Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video](youtube.com)
youtube.com
Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
https://www.youtube.com/watch?v=9ag0fPMmYPQ
36 comments
As someone who has been playing around with (and enjoying) Mojo, I have my doubts about how useful Mojo will end up being for your average scientist. You can't get performant code out of Mojo if you're not willing to learn some deeper programming concepts like SIMD or tiling.
I don't have the exact quote on hand, but in the Mojo Discord, Chris Latner explicitly said he wants no "compiler magic" in Mojo. With that idea in mind, Mojo makes it a lot easier to do optimizations like SIMD vectorization by hand, but you will still have to do it manually. My guess is that many scientists who don't like programming would find it annoying to hand-write those kinds of optimizations. If you want a language that gives you nice, performant code on your first attempt, Julia is always a decent option.
These are the docs for some of Mojo's higher order functions that implement vectorization, parallelization, tiling, loop switching, etc. https://docs.modular.com/mojo/stdlib/algorithm/functional
I do think they are a good idea and relatively easy to use; I'm just not convinced that the non-programmer scientist will like them.
I don't have the exact quote on hand, but in the Mojo Discord, Chris Latner explicitly said he wants no "compiler magic" in Mojo. With that idea in mind, Mojo makes it a lot easier to do optimizations like SIMD vectorization by hand, but you will still have to do it manually. My guess is that many scientists who don't like programming would find it annoying to hand-write those kinds of optimizations. If you want a language that gives you nice, performant code on your first attempt, Julia is always a decent option.
These are the docs for some of Mojo's higher order functions that implement vectorization, parallelization, tiling, loop switching, etc. https://docs.modular.com/mojo/stdlib/algorithm/functional
I do think they are a good idea and relatively easy to use; I'm just not convinced that the non-programmer scientist will like them.
> If you want a language that gives you nice, performant code on your first attempt, Julia is always a decent option.
If Julia hasn't taken off yet (which I am very sad about), I'm not sure why Mojo would. I'd rather have more resources invested into Julia.
If Julia hasn't taken off yet (which I am very sad about), I'm not sure why Mojo would. I'd rather have more resources invested into Julia.
Depends on what one means regarding taking off, several industries are quite happy with it.
https://info.juliahub.com/case-studies
Any language designer would be crying of joy if their language had so few users as Julia is currently having.
https://info.juliahub.com/case-studies
Any language designer would be crying of joy if their language had so few users as Julia is currently having.
Julia has to bootstrap an ecosystem. If mojo can borrow all of the successful Python libraries, that is worth a lot.
Still an enormous uphill battle, but slightly more tractable. Regardless, it is a rough place to be - for a staggering number of uses, Python is fast enough. The organizations who absolutely require top tier performance already have the ability to use FFI. Instagram runs on Django and I believe is still used for YouTube.
Still an enormous uphill battle, but slightly more tractable. Regardless, it is a rough place to be - for a staggering number of uses, Python is fast enough. The organizations who absolutely require top tier performance already have the ability to use FFI. Instagram runs on Django and I believe is still used for YouTube.
OTOH,Rust has shown that there is a reasonable size market for performant, safe system programming languages. I suspect it is being held back from larger adoption due to its complexity. I see an opportunity for Mojo to get into that, with a simpler model and ability to gradually opt in to more complex but high performance parts of the language.
Mojo has a good chance to target Python programmers who would have gone for Go or Java for better performance, and C++ programmers who need something like Rust, but simpler.
Mojo has a good chance to target Python programmers who would have gone for Go or Java for better performance, and C++ programmers who need something like Rust, but simpler.
That wouldn't be my guess at what "no compiler magic" implies.
Compiler magic means the implementation doing things that the application can't. It reflects limitations or constraints on the target language. If the language is expressive enough you can do everything through library code.
This would mean you're able to do simd vectorisation by hand, but you're also able to run a compile time transform that vectorises your code without needing to bind that transform into the implementation of the compiler.
Thus the non-programmer scientist can use libraries written by someone more on the boundary that do autovec etc, without needing to wait for the core mojo implementation to do it.
Compiler magic means the implementation doing things that the application can't. It reflects limitations or constraints on the target language. If the language is expressive enough you can do everything through library code.
This would mean you're able to do simd vectorisation by hand, but you're also able to run a compile time transform that vectorises your code without needing to bind that transform into the implementation of the compiler.
Thus the non-programmer scientist can use libraries written by someone more on the boundary that do autovec etc, without needing to wait for the core mojo implementation to do it.
Won't the right abstractions like NumPy make it possible for researchers to obtain generally performant code, and lower the bar to write specialized, optimized code without having to drop all the way down to CUDA?
I think I would agree with you. In my opinion, that already exists and is decently mature. CuPy [0] for Python and CUDA.jl [1] for Julia are both excellent ways to interface with GPU that don't require you to get into the nitty gritty of CUDA. Both do their best to keep you at the Array-level abstraction until you actually need to start writing kernels yourself and even then, it's pretty simple. They took a complete GPU novice like me and let me to write pretty performant kernels without having to ever touch raw CUDA.
[0] https://cupy.dev/
[1] https://cuda.juliagpu.org/stable/
[0] https://cupy.dev/
[1] https://cuda.juliagpu.org/stable/
True, but don't you think AI Copilots can optimize the code in the future? Write the code in Python, then tell Copilot to optimize it with Mojo.
I am really enjoying the language, the level of improvement over the last few months has been amazing. At work all our heterogeneous compute needs are implemented using C++/CUDA. I've been exploring new languages for the type of work we do on and off over the last few years: Julia, Rust, D, Chapel, and Mojo.
It seems the only new languages serious about native heterogeneous compute are: Julia, Chapel, and Mojo.
Of those languages I can say Mojo and Chapel were the most impressive. But Mojo is just so fun to write, I've ported a bunch of my "hobby numerical code" to Mojo. I am practically all in on Mojo since it'll give me access to MLIR.
I have always wondered though, why does Chapel get no love online???
Of those languages I can say Mojo and Chapel were the most impressive. But Mojo is just so fun to write, I've ported a bunch of my "hobby numerical code" to Mojo. I am practically all in on Mojo since it'll give me access to MLIR.
I have always wondered though, why does Chapel get no love online???
Most likely because HPC isn't cool for TikTok videos, by language influencers.
As CERN alumni, and language nerd, I find Chapel quite cool.
As CERN alumni, and language nerd, I find Chapel quite cool.
Heard some positive things about Mojo. But my curiousity waned after I learnt it was not open source currently.
In 2024 why should I be interested in a language that is not open source ? Perhaps I'm missing something ?
In 2024 why should I be interested in a language that is not open source ? Perhaps I'm missing something ?
The standard library is open source, you can find it here: https://github.com/modularml/mojo/tree/nightly/stdlib
We'll be opening up more over time - stay tuned!
We'll be opening up more over time - stay tuned!
Just in case you're in the know:
I was really really close to trying to spin up something at work using the Max Engine. However, I see that it collects telemetry [1], and we can't really allow that. Do you know if there are plans to be able to turn this entirely off at some point?
It's nice to know if I should keep it on my radar, or if I can't consider it without changing jobs :)
[1]: https://docs.modular.com/engine/faq#does-the-max-sdk-collect...
I was really really close to trying to spin up something at work using the Max Engine. However, I see that it collects telemetry [1], and we can't really allow that. Do you know if there are plans to be able to turn this entirely off at some point?
It's nice to know if I should keep it on my radar, or if I can't consider it without changing jobs :)
[1]: https://docs.modular.com/engine/faq#does-the-max-sdk-collect...
Please reach out to us to talk through it, I'm sure there's a way to work it out.
There’s nothing bad about telemetry per se. In fact it should be considered bad to not be paying attention to how anything you build works in the real world.
(Then comes Meta c.s. and everyone rightly distrusts anything reported back from their computer)
This just to say, that yes, the majority of companies cannot be trusted, but there’s still good guys out there collecting useful metrics completely devoid of secondary malicious purposes.
(Then comes Meta c.s. and everyone rightly distrusts anything reported back from their computer)
This just to say, that yes, the majority of companies cannot be trusted, but there’s still good guys out there collecting useful metrics completely devoid of secondary malicious purposes.
Intentions be damned. Some industries take IP/security very seriously (eg regulated medical). Tools which phone home “for my user experience” are a complete deal breaker.
QED
Mojo's developers claim that they intend for Mojo to be open source:
https://www.modular.com/blog/the-next-big-step-in-mojo-open-...
This is encouraging, and it seems that at least the core of the language is now open: https://github.com/modularml/mojo
I haven't tried it and I don't have a sense of how open Mojo really is today, or what's left that isn't open. I tend to agree that we should take the open source claim with skepticism until we see it in action.
The goals for the project are promising: something like the expressiveness of Python combined with the speed and safety of Rust. If they can pull it off, and it's open source, that will be very impressive.
This is encouraging, and it seems that at least the core of the language is now open: https://github.com/modularml/mojo
I haven't tried it and I don't have a sense of how open Mojo really is today, or what's left that isn't open. I tend to agree that we should take the open source claim with skepticism until we see it in action.
The goals for the project are promising: something like the expressiveness of Python combined with the speed and safety of Rust. If they can pull it off, and it's open source, that will be very impressive.
> something like the expressiveness of Python combined with the speed and safety of Rust.
Isn't that problem already solved? We already have Nim[0] that is memory-safe language with Python-esque syntax and performance of C. Yeah, it's not an extension of Python as Mojo claims to be; but I'd pick a mature language with proven design for my projects over something that's not even out yet.
[0]- http://nim-lang.org
Isn't that problem already solved? We already have Nim[0] that is memory-safe language with Python-esque syntax and performance of C. Yeah, it's not an extension of Python as Mojo claims to be; but I'd pick a mature language with proven design for my projects over something that's not even out yet.
[0]- http://nim-lang.org
About 11 minutes in as an aside they look at an example where they're initially mutating a growable array (Rust's Vec, Mojo's List) and now they want to replace it instead.
The narrator (rather than Chris) shows that Mojo makes this fairly easy - we were never promising only to mutate the container, so if we replace it instead that's fine. And they (presumably correctly, I am not a Python expert) say that Python just can't do this.
But they also claim Rust can't do it either, and propose a fairly serious surgery to adjust the function signature instead to write a function which takes and returns ownership.
But you don't need to do that in Rust. We have a mutable reference, Rust doesn't mind us changing what it refers to, it's mutable after all, we just can't move it because it's not ours to move. This is where core::mem::swap, core::mem::take and core::mem::replace enter the picture, they allow us to easily use this capability.
For the example they're explaining you can just core::mem::replace(v, vec![8, 8]); and you're done, the signature doesn't change at all.
The narrator (rather than Chris) shows that Mojo makes this fairly easy - we were never promising only to mutate the container, so if we replace it instead that's fine. And they (presumably correctly, I am not a Python expert) say that Python just can't do this.
But they also claim Rust can't do it either, and propose a fairly serious surgery to adjust the function signature instead to write a function which takes and returns ownership.
But you don't need to do that in Rust. We have a mutable reference, Rust doesn't mind us changing what it refers to, it's mutable after all, we just can't move it because it's not ours to move. This is where core::mem::swap, core::mem::take and core::mem::replace enter the picture, they allow us to easily use this capability.
For the example they're explaining you can just core::mem::replace(v, vec![8, 8]); and you're done, the signature doesn't change at all.
I REALLY want to use mojo...but they still don't have basic backwards compatibility features like lambda done. I worry mojo won't get off the ground because they're too focused on hardware performance and aren't building enough features to justify the switch... to get that hardware performance.
Mojo feels like a language that's trying to be everything for everyone.
I feel the opposite, they really are focused on being a language that's great for AI and heterogeneous compute, since that's what Modular is focused on. But the features are attractive for other use cases, it has access to MLIR, compile time metaprogramming, easy and ergonomic SIMD, and soon GPU support.
Okay great.
Why does AI and heterogeneous compute need ownership and lifetime checks again?
These are really needed for low level pointer heavy code.
Why does AI and heterogeneous compute need ownership and lifetime checks again?
These are really needed for low level pointer heavy code.
Because writing a garbage collector to run on graphics cards is a thankless PhD class problem, even if technically possible, no one will adopt it.
So they can optimize code. The main theme is addressing two-language problem (single high & low level language). They want uniform language for cpu/gpu/whatever-pu. They can't have garbage collection. They need strict dataflow analysis with precise destruction points.
Do you see my point that they are trying to do everything?
They're not trying to do everything. They don't care about stuff like Hindley–Milner inference, logic programming, relational algebra integration, tsx like html integration, functional purity, algebraic effects and dozens of other concepts. They just care about extending python so you don't need to use ffi to jump into c++/cuda for performance because language already supports high performance constructs.
So how is Mojo comparing with Hylo (formerly Val), the other former Swift creator created new language?
Completely different goals. Mojo seeks to replace / supplement Python in the compute space, Hylo (Val) is an experiment in a value-first semantic language, inspired by Swift.
Any technological advancement that gets them more efficiency and leverage without the bottleneck of working with a software engineer would both empower scientists and free up software engineers for other problems.
It remains to be seen whether it will actually deliver on this potential. I think a lot has been promised before it's been proven. But I do think something like this is worth attempting and thoughtful work is being applied to the attempt.