Swift Creator's Company Builds New Programming Language 'Mojo' - a Python Superset

While working at Apple, Chris Lattner designed Swift to "fully leverage the power of LLVM," and "led a team for a while at Google to try to move Swift out of its Apple comfort zone, to become a replacement for Python in AI model development." That's according to a blog post by Jeremy Howard, an advisor to Lattner's Modular AI (which he co-founded in 2022 to build a next-generation AI platform for developers).

"But sadly," Howard writes, Swift "did not receive the support it needed from either Apple or from Google, and it was not ultimately successful." And yet... [W]hilst at Google Chris did develop another project which became hugely successful: MLIR. MLIR is a replacement for LLVM's intermediate representation [or IR] for the modern age of many-core computing and AI workloads. It's critical for fully leveraging the power of hardware like GPUs, TPUs, and the vector units increasingly being added to server-class CPUs.

So, if Swift was "syntax sugar for LLVM", what's "syntax sugar for MLIR"? The answer is: Mojo! Mojo is a brand new language that's designed to take full advantage of MLIR. And also Mojo is Python.

Wait what?

OK let me explain. Maybe it's better to say Mojo is Python++. It will be (when complete) a strict superset of the Python language. But it also has additional functionality so we can write high performance code that takes advantage of modern accelerators...

Whereas Swift was a brand new language packing all kinds of cool features based on latest research in programming language design, Mojo is, at its heart, just Python. This seems wise, not just because Python is already well understood by millions of coders, but also because after decades of use its capabilities and limitations are now well understood. Relying on the latest programming language research is pretty cool, but its potentially-dangerous speculation because you never really know how things will turn out...

A key trick in Mojo is that you can opt in at any time to a faster "mode" as a developer, by using "fn" instead of "def" to create your function. In this mode, you have to declare exactly what the type of every variable is, and as a result Mojo can create optimised machine code to implement your function. Furthermore, if you use "struct" instead of "class", your attributes will be tightly packed into memory, such that they can even be used in data structures without chasing pointers around. These are the kinds of features that allow languages like C to be so fast, and now they're accessible to Python programmers too — just by learning a tiny bit of new syntax...

I can't begin to describe all the little (and big!) ideas throughout Mojo's design and implementation — it's the result of Chris and his team's decades of work on compiler and language design and includes all the tricks and hard-won experience from that time — but what I can describe is an amazing result that I saw with my own eyes.
Mojo hasn't been released to the public yet, (other than an online "playground" with a waitlist where they're "rolling out access slowly.") But the blog post notes that creating a programming language's syntax is usually complex, error-prone, and controversial — a problem Mojo neatly avoids by "outsourcing" its syntax to an existing language, "which also happens to be the most widely used language today."

And "As a compiled language, Mojo's deployment story is basically the same as C," the post argues. [That is, "you can literally just make the compiled program available for direct download. It can be just 100k or so in size, and will launch and run quickly."]

"This means that Mojo is far more than a language for AI/ML applications. It's actually a version of Python that allows us to write fast, small, easily-deployed applications that take advantage of all available cores and accelerators!"

Yet more python fragmentation

[xack]

There is still lots of unpatched python 2.7 hanging around and you even need rust to compile python now. Meanwhile it took over 20 years to implement thumbnails in gtk. This is why people say screw it and stay in their walled gardens.

Re:

[Njovich]

'Fragmentation' was an apple originating criticism on Android about Android supporting different devices with different screen sizes. This was because early versions of iOS had a ridiculous UI implementation that didn't support dynamic window sizes. Since Apple has fixed this issue you don't hear from them about fragmentation anymore. Just like Android totally dominates smart phones, Python is rapidly becoming the biggest language out there thanks to this 'fragmentation' as you call it, or 'widescale and di

Re:

[UnknowingFool]

This was because early versions of iOS had a ridiculous UI implementation that didn't support dynamic window sizes.

That is because early Apple devices did not have many window sizes to worry about. It would be a fair criticism now for iOS and Apple devices. Complaining about Apple not implementing something they did not need at the time seems pointless. That is like criticizing Nintendo for not allowing up to 8 players on the NES like they did on the Game Cube when the NES did not have connections for more than two controllers nor games that could handle 8 players nor the hardware to handle that many players.

At the tim

Re:

[Njovich]

