Rust vs Mojo - the new LLVM language

[Jesper]

Curious if some of you have some thoughts on the newly announced Mojo language:

Modular Docs - Mojo🔥 programming manual

Superset of Python - but like Rust has a borrow checker and is also built on the LLVM compiler. Compiled language - so you can distribute just the executable without the interpreter.

It is aimed at the tensorflow/pytorch machine learning domain - but looks like it might be useful for general systems programming.

Feels a bit like C vs C++ in that you can switch immediately - but eventually will want to migrate to the new classes (struct & fn vs class & def) to take advantage of the type system and faster execution.

[jofas]

By bringing together the best of dynamic languages and systems languages, we hope to provide a unified programming model that works across levels of abstraction, is friendly for novice programmers, and scales across many use cases from accelerators through to application programming and scripting.

Makes me think of this famous xkcd cartoon

I personally am quite vary of the Python ecosystem and the various languages and dialects that developed around its deficiencies when it comes to writing performance-critical programs. Especially in the whole scientific computing realm. I really enjoy another LLVM-based language that looks similar to Mojo to me: Julia. I find the language really refreshing and it does not carry along the cruft from 30 years of Python development with it. I'm not sure whether Mojo can be successful and accomplish its grand goals of a unified programming model spanning accelerators, system programming, application development and scripting. Or if it becomes the next Cython, which I'd argue is a rather niche language beyond a few scientific computing libraries.

[H2CO3]

If you allow me to pick out one particular thing that makes me not like the language very much upfront: it looks like they've got their explicitness goals completely backwards. One of the examples in the demo looks something like this:

let x: Array<_> = make_array();
mutate_in_place(x); // mutate in place
pass_by_value(x^); // give away ownership

That is, passing by mutable reference is implicit, while passing by value must be explicitly annotated. That sounds like it contradicts 50 years of industry experience It is mutating that should be explicit, because that's what can lead to surprises.

---

In any case, I don't think it's a Rust competitor. It's explicitly oriented towards machine learning, so I'd pretty much consider it a DSL rather than a general-purpose systems programming language.

[Jesper]

Julia is a great language - not general purpose, but arguably the one the data science community should have adopted instead of python...

Would also have loved to see Rust being used for machine learning - does have 'unofficial' bindings for pytorch & tensorflow, but I'm afraid the community is not coming.

Love python, but always saw it as mainly a scripting language replacing shell scripts, perl, etc.

Always been a weakness that you didn't have direct access to fundamental machine types (int, float) - which you do in Julia. A package manager came late to the language - and the "batteries included" means that the standard library is full of modules that are not best in class but never will go away.

Python's list type is actually implemented with arrays - always bothered me - lists and arrays are different. Intention was to make it easy to learn programming - but why start out that way.

Nevertheless, Chris Lattner is a great guy to have behind Mojo.

[hax10]

I think it's good to see borrow checking make its way to another language.

I don't see Mojo competing with Rust though, as Rust is, for better or for worse, very much a statically-typed language. Mojo, on the other hand, will always have to support a large dynamically-typed codebase in order to maintain compatibility with Python. This has important consequences for what kinds of projects will be well-suited to each language and also the kinds of programmers who will be attracted to them.

[jofas]

@Jesper

but arguably the one the data science community should have adopted instead of python...

Amen. I mean Julia is 20 years younger and the community must first develop. I do think a new language fully focused on scientific computing with performance in mind should be preferred over trying to make semi-suitable languages fit that particular purpose. Especially given that with numerical computing, you now have to be able to support a ton of heterogeneous hardware and distributed resources. In a perfect world we'd all write Fortran, of course, but I stopped trying to convince the masses of my divine message.

@Jesper

Nevertheless, Chris Lattner is a great guy to have behind Mojo.

Okay, then Mojo probably will gain some traction. Who can put LLVM, Clang, Swift, MLIR and XLA on their resume?

[kevinmcfarlane]

At minimum I expect it to have traction in the AI space as it addresses the "environmental" pain points they describe in their "why" document.

