Could Mojo be the first all purpose language?
All languages have their own strengths and weaknesses, which is why we have so many — to cover all our bases. I'm wondering if Mojo could realistically become an "all-purpose" language — not as the default for every use case, but as a strong contender in every domain.
In my mind, there are 3 core requirements for a language to be truly all-purpose:
Speed — to ensure performance-critical cases don't default to C/C++/Rust.
Safety — to prevent Rust from being the go-to in security-sensitive environments.
Ease of use — to compete with Python or Go in scenarios like scripting or teaching.
Ecosystem and tooling matter, but these tend to grow with adoption, whereas the above three characteristics are more fundamental to the language itself.
No current language truly nails all three — Rust is close with 2/3, but its complexity holds it back from the ease-of-use aspect. Its arguably not even possible to achieve all three at the same time: memory management alone requires making a decision between speed (manual management / borrow checker) and ease of use (GC / ARC).
However, Mojo's dual approach (Python mode for ease and saftey and Rust-like features like fn and the borrow checker for speed and safety) seems to come closest to striking this balance.
Could Mojo actually evolve into an all-purpose language? Or would the inevitable trade-offs (potential complexity or C++ like feature bloat) make that impractical? Is it even desirable to have an all-purpose language in the first place?
I'd love to hear everyone's thoughts!
8 Replies
Mojo is a general purpose language, but there are things it likely won't do.
* Safety critical, since formally verified compilers are hard to make even for C, much less a language like Mojo.
* Embedded, since they are just starting to come around to Rust.
There is an amount of additional detail that will get pulled in as the language evolves. For instance, Mojo will have to enforce alias xor mutable or something equivalent, which makes it harder get a multi-threaded program to compile, but easier to make a correct one. Also, some people's definition of "ease of use" means no types at all, and Mojo libraries are likely to be strongly encouraged to be fully typed. Mojo is headed down a path of making library authorship harder to make the general user experience easier, which may cause issues for library authors.
It's also important to note that Arc does not turn off the borrow checker, and Mojo still has many of the restrictions that Rust does.
There will also be a reason to use a language more specialized towards a domain, so I don't think an "all purpose" language is possible. Especially since the "if the program compiles it has no bugs if you properly specified what a bug is" feature of Rocq (formerly Coq), Lean, Agda and Idris requires a substantial amount of math and CS knowledge to use at all, and that is desirable in many circumstances. "All purpose" also groups in things like SQL, which have very different goals than Mojo.
Mojo is a good, useful language, but trying to claim to be everything to everyone is going to cause issues.
I was referring to programming languages rather than query languages or proof verification tools, but thanks for the input!
Wouldn't Mojo need to support dynamic typing and python libraries to be a super set of python? Or are you saying that even if this is true, it won't matter since using the pythonic syntax would be frowned upon.
Mojo will support duck typing (as python does). The reason that library authors are likely pushed towards using the typed set of the language (fn) is that libraries in the "dyn" part of the language will likely produce worse LSP output, simply due to how more dynamic type systems work, and for anyone on the "fn" side of the language anything from a dynamic language is typed as "object" and there isn't a good way to tell what errors are thrown.
It's the same reason why JS devs always want typescript types or jsdoc for libraries.
Also, the reason I used "language" in the way that I did is because any definition aside from turing completeness tends to exclude things people generally think of as languages.
If you specifically mean general purpose languages, then there is a smaller set of things that Mojo is missing, but the borrow checker memory management is something many people are not going to like.
Trying to be everything to everyone is unsustainable, and is why C++ is in the position it currently is.
Lean is actually pretty cool.
but the borrow checker memory management is something many people are not going to like.I'm going to make sure it's likeable, don't worry about that. This has been my longstanding mission. It's time we put the "borrow checking is complicated" meme to bed. Mojo can achieve this, I'm sure of it.
I sure hope so! My personal hopeful use case for mojo would be for a wasm app server host prototype using python/dynamic and then slowly moved into pure mojo and solidified little by little over time for performance and correctness.
Congrats @mikeb, you just advanced to level 1!
I think Mojo has already done a lot to fix this. The ASAP memory model, value identity, and the heavy use of value semantics really makes the experience smoother than Rust's.