Complaining about Apple not implementing something they did not need at the time seems pointless

They didn't need it unless they were ever going to release a device with a different resolution. Which they did so they did need it. I take it you were not a mobile developer back then? Because you had to separately implement things for different screen sizes the moment they started releasing different device sizes. Then when they came with a solution for the shitshow you had to re-implement everything again.

Re:

[UnknowingFool]

They didn't need it unless they were ever going to release a device with a different resolution.

That is not correct logic. The early iOS versions were targeted to early existing Apple devices. At the time they did not need to device the iOS YET to adjust for dynamic windows. The word YET is very important in this context.

. I take it you were not a mobile developer back then?

And why would you assume that I did not. I also developed on industrial scanners. Thankfully each client understood that our application would need to be customized to every device they had as scanners had so many variation in screen sizes, barcode compatibility, wireless and wired co

Re:

[drinkypoo]

Apple should have done dynamic windowing EARLIER. But your contention that they should have released it when they did not need it is ridiculous at best.

Apple has a long history of not implementing features until long, long after they are needed. My favorite example is graphics acceleration. Macintosh computers had literally none of it in hardware until Quadras came out, unless you bought a graphics card that cost as much as a whole computer (and had as much processing power as the computer, too!) despite being an all-graphics computer with no hardware text mode. And it was daft to not plan for devices with varying screen sizes from day one. That's just mak

Re:

[alvinrod]

The criticism was somewhat valid. Android never really took off in the tablet space because most apps were phone apps that were just meant to scale to the larger screen size and didn't. Even in the phone space iOS still does see some benefits from having a more limited number of configurations to target, but that's just a trade off for having more freedom in terms of hardware choice.

These days Android fragmentation has far more to do with the OS version than anything else. There're still plenty of people

Re:

[Njovich]

Android never really took off in the tablet space

Android is now nr1 in the tablet space though (although Apple of course has an extremely respectable position there). For the early years I think it was more of a chicken and egg thing where there were much less users on Android tablets so there perhaps less effort was put into the tablet apps. I can't really think of an iOS tablet app that you really were missing out on with Android though, perhaps some games?

These days Android fragmentation has far more to do with the OS version than anything else.

OS version is not any issue for Android app developers unless you talk about very specific feature

Re:

[jythie]

No, this kind of fragmentation is pretty bad. Python really struggles with fragmentation, and is popular despite it, not because of it. You can extend capabilities via libraries and not 'fragment', you only get the problem when you decide to change the language, and I have never heard a python programmer gloat about that.

Re:

[phantomfive]

If all it takes is changing "def" to "fn" (and using types) to have faster code, then that's kind of great.

Lack of types is one of the serious weaknesses of Python anyway in any project larger than a few files.

Re:

[HiThere]

It depends on what you mean by types. For some purposes the current Python typing system works well. It doesn't work well for optimization, or if you don't use it. (Yeah, it's a lot less than perfect, but NOBODY has a perfect typing system. Ada had every length of string be a separate type, and that's not a good answer either. I would guess that there is no generally perfect typing system.)

OTOH, I do think that Python should have a "mandatory typing" switch, and another that says "assume types offered

Re:

[phantomfive]

When I use Python I declare types for all my function parameters. It just makes everything easier.

Re:

[jythie]

Do you mean you hint types? Unless you are working in the numpy (or similiar) ecosystem, python does not declare types in function parameters.

Re:

[greytree]

"OTOH, I do think that Python should have a "mandatory typing" switch"

Which MUST be invoked like this. Because.

    use strict;

Re:

[jythie]

Which kinda makes you wonder why the person felt it was necessary to change the language syntax rather than use a decorator or some other existing tool for extending python's capabilities. Over the years I have grown deeply suspicious of people introducing new pet languages, they always seem to turn out to exist for the sake of existing and not able to do anything actually new.

Re:

[greytree]

"Look at me everybody - I invented a new language!"

"Look at me everybody - I added a new decorator to Python!"

I wonder why they choose the former ? :-/

Re:

[jma05]

You can sort of do the same with Cython for a long time now. Just change def to cdef.

Oh, no, "Mojo" confusion!

[Ecuador]

I know Perl is not that popular anymore, but one of the most modern frameworks for Perl development, Mojolicious [mojolicious.org], is usually referred to as "Mojo". Why would they consider such a name for a Python superset?

