Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]

https://www.youtube.com/watch?v=9ag0fPMmYPQ

by jackclayton • 2 years ago

60 36 2 years ago

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.

fl0ki• 2 years ago

It'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 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.

CoreyFieldens2• 2 years ago

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.

madspindel• 2 years ago

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.

likium• 2 years ago

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?

dunefox• 2 years ago

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.

JonChesterfield• 2 years ago

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.

sidkshatriya• 2 years ago

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 ?

jopamer• 2 years ago

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!

NegatioN• 2 years ago

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

loudmax• 2 years ago

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.

archargelod• 2 years ago

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

Apocryphon• 2 years ago

So how is Mojo comparing with Hylo (formerly Val), the other former Swift creator created new language?

jshier• 2 years ago

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.

fooker3• 2 years ago

Mojo feels like a language that's trying to be everything for everyone.

WeatherBrier2• 2 years ago

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.

fooker3• 2 years ago

Okay great.

Why does AI and heterogeneous compute need ownership and lifetime checks again?

These are really needed for low level pointer heavy code.

WeatherBrier2• 2 years ago

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???

pjmlp4• 2 years ago

Most likely because HPC isn't cool for TikTok videos, by language influencers.

As CERN alumni, and language nerd, I find Chapel quite cool.

hyperjeff• 2 years ago

eech. i don’t want to use a language made by people who take advice from, let alone watch, tiktok influencers.

tialaramex• 2 years ago

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.

Mojo: Ownership and lifetime checks deep dive with Chris Lattner [video]

Related Stories