Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Next Big Step in Mojo Open Source

modular.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: The Next Big Step in Mojo Open Source

#11

Post by modernerd »

achandran wrote: post #10
modernerd wrote: post #7

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 dis…

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.

Re: The Next Big Step in Mojo Open Source

#12

Post by chrislattner »

modernerd wrote: post #7

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 dis…

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

Re: The Next Big Step in Mojo Open Source

#13

Post by chrislattner »

modernerd wrote: post #11
achandran wrote: post #10

Earlier quoted context omitted.

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 th…

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

Re: The Next Big Step in Mojo Open Source

#14

Post by chrislattner »

nickysielicki wrote: post #8

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 progr…

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

Re: The Next Big Step in Mojo Open Source

#15

Post by CurriedLambda »

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.

Re: The Next Big Step in Mojo Open Source

#16

Post by ptx »

modernerd wrote: post #7

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 dis…

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

Re: The Next Big Step in Mojo Open Source

#18

Post by zerojames »

chrislattner wrote: post #12
modernerd wrote: post #7

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 dis…

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…

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!

Re: The Next Big Step in Mojo Open Source

#19

Post by modocache »

zerojames wrote: post #18
chrislattner wrote: post #12

Earlier quoted context omitted.

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…

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!

Re: The Next Big Step in Mojo Open Source

#20

Post by teleforce »

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

Post reply on HN