Re:

[Warren416]

I am sure there are 10 less obscure things than that Perl library that used Mojo in their name.

Re:

[angel'o'sphere]

Well, you could read the summary, and you had the answer.
Most likely, just like myself: they never heard about Mojolicious.

Re:

[Daina.0]

M$ is King of Misnaming. They have many products that overstamp existing product or technology names--.NET, Typescript, C#, etc. Don't bother looking up the last two. They've pretty much been obliterated.

Do your research before reusing/stealing/overtstamping an existing product/concept/technology name to confuse the marketplace.

I worked briefly for a company named Mojo Marketplace, a Wordpress template aggregator/sales site. Now their name will have confusion. They should sue.

Re:

[Joey Vegetables]

My system has 196 direct dependencies on perl, including among many other sudo, qpdf, nss, openssl, much of Qt5, git, gimp, samba, curl, rsync, wget, CUPS, coreutils, llvm, glibc, xscreensaver, libX11, and the Linux build system. It may not be exciting, but it sits at the foundation of a lot of important software.

Waiting for this for years

[wattersa]

My whole challenge with a recent computer vision project is maximum performance, and we initially chose C++ and x86 assembly because we simply don't think that interpreted Python is fast enough for what we need to do. If what they are saying in their product unveiling post is all accurate, in addition to having high performance, Mojo will save a large amount of time and money by letting us recycle existing Python code and knowledge instead of essentially creating new C++ and assembly code. Chris has an amazing track record and this new project shows leadership in the field. Can't wait to try it.

Re:

[phantomfive]

My whole challenge with a recent computer vision project is maximum performance, and we initially chose C++ and x86

If you were planning on writing in x86 assembly because you needed speed, this will not help you.

Re:

[jythie]

I am pretty skeptical. A the data science and Ai communities have already demonstrated, there is already a well understood pattern for adding high performance domain specific capabilities to python. By creating a new language instead of a library, kinda smells like someone who wanted to do things a 'fun' way instead of a 'good' way, which is not a good sign. I mean I get it, designing languages, working with compilers and interpreters, that stuff is REALLY fun and there is a pent up demand for doing it s

Re:

[SoftwareArtist]

kinda smells like someone who wanted to do things a 'fun' way instead of a 'good' way

In a lot of cases I'd agree with you. But when the "someone" is Chris Lattner, I'll give him the benefit of the doubt. There aren't many people in the world who know more than him about the "good" way of designing languages and language infrastructure.

Re:

[dadaz]

There are plenty of ways to use Python for non-performance critical paths, and optimize the few bits that eventually really require it, without shoehorning a new language.

There are also plenty of existing Python based ML frameworks, which are both simple to use (PyTorch and JAX more than TF), and have zillions of models written with them as baseline for developers to experiment with.

I honestly see Mojo coasting with Swift in the corner of the forgotten languages.

Re:

[greytree]

"Chris has an amazing track record and this new project shows leadership in the field."

Are you a programmer or someone in HR ?

And you forgot to mention that Chris pushed the diversity boundaries with these empowering new paradigms.

No thanks!

[backslashdot]

Put a fork in this fork.

Re:

[HiThere]

This may have its good points. Think of it as a test-bed for new Python features. (They *did* say "superset", so it ought to be compatible.)

Curious timing

[Impy the Impiuos Imp]

AI is exploding for investment. And now, we wait. (Auctioneer drawl. That's farmyard auctioneer, not Christie's) Hey, bidibidibidobidibillion budibibibilll do I have one one billion dollars? One billiob...One billion dollars! Hey bidibidibidobod one one hey bidibidibidibidi one one...one point one billion dollars! Hey bidibidibidibidibidi one two, one two bidibidibidibidibidi one two...

Etc. Good luck!

Oh great...

[SuperDre]

Yet another language which does the same as many already on the market.

Re:

[evil_aaronm]

Your point would be better taken if you named at least two or three of the "many." I'm kind of curious what languages you're thinking of.

Re:

[SuperDre]

any language which has been already on the market (for decades) with one of the older ones being C.

Re:

[angel'o'sphere]

Which sounds as if you want to say: all (programming) languages do the same. You had kind a point ... but actually you have not.

Re:

[SuperDre]

There are already so many languages on the market for decades, and in reality, most of them do exactly the same, only a different syntax.

