Mojo feels like a great fit for so many domains outside of AI. It could be a killer general purpose language.
It's easy to read and write, offers memory safety without RC or GC or even much mental overhead, will (eventually) be a superset of Python, and it's very performant already.
So far I've been hesitant to invest more time in it when it's pitched as "the programming language for all AI developers", when it's distributed inside the MAX package[1], and when Modular is prioritising features around AI over all else. (I understand why for all these things, I just wish it were otherwise.)
It's great to see the library in the open, but it would be much more compelling for me if Mojo were a separate entity, with its own open site and foundation, to be used by Modular but with more diverse adoption encouraged. Of course it's early days, but I hope it takes on a life more like Rust than Swift (which — despite its potential as a general-purpose language‚ is still largely used in one ecosystem).
You're right that Mojo is a completely general purpose programming language. Community members are already building gui libraries and serving stuff etc.
It might not be the best thing, but here's the rationale for why we do this: it's basically that Mojo is still early, and being "good" at something requires more than a language - you also need a library ecosystem and committed community around there. We don't think it is time to declare that Mojo is a great solution for GUI development (for example) until these things happen.
In contrast, Modular is pushing hard to build out the AI part of the ecosystem and already has MAX engine and even more things coming, so we're pretty confident that Mojo will be great in the AI domain.
As the community builds out, we can expand positioning where it makes sense. We just don't want to overclaim.
Is there a packaging ecosystem, or does PyPi interoperate? I would love to start writing some Mojo code, but a key thing I'd love to do is make web requests. Any direction you have would be sincerely appreciated!
We're definitely going to explore this further, and have begun some discussions with the community to try and shape what this will look like for Mojo; see https://github.com/modularml/mojo/discussions/1785 for more details.
The discussion there is centered on a project manifest and build tool, and work is underway. Some of our guiding principles are to write this tooling in Mojo, as open source software, and to be focused on integration with existing build systems and ecosystems.
Of course, once we're able to define a Mojo project, and have a principled method of building all Mojo projects in the known universe, the natural next step would be to build out a packaging ecosystem. Again, we're interested in playing well with others, so while it's still early days, I think we'll want to have a well-thought-out interface with PyPI.
As for web requests: try searching GitHub for Mojo projects that may suit your needs: https://github.com/search?q=language%3Amojo+http&type=reposi... -- and by the way, we're also very proud that Mojo has become popular enough on GitHub that it can be searched like this, and its source code is syntax highlighted. If you don't see any Mojo packages on there that you like, try writing one yourself and letting us know on our Discord! Although we don't (yet!) have a build tool, you can clone a Mojo package from GitHub and import it into your project manually, so sharing code is possible -- we're working to make it not just possible, but downright awesome!
If Mojo can nail single-file deployment and have a Cargo-like packaging experience, along with the characteristics you highlighted, it could be an excellent general purpose language for web backends, cli tools etc
Yes! But also games and other hard real-time systems, desktop apps, microcontrollers and so much more…
I think it will get there with packaging. (Modular was recently hiring someone to work on Mojo's dev tooling full time, which sounds awesome, and I don't see that role any more so perhaps it was filled.)
Mojo is already the language I want to reach for for 100 things outside of AI. It would just help to know that the team behind it will actively support/encourage use of it in those spaces first.
We totally want to see Mojo go into all these places! It's just that Modular can't fund use of Mojo in (eg) gamedev or embedded development (at least not in the foreseeable future). Open sourcing the implementation is a big part of helping catalyze those developments in the community.
In my experience, a diverse community of people who want similar but /different/ things is what builds out a thriving community. This is why LLVM is pretty great for example: lots of people have a shared view on what technical excellence means, but they all want different things so you get a well balanced ecosystem, not just "Apple's compiler".
Right, but with improved ergonomics that make Mojo easier to learn and write than Rust, the biggest difference being “borrow by default” as described here:
It's very interesting to browse, since it's a huge collection of (presumably) working tested example code doing mundane things using Mojo, which is extremely useful to browse when trying to figure out how to efficiently use the language. Similarly, browsing the implementation of the stdlib has helped me a lot with learning zig.
Awesome, we'll be releasing a bunch more, but this is a pretty exciting starting point. The standard library has a lot of the lowest level details, and shapes most of the language - because so much of Mojo is library defined.
When mojo was initially released I didn’t think much of it because: 1. It was announced prior to being available, even in closed source form. 2. Emoji filenames meant to me that it wasn’t taking itself too seriously. 3. Many people have tried to make Python fast and failed, and that was my naive take on it, and despite the fact that LLVM allstars were working on it, it seemed like a lofty goal. 4. Closed source programming languages usually suck.
There are some fascinating ideas here, I’m especially excited about what could come from their templated IR. Recommend others give it a watch if they’re confused on why they should pay attention to this project.
If you're interested in compiler nerdery, you should totally check out the source code, you'll see just how much we meant by "Syntactic sugar for MLIR" :-)
If people from the Mojo team are here, I’m curious what the arguments were against focusing on improving the Julia ecosystem and instead building Mojo? Julia solves the multi-language problem pretty well now and already has lots of great ML libraries that could use greater support.
Edit: nevermind, realizing from the a YouTube video linked in the comments that they viewed Python compatibility as a non negotiable
I wish Mojo or any other other languages for intensive data processing and HPC would consider techniques proposed by MPL with its novel Automatic Management of Parallelism. It won distinguished paper award in POPL 2024 and ACM SIGPLAN dissertation award 2023 by proposing these two main things [1],[2]:
a) Provably efficient parallel garbage collection based on disentanglement
b) Provably efficient automatic granularity control
Pretty disappointed to not find sources for the compiler yet, which is the part I'm by far the most interested in. Hopefully that will follow this release soon!
Is anyone else surprised at the straightforward collections implementations? From reading this site (and leetcode interviews) I expected to find advanced data structures under the hood. This is not a negative comment, I'm pro Mojo, just wondering who the heck is using the fancy stuff we get quizzed on in interviews if not stdlib devs.
They're used only as needed. Which is to say, rarely.
Eg. A database might store its index in a B-Tree, or other "similar" data structure. For example, you can see RocksDB using "fancy" structure to store its data [0].
It's easy to read and write, offers memory safety without RC or GC or even much mental overhead, will (eventually) be a superset of Python, and it's very performant already.
So far I've been hesitant to invest more time in it when it's pitched as "the programming language for all AI developers", when it's distributed inside the MAX package[1], and when Modular is prioritising features around AI over all else. (I understand why for all these things, I just wish it were otherwise.)
It's great to see the library in the open, but it would be much more compelling for me if Mojo were a separate entity, with its own open site and foundation, to be used by Modular but with more diverse adoption encouraged. Of course it's early days, but I hope it takes on a life more like Rust than Swift (which — despite its potential as a general-purpose language‚ is still largely used in one ecosystem).
1: https://www.modular.com/blog/max-is-here-what-does-that-mean...