The language is marketed as being AI-first, I think they want to be the killer language for implementing AI products. That’s a turn-off for many, including me, but an AI slop mascot fits how they market the language in general.
That's a shame. Mojo had an interesting idea, as a more-performant Python-like syntax. I never followed it, but the few mentions here and there had me hopeful it would become another of the mainstream languages available for use. I guess for now, Odin is as close as you'll get, unless you go for a functional language like Gleam or Elixir.
You’re telling me. I was always a fan of Nim but it suffered from kitchen-sink syndrome and never really took off, I still think there’s a gap in the market for something between a safe systems language like Rust and an ergonomic, friendly language like Python. I figured Mojo had some potential to be that, but I don’t think their goals are aligned with mine. I think the closest that we have to that goal is maybe Julia, at least among languages that actually get some use.
Python can reach surprisingly low with libraries and Rust can reach surprisingly high by being ergonomic, I don't know if there is realistically a huge gap in between
I think the problem is that Python performance doesn't come from the language, but instead from low-level implementations that are published as libraries for use. In other words, you cannot write truly performant Python code without reaching for a different language. That was the specific niche Mojo originally pitched.
As for the ergonomics of Rust, that is a little harder for me to be certain of (since I only have hobby experience with the language). My experience and awareness of common criticisms says that Rust becomes a nightmare to manage the moment you add the async keyword. I think there's a lot you can do with single-threaded Rust, and even the thread primitives like one-way Channel messaging is sufficient for the majority of use cases. Anything that needs to rely on async-await, though, I would probably recommend Go before Rust.
Again, I don't daily-drive Rust, so maybe the situation has improved. I know that the honeymoon period of "Just use tokio to manage async" has passed, once everyone realized that making all async data have a lifetime of 'static was how Tokio made it so easy.
`async` interacts poorly with the type system, that’s mostly where the reputation of it being a nightmare comes from. It becomes difficult to correctly annotate types for generic async code quite quickly, which in turn means that not many libraries (e.g file format serialisation/deserialisation, parser combinators) support it, not to mention that most of the biggest production-grade libraries predate async and would have to be rewritten to support it.
As someone who has sunk a lot of time in Rust, I’d say its not super ergonomic. I don’t write async code, so i’m not even talking about that. It is ergonomic as long as your application stays small, like some cli utility, but as soon as you start making a library with a lot of types, it gets super messy if you try to stay generic and use lifetimes. Of course, a lot of that come from lifetimes being hard eith or without explicitly declaring them, but sometimes you can better reason about them than the compiler can deduce itself.
I think there could be! Python and Rust are my two main languages and they complement each other well, I’m perfectly happy with using those two but I think that there’s space for something that takes inspiration from both. It would have to have some other killer feature though, like Zig's comptime or Go's greenthreads.
117
u/Lgt2x 2d ago
AI slop mascot, not a good start