It's then a question of whether it gets used more widely beyond that.

[Jesper]

I think the AI part is mainly to try to grab that community and quickly have a large user base.

Interestingly Swift - Chris Lattner's previous language - already had integration with python, C and tensorflow - but maybe it never took off in the way he envisaged. Here is an old video where he talks about that

The Power of Swift for Machine Learning (TensorFlow Meets)

[Pyramidev]

@hax10

I don't see Mojo competing with Rust though, as Rust is, for better or for worse, very much a statically-typed language. Mojo, on the other hand, will always have to support a large dynamically-typed codebase in order to maintain compatibility with Python. This has important consequences for what kinds of projects will be well-suited to each language and also the kinds of programmers who will be attracted to them.

If Mojo manages to become a Python superset and have a good ecosystem, then I think it will compete with Rust for some programmers. But it depends on witch kind of Rust programmer.

For example, here an article from Aembit: Why We Chose Rust - Aembit

Sadly, this article could be summarized as follows: We don't like Rust and we would prefer to code in Go. But, if we have chosen Go, then we may need to rewrite the code in a more performant language later.

This kind of Rust programmer would prefer a language with a simpler learning curve that allows them to optimize the code later.

For this kind of programmer, I think that Mojo may compete with Rust in the future.

On the contrary, here is an article from Qdrant: Why Rust? - Qdrant

This kind of Rust programmer chooses Rust because it is a good language.

For them, I don't think that Mojo would match.

[hax10]

@Pyramidev

If Mojo manages to become a Python superset and have a good ecosystem, then I think it will compete with Rust for some programmers. But it depends on witch kind of Rust programmer.

Yeah, I think that's true, it does depend on the specific circumstances. I agree Mojo won't be attractive to people who are willing to put in the time to learn Rust and whose needs are well-served by the existing Rust ecosystem. But programmers who want to get started hacking quickly and who want libraries that Python is well-known for (especially in data science) may prefer Mojo.

[kevinmcfarlane]

The rationale and vision are as described here.

The Case for a Next-Generation AI Developer Platform

AI software today is monolithic and research quality, fractured into technology silos that follow the organization chart of the Big Tech companies who built it. It was created by researchers to do research, and the quick evolution of AI has left no time to pause and build it right. Instead we've just piled on more and more layers of complexity over time, resulting in an industry that is struggling to maintain and scale fragmented custom tool chains that differ between research and production, training and deployment, server and edge. AI systems have become a vast sea of incompatible technologies that only the largest and most sophisticated companies can brute force to achieve their goals.

A unified, extensible platform to superpower your AI

So it's not just offering a new language but attempting to streamline the entire AI ecosystem while allowing re-use and interoperability with it.

In that sense I don't see it as a competitor to Rust. They have different goals. Though I can easily see how scientific researchers doing numerical computing in general, not just in AI might grab Mojo to wrap and performance-boost whatever they are already doing without (traditionally) having to drop down to C/C++.

[khimru]

@H2CO3

In any case, I don't think it's a Rust competitor. It's explicitly oriented towards machine learning, so I'd pretty much consider it a DSL rather than a general-purpose systems programming language.

I still hope it'll succeed. Because lifetime tracking is one of the hardest tasks in any language and now, when Rust have shown that it's actually possible to put in the language… we need more such languages.

Because stretching Rust to cover both low-level programming and high-level scripting would just turn it into a monster not suitable for either.

[yuribudilov]

Question: what language is Mojo and Modula AI compiler is written in? Using C and/or C++? Or Swift perhaps? Julia?
I recently listened to Chris Lattner podcast with Lex Fridman on this topic. Many things he talked about re Mojo/Modular were already present in Rust. I was wondering why they would undertake such a massive new initiative and code it all in C++ ?? With level of complexity and sophisticaion required I suspect they will not ship it any time soon if Mojo compiler is written in C/C++. Rust could be used to write Mojo/Modular compilers and much of ecosystem, IMO, and Rust should be a better choice than C/C++. Just a personal opinion.