Re:

[angel'o'sphere]

That might be true since C++ got lambdas ... before that: not so much.

And there are still plenty of languages which are not just the same as the other in different syntax.

SmallTalk e.g. and the languages around it. Or shells ...

Actually I have no idea if Go and/or Rust support functional programming the slightest ...

Re:

[jythie]

They pretty much all do. Outside edge cases like functional languages or ones that lack OOP, the languages themselves tend to be pretty similar in their capabilities. The power really comes from libraries and ecosystems, not languages.

Re:

[jythie]

I think a big part of the problem is that there is so little actual demand or need for new languages, that the people who enjoy constructing them try to shoehorn the solution into problems they find. People who start creating incompatible compilers and interpreters really need to stop and ask themselves 'is this really the best solution or is it simply the coolest solution?'

Re:

[bill_mcgonigle]

Perhaps instead of inventing yet another language Chris should have just improved an existing language to address an unserved market.

Somenody let him know.

Another language ?!

[TronNerd82]

I'm still using Objective-C!

Snakes, why'd it have to be snakes...

[SuperKendall]

This new attempt seems like a great idea to actually make something that will get used by the AI community.

As much as I don't like Python and wish the Swift AI stuff had continued and succeeded, I have to acknowledge that Python has a huge lead in being the official programming language of AI already, and that's before this new superset is even factored in...

So, this new attempt could easily build some traction. Especially if it's quickly adopted by popular Python workbenches (if that's the right term).

I w

Re:

[jythie]

The AI community already has well established python tools and pathways for bringing in new capabilities via libraries rather than language changes. Creating something incompatible that could be done via systems they already have is going to be a hard sell to people actually doing work.

Python, like R, is already extremely easy to extend, even adding syntactic sugar to make it behave like other systems. You need a damn good reason to create a new incompatible superset of a language itself, and I am not

Looks to have some benefit

[SuperKendall]

The AI community already has well established python tools and pathways for bringing in new capabilities via libraries rather than language changes.

Very true, but I think this new language could have something to offer to those working on really large models that need even more advanced performance than just accelerated math libraries....

I am not seeing anything in this that lends itself to such a solution.

I don't know for sure either but if Chris Lattner does, I would not write it off.

And don't forget par

better than ONNX?

[oumuamua]

The current way to deploy your deep learning models is to export to ONNX. https://onnx.ai/onnx/intro/ [onnx.ai] Then you can run it in Javascript, JAVA, Rust, C, whatever language you want. One huge problem is rebuilding the input processing code for the model in the new language. Another problem with ONNX is the export does not always work, it is often one step behind on the newest opsets. Then lots of other gotyas to watch for.
If Mojo is less a headache than ONNX, I'm in.

Someone invent an add-on for this named Jojo

[jfdavis668]

Won't someone please think of the children.

"Strict Superset"

[devloop]

"It will be (when complete) a strict superset of the Python language. But it also has additional functionality"

It will be strict, but it will be a superset, but it will also have some more stuff!

Sounds like a nonsense statement.

Re:

[richbaker]

It’s not a nonsense statement. Mojo being a strict superset of Python means that all Python code is valid Mojo code but not vice versa.

Re:

[Anonymous Coward]

That's the definition of "strict superset" [wikipedia.org].

Re:

[HiThere]

It's not nonsense, but it does sound unlikely. Being a superset would mean that all valid Python (which version) code was valid Mojo code. Strict would mean no exceptions. And I really doubt that they can live up to that promise. Cython has been trying for years and still can't make that claim. And it's a moving target, if you don't specify a particular version.

Re:

[Visarga]

I think they keep a regular Python kernel on hand to run legacy Python.

Re: "Strict Superset"

[mugurel]

If a set A is a superset of a set B, that doesn't rule out that A = B. "A is a *strict* superset of B" implies A does not equal B. Calling Mojo a "strict superset" of Python is kind of gratuitous, because the only thing that the "strict" qualifier adds is that there is that Mojo is not just Python, but something more, which is the whole point of TFA.

At last! A second new language!

[zephvark]

It is so wonderful to have a choice of programming languages now. I mean, I've been using GWBASIC forever and, although the current version 10,000 does support objects and now allows three characters for variable names, the need to number every line of code just gets ridiculous.

