The Next Big Step in Mojo Open Source | Hacker News Reader

The Next Big Step in Mojo Open Source

modular.com

162 pointsmelodyogonna23 comments

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).

1: https://www.modular.com/blog/max-is-here-what-does-that-mean...

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".

-Chris

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.

-Chris

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!

The memory management approach is basically the same as in Rust, according to the docs[0].

Merging Rust and Python into a single language sounds like a very challenging project, with "eventually" being far into the future at best.

[0] https://docs.modular.com/mojo/manual/values/ownership

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:

https://www.modular.com/blog/mojo-vs-rust-is-mojo-faster-tha...

Mojo just open sourced their standard library. https://github.com/modularml/mojo/tree/nightly/stdlib

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.

-Chris

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.

They presented at the LLVM conference in 2023 and this video totally changed my view: https://youtu.be/SEwTjZvy8vw?si=itaRiFCIwGnyOQcc

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" :-)

A relatively accessible example is the `Int` type: https://github.com/modularml/mojo/blob/main/stdlib/src/built...

implemented in terms of the index dialect (that Modular upstreamed to MLIR): https://mlir.llvm.org/docs/Dialects/IndexOps/

-Chris

So it looks like the actual runtime is still closed.

You mean compiler. And yes, it has not been open-sourced just yet.

Won’t touch it until it is, but I’m very exited for it to happen.

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

What is the deal with exceptions? I see https://docs.modular.com/mojo/roadmap#the-standard-library-h... and https://github.com/modularml/mojo/blob/main/stdlib/src/built... but then other places debug_assert is used https://github.com/modularml/mojo/blob/6d2a7b552769358ec68a9...

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

[1] MaPLe (MPL):

https://github.com/MPLLang/mpl

[2] Automatic Parallelism Management:

https://dl.acm.org/doi/10.1145/3632880

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].

[0] https://github.com/facebook/rocksdb

Reply on news.ycombinator.com