[jofas]

Well, if Chris Lattner is the person in charge of language design and compiler implementation, he probably has a different opinion. He's the author of LLVM and Clang, both massively successful programs written in C++.

[jjpe]

I'm thinking that the entire mojo team is experienced in writing C/C++, and perhaps some of them (eg Chris Lattner himself) have extensive knowledge of Swift.

But AFAIK none of them have extensive experience writing Rust.
I'm not saying they couldn't learn to do so; they probably could, and at an accelerated rate. IIRC Mojo will incorporate some form of Rust's borrowck, so it's not like they don't know how that works or what its benefits are.

There is also the consideration that Mojo is explicitly designed to be compatible with Python and its ecosystem. Since CPython is written in... well, C, it's likely that the Mojo team wants their project to work wherever C works. And as amazing as Rust is, it can only target a subset of all the CPU arches and OSes out there.

[yuribudilov]

to me this sounds like Chris Lattner and his team are not following their own advice. Here we have them telling the world to stop using C, C++, Python and instead jump on their Mojo platform. And yet they are not willing to jump off from C/C++ onto something like Rust.

[jjpe]

First off, what I said is speculation on my part, not anything that's on record by any Mojo team members.

Second, insofar keeping deployment environment parity with CPython is indeed a factor for the Mojo team (and it would be for me if I was on the team, to encourage the organic adoption of Mojo under Pythonistas), Rust automatically has a negative point against it. That's what the last paragraph I my previous response was about.
So no matter what features Rust has, if it can't deploy everywhere that a random Python programmer might be, then it's artificially limiting its own adoption potential.

In addition, it likely doesn't matter too much what language it's written in right now. Did you know that there is a tradition among compiler builders to "bootstrap" their own compiler, i.e. to eventually write the compiler of a language in that language itself?
For example the first versions of rustc were written in OCaml (or some other ML variant) IIRC, and now it's written in Rust.
So you see, ultimately it's not all that unlikely that the Mojo toolchain will be written in Mojo itself as the language matures. Especially so if it delivers on both its performance and Python backwards-compatibility goals.

[kevinmcfarlane]

I'd been sitting on a Mojo Playground invite for a few weeks but hadn't done much with it beyond looking at the intro. Then I received a mail about a new interactive tutorial, so I thought I'd give it a go. And, as it happens, the algorithm he was demo-ing was one I'd just been using in my hand-rolled Python Machine Learning (ML) example that formed the basis for my first proper Rust program. Also, I'd just spent some time going through a Python ML tutorial, so it arrived at the right time for me to take interest.

In brief, the example calculates and times the Euclidean Distance between two vectors in Python and then in Mojo and compares the two (there are a few steps in between, such a adding NumPy and so on) but ultimately he ends with this.

Our Mojo code execution time dropped down to ~13 ms. That’s almost 2x faster than the NumPy which is implemented in C/C++ and 60x faster than the pure Python implementation. Let’s take a look at the Python and Mojo code side by side so you can appreciate how little you had to change the code to see the performance improvements.

So, this was just from adding declarations and strong typing.

I got the same results when I worked through it myself.

The 60x figure was interesting because it was roughly how much faster my own Rust ML program was compared to Python.

Anyway, this suggests that Mojo is at least comparable to C/C++/Rust. Of course, the marketing to date claims potentially much higher speedups. And I do recall seeing a video example which took it up to a much larger factor - hundreds I think - but not 35K or whatever.

I think what I'll try and do next is try my Python ML in the playground and Mojo-ise it. Though I'm not sure whether they let you upload csv files for input.

The playground seemed to be about twice as fast as my dev box when I ran their Python locally. So I should be able to estimate how it compares to Rust.

Update: My Python was running an old Anaconda version. Upgrading to 3.11.1 64-bit speeded it up from 22s to 13s. The Rust is at 0.3s. So 43x.

It looks like I should be able to try my example in the Playground and Mojo-ise it. But that will likely be a task for next week now when I have time.