Also, Dijkstra would certainly have written "Classes Considered Harmful" about this situation. Line numbers are clear! Now you have line-numbered objects that are superclassed, subclassed, and overloaded, and my Gods you have no idea of what is going on.

I've been keenly watching this other new language that's been walking through the alphabet but, they're only up to "C", so it's going to be a long time before they finish that one.

Re:

[angel'o'sphere]

Well, D is out since 20 years, you could skip E and jump to F# ...

Re:

[HiThere]

There was a language called E a decade or so ago. I don't know if it ever got past beta development, though.

Zen of Mojo

[YetAnotherDrew]

There should be a strict superset of one obvious way to do it.

Re:

[HiThere]

Unfortunately, the obvious way to make an improved Python would not be a superset. It would include things like no GIL (Python 3.12 is a step towards that), but it would also mean that declared types had to be honored, which would prevent it from being a superset.

Re:

[jythie]

And in this case, it kinda sounds like all the person is really doing is creating a library and building its syntax into the interpreter.

Re:

[Visarga]

I think the main focus is on ML workloads - parallelising on multiple CPUs, GPUs, considering the sizes of the cache for each of them, the number of cores, etc - the same matrix multiplication is better expressed in a different way. They are doing this low level planning of computation, including loop unrolling and sliding windows - they call it language-integrated auto-tuning. This is the hard part of writing CUDA kernels. They want to make it much more accessible to ML researchers.

This web design is least expected

[Ajay Anand]

Using slideshow to showcase code is a very bad idea. Why does the image change in the middle of reading the code?

If you want to know more... 35,000x?

[AlanObject]

Check out Jeff Delaney's video on Mojo [youtube.com]. As always he does a good job at getting to the essence of it with a few bits of quirky/nerdy humor thrown in.

I have been using Python on and off for years, and I never really had the impression that it was "slow." Implement or use a REST interface, a CLI that does something. Maybe some graphics tasks. I guess I just never used it for anything big enough for it to matter.

The claim is that Mojo can get results on some tasks 35,000x faster than regular Python.

Re:If you want to know more... 35,000x?

[BobC]

Yeah, the "35,000x" is for Mandelbrot, Mojo vs. "dumb" Python (no Numpy). Once you use Numpy, Mojo is "only" 12x faster, which is still impressive.

Re:

[CalgaryD]

I have actually measured that. C implementation of the same code in C is about 270 times faster than pure python. For simple for loop with some computing thing. 35000 sounds like a stretch to me...

Re:

[dadaz]

Just use Numpy, or Numba or Cython (or even C++ and pybind11) only for the parts that really need it, and there is no need for a new language. Just plain old Python.
Python has outstanding support from both independent developers and companies, with a truckload of existing modules.
Language DuJour has one company backing it (until it is still around, that is), it likely lacks support of many Python features, and roams around the untested land like tumbleweed in the high planes.

Stop it

[CalgaryD]

Python 2 to Python 3 was and is bad enough. Just stop it. Leave Python alone, damn you.

Re:

[greytree]

I had a Python2-3 problem bite me YESTERDAY.

I wonder if Python2-3 was (is) the greatest programming language mistake of all time?

Re:

[jma05]

Not even close.

Re:

[greytree]

Interesting point, well made. Wish I had more time to read your insightful comments.

Re:

[jma05]

"I wonder if Python2-3 was (is) the greatest programming language mistake of all time?" - You mean this hyperbole was full of insight and well argued reasoning that it warranted something better? LOL.

Re:

[greytree]

Have you ever considered that it is possible not to reply to a discussion to which you can add absolutely nothing?

Re:

[jma05]

You are failing to apply your own advice to yourself. Quite hypocritical, no?
I added an opinion to a post which had absolutely nothing but an substantiated personal opinion.
If you back your opinion with arguments on why it is the "greatest programming language mistake of all time", I will provide several arguments why I feel exactly the opposite.

Re:

[jma05]

*unsubstantiated

Re:

[greytree]

Have you ever considered that it is possible not to reply to a discussion to which you are repeatedly adding absolutely nothing?

Re:

[jma05]

Yes, but it never stopped you :-).

"its potentially-dangerous speculation because"

[greytree]

I am glad they know how to follow language rules.

Because we just don't have *enough* languages.

[gestalt_n_pepper]

Let's throw this one out and watch it sink too.