Earlier quoted context omitted.
Okay great. Why does AI and heterogeneous compute need ownership and lifetime checks again? These are really needed for low level pointer heavy code.
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.
Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
21–30 of 37 posts
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#22It's fashionable to hate on Mojo, but I actually hope they succeed. I started my career by writing fast, production-grade replacements for Python programs written by scientists. Without someone like me, they were squandering government-funded compute resources and wasting time on the critical path to delivering their scientific contributions. Any technological advancement that gets them more efficiency and leverage w…
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 ide…
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#23Earlier quoted context omitted.
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!
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…
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#24Earlier quoted context omitted.
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 ide…
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?
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#25It's fashionable to hate on Mojo, but I actually hope they succeed. I started my career by writing fast, production-grade replacements for Python programs written by scientists. Without someone like me, they were squandering government-funded compute resources and wasting time on the critical path to delivering their scientific contributions. Any technological advancement that gets them more efficiency and leverage w…
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 ide…
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.
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#26The 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.
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#27Earlier quoted context omitted.
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 ide…
> 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.
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.
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#28Heard 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 ?
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…
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
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#29It's fashionable to hate on Mojo, but I actually hope they succeed. I started my career by writing fast, production-grade replacements for Python programs written by scientists. Without someone like me, they were squandering government-funded compute resources and wasting time on the critical path to delivering their scientific contributions. Any technological advancement that gets them more efficiency and leverage w…
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 ide…
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.
Re: Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]
#30Earlier quoted context omitted.
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…
> 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