Mojo 1.0
modular.com
modular.com
I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
I hope with 1.0 (havent fully read the article yet) they stop breaking language features / syntax because they did quite a few different changes over time, their overall goal is to be a fully native superset of Python.
I do see this one overtaking Nim over time, which kind of saddens me, because I like Nim for what it is, but Mojo trying to be a superset of Python is a no-brainer for most Python developers. Reminds me of how a lot of Go devs were former Python devs not C++.
Not any more. That was the initial announcement, but I think then somebody actually looked at Python and realised what a complex language it is - so they refocused on being a Python-like language. Python has a reputation for being a simple language, but in reality it isn’t at all.
To preempt all of the inevitable responses: yes, I'm aware that this was started by the same guy who started LLVM and Swift. That doesn't automatically mean anything he comes up with will be great, especially when it's specifically trying to be "like" a language that doesn't really have much on common with either of those; there are plenty of instances of very smart people having an overabundance of confidence when jumping into something they assume they'll excel at and getting humbled. I'd also argue both Swift and LLVM have some common criticisms that very much are in line with the same concern I've expressed here (i.e. long term design suffering due to expanded or pivoted scope; even the name LLVM alludes to some of that history of having a somewhat different goal originally). His name is enough that I'll probably always click to take a first look at anything he comes up with, but I'm not going to ignore things that seem like issues because of that either. Smart people don't need to held to a lower standard because their work should be able to speak for itself.
Why haven't they happened yet though...? Nim is not a young language. Leadership [Andreas] doesn't think they are more important than spending time adding another memory management option.
There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say). The benefit is more "software distribution" for the dependency allergic, but the Nim culture is much less micro-deps than seems in vogue lately. All that said, I think having a more batteries core distribution is valuable - just less than you might guess - and practically that needs delegation.
And knowing the magic keyword search `adix` to arrive at a prerelease library that you yourself wrote. That not's exactly an endorsement for discoverability. Unless I'm missing something, Nimble is essentially stateless. You have no sense of how many times or how recently a library has been downloaded. These are important proxies.
> There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say) … more batteries core distribution is valuable - just less than you might guess
You've been around the community a lot longer than I have. Don't you find this strange? What top 10 language has as weak of a std lib as Nim? [Status all but says](https://status-im.github.io/nim-style-guide/libraries.std.ht...) don't use it.
> practically that needs delegation.
Yeah, I don't think this is the community's strong suit. It strikes me that Araq is tired of explaining himself (but doesn't care to consolidate discussion into ADRs), so when a well-meaning, would be contributor like the parent-poster comes along they get shot down and we lose them.
There are a million ways to define both "top 10 language" and "weak std lib", but the C stdlib is not great and C++'s was bad enough to spawn Boost. And I'm sure many firms all but say "do not use" parts of many top10 stdlibs. In any event, we don't disagree that Nim's stdlib being stronger would be better or that poor delegation or unconsolidated discussion are problems. We disagree on very little, including I'm sure that there is more to a PLang than its stdlib.
What is present/missing in any stdlib (or really in almost anything period) is also often much more subtle and subjective than simple sales pitches one hears. To be concrete, there are "useful" (to someone) things in the Nim stdlib not in either Python's or Go's like std/critbits, std/pegs, ropes, packedsets, intsets, editdistance, etc. Nim stdlib substring search behind "xyz".find() is layered to let you, if you want, pre-build a `SkipTable` (the way regex engines let you pre-"compile" regexes). Subtle in diversity of both kind and granularity and subjective as in "who cares?"
Yes, all that and more is all available in all the ecosystems of anything "popular", but that brings you back to "trust proxies", like "prerelease" numbers, a very weak one, IMO. E.g., I have never used a neovim with a version >0.13, but it's been a trooper; one man's 0.7 is another's 7.0. TRUST IS TRICKY! A count of distinct reliers for some values of "distinct" and "rely" or various update patterns would be better (have their own issues, of course, but at least measures "company" as in "what misery loves", LOL).
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.
Has OrderedTable been ported to Nimony? Does it still have this bug?
https://github.com/nim-lang/Nim/blob/devel/lib/pure/collecti...
I didn't know about Nimony and just took a look.
https://github.com/nim-lang/nimony/blob/master/lib/std/table...
OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an item from a single-threaded sorted list: most painful to remove the 1st element, least painful to remove the last element, but then you still have to rehash the entire table.
What kind of special whitespace requirements do people have?
Functional-style programming has become much more popular since Python was designed in the 1990s, and there doesn’t seem to be a good way to have Python-like significant indentation and also support true anonymous functions.
One interesting PL concept they implement are linear types https://mojolang.org/docs/std/traits/anytype/AnyType/
Guido doesn't want them in the language, as simple as that.
People complained about this in 1999 but then I used it and it's never mattered.
(On other projects, I often wish other languages had formatters as good and standard as the Python ecosystem. I have many complaints about Python but whitespace is just not a problem I've seen)
The trivial kind of raw source generation is still trivial, but I'm guessing you're doing embedding/templates or something?
Also it isn't the only one, many ML derived languages also use indentation, including the famous F#, Standard ML, OCaml, Haskell,....
Very excited for Mojo once it's open sourced later this year.
Chris Lattner said in a Developer Voices podcast interview:
"Swift in a way was syntactic sugar for LLVM, at the very bottom of the stack it could talk directly to LLVM primitives. Mojo does basically that same trick, but it supercharges it by moving to this MLIR world."
Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving.
Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
What techniques?
https://www.research-collection.ethz.ch/entities/publication...
C# compiler is also fully multithreaded since the Roslyn rewrite in 2016.
> The novelty is in parrelizing LLVM, which is traditionally a single-thread code generator.
You said they parallelized LLVM with novel techniques, but then claimed the novelty is the very act of parallelizing it. That's circular, you still haven't explained what are the novel techniques?
Why? Because it uses MLIR? Rust has its own MIR, it's even more not-LLVM-wrapper.
But even if yes, MLIR is part of the LLVM project, so it's technically still "just an LLVM wrapper".
https://mojolang.org is a lot better as a introduction to the language for a programmer, at least for me, compared to whatever I could find on the modular.com website.
Feedback welcome as always and thanks for checking it out! Encourage you to watch ModCon next week for some exciting announcements :)
Ok, yes, this is a substantially better entry point to the language than anything I found by clicking around - maybe link it prominently from the main page?
"Why Mojo?" is now smack bang on the homepage!
I'd love the language and platform be succesful, nevertheless.
You can stick to python and generate mojo or rust or lean.
There is more than one solution to the two language problem.
> "Qualcomm to Acquire Modular"
That's linked from their news section. If I read between the lines here what happened is the VC money ran out and they arranged some kind of acquihire. That obviously raises a lot of questions about what will happen to Mojo and the intentions around it. The merger was completed a few weeks ago so apparently this is a done deal. Them wrapping a ribbon around the 1.0 a few weeks later is a bit suggestive.
The modular front page reads like it was trying to pitch the whole thing as a competitor to other inference platforms like open router, replicate, bedrock, etc.
I'm sure there's more to it and that the tech was amazing. But the acquisition raises a lot of questions about the future of the whole thing. An OSS move at least would allow people to continue working on Mojo independently from Qualcomm. I assume some people in the team might be moving on post acquisition.
And the main use of the language (and justification for the VC money) was always the engine built with it, which I have absolutely no opinion on.
Honestly, the promise of the language is immense. Ownership semantics that have much better ergonomics and are much more teachable than Rusts, and eventually a relatively smooth teaching path from Python to Mojo would make Mojo a default first modern low level language for many people coming in. Whether this will be relevant in the LLM world we live in now, where you can just take your Python prototype and have it be rewritten in Rust, who knows...
The evolution of iPaaS low coding tools.
Just like you can take some high level code in a dynamic language and expect the JIT compiler to do the best every time, under completly different execution patterns, so will LLM based development eventually become like that.
COBOL is already laughing at the efforts to write so much English text to keep AI on track.
Sorry, but what's the pitch?
https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...
Much better options out there. Python already has libraries like Pydantic that offload performance to functions written in Rust under the hood.
Hmm, I've been under the impression that at one point they said it'd be 100% FOSS by the time 1.0 hits, but maybe I misunderstand/misremember the details. But I remember they'd said it'd be FOSS in connection with 1.0, seems weird to do it this way instead of waiting until it's all FOSS then cut 1.0.
Make of that what you will.
A compiler promising source stability is a different commitment than the compiler’s code being ready for outside contributors. Which is also different to having ABI stability, which took until 5.0 for Swift to achieve (I think Mojo does not have ABI stability as a goal as it doesn’t have to link to OS frameworks).
I feel like they're going to remain closed until Qualcomm is convinced they can't make any money from it being so.
If Mojo's goal was to make evolution easier, they would have a limited closed beta like what Jai does. But they're not doing that; they make the toolchain available to everyone, they just did this marketing push around releasing version 1.0 of their language. They're making it harder to make breaking changes by seeking users among the general public.
I have no idea why you started talking about outside contributors though, nobody's arguing that they should accept outside contributions. You do t have to do that. It's a completely orthogonal issue to what we're talking about, which is releasing the code under a FOSS license.
Clang actually has replaced most GCC forks exactly because vendors can keep the fork closed source.
AMD/NVIDIA/Intel now having first class support for Python DSLs or GPU JITs for their APIs, and Julia as well.
It was just a different culture. There was no expectation that everything should be free.
In fact, GCC was largely ignored until Sun decided to split SunOS into two SKUs.
As I said, C was not "closed source", it was distributed with source under a proprietary license. And "all the UNIX clone vendors" didn't exist for years after the UNIX tape was first released. And they weren't "clones", they were enhanced supported versions of the AT&T system. I worked for nearly a decade for the first of those commercial UNIX vendors, ISC ... the other prominent ones were SCO and Wollongong. (Sun came along later, based on BSD UNIX, developed for the VAX and of course derived from AT&T UNIX ... none of these were "clones" ... the first of those was Minix, and then GNU/Linux). We all distributed UNIX with the AT&T C compiler. Eventually ISC wrote their own C compiler for IBM's AIX project because IBM always had special requirements ... I don't know whether we distributed the source or not.
But the point is that this was nothing like the situation with Mojo, which currently has not released the compiler source ... which is nothing like what people on this page are writing, because it will be open source SOON, probably coincident with the conference later this month.
I won't respond further about this.
The alternatives would be stuff like CUDA
OTOH Python itself is the world’s most popular programming language, yet has only recently had the money to support more than a single full-time developer.
This doesn't compete with Python.
Like if someone wrote a competitor to VHDL that looked like TEMU Python... Python would not be its competitor, VHDL would.
License-wise, Mojo reminds me of paid Borland compilers that were in vogue before I was born. Even if it's open-sourced, what incentive does Qualcomm have to maintain a happy path for Metal deployment? Mojo might actually be the best way to program Apple GPUs (on a technical level) and it would still lose due to politics.
Look at the Asahi Linux effort, for instance...
https://developer.nvidia.com/blog/cutile-jl-brings-nvidia-cu...
Mojo addresses the actual need to write code in other languages, such as C++ or CUDA, for low level and hardware specific work.
But I wonder if it has already missed the AI hype cycle, when a lot of low level code is being written. I'm not sure how the developer ecosystem will react now.
Lastest OpenCV 5 release notes also had a lot of LLMisms.
I guess that's the new normal. Still, I am very hopeful for Mojo.
Hard to decide if the blog post is wild, or people's visceral reactions to it.
I've said it before: I believe the obsession in trying to figure out if something is AI generated will soon be classified as a mental disorder.
I think AI use will soon be classified as a health risk worse then smoking, drug and gambling.
Did they think that image would make them look fun or interesting? Because it's exactly the opposite.
Yes, so basing confidence on it is totally bogus. Such comments are cheap and add nothing to the discussion of Mojo reaching 1.0 status.
Not to worry though, if there’s nothing webshit accessible in the content there’s surely something wrong with the CSS to complain about!
Unless the idea is that, in 2026, you assume your audience is an LLM that is ingesting and summarizing your content for the end user and that no human will actually read what you wrote so you don't actually need to care about signals of quality or trustworthiness. The AI generated illustration seems kind of superfluous if that's the case, though.
So maybe an AI image isn't the worst.
Yeah, that really made me triple-check if I visited a fake SEO spam website instead of the official OpenCV one. The fact that their blog looks exactly the same every single low-effort AI content farm doesn't help either.
It's all just spam, filler content and I did not ask for that.
I tried Mojo a bit early on and decided to come back to it when it was more complete, and in the interim I read some comments somewhere that the superset-of-Python part was being walked back from.
On https://mojolang.org/docs/roadmap/ it's stated (Phase 3) that "Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't."
I feel like that "full superset of Python" part was part of the appeal of Mojo.
Personally I'm kind of tired of 97% python-compatible this-and-that. Python itself has enough of a history of incompatibility and the cognitive overhead in switching might be easier with just moving to a totally different language. But maybe not — it depends on the details I guess.
Honestly reading through the documentation more and more I'm more and more confused about what the 1.0 release actually means.
It seems like a deliberate pivot towards creating an AI-era language which make GPU programming as easy as writing Python.
It absolutely was, but IMO was never going to happen. Python has a reputation as a simple language, but it really isn’t. It’s a very complex language hiding behind friendly syntax.
I think once the Mojo team realised that, they had to adjust their expectations.
Python is C++ level complexity, when one fully understands the runtime, its dynamic capabilities, the C API, the standard library, the OOP model reboot on 2.0 with new style classes, all breaking changes that happen between releases, and naturally one doesn't know before hand what are the exact requirements to execute any random Python script.
Why not now though? Why wait for 4 more months? What magic is there to hide in just making it source available at least.
That's the favorable interpretation, atleast.
At this point I find it deeply troubling that it isn't open source. I respect Chris I know folks who have worked with him and but at the end of the day I feel too weird about this entire closed source programming language thing.
If we complain to Nvidia about there weird closed source limitations, I think Mojo is just as bad. You don't even know what your compiler might be doing, and if it does something wrong you can't fix it, you now have to file a bug and wait until the gods from above come to your rescue.
I have had similar issues with drivers, I have faced soo many driver bugs in my work and the answer is always write more code that works around it somehow, this warp level is bad, this feature doesn't work with these values, etc. etc. Why can't I fix them, I have often on Linux just pinged the Mesa team about driver bugs with a rough draft of a patch and gotten it fixed, I can even patch and run it myself when I am in a hurry.
I feel like atleast making stuff, source available like Unreal should be the baseline for any "core" software where a bug could possibly be a major blocking issue for a developer. Windows and Mac are very bad with this.
Mac's CoreML has had soo many bugs over the last couple years I have had to email someone I know at the company to get them fixed or try to get into contact with someone.
Intel's drivers have had bugs too but I have had more contacts there which is a wash. AMD well it's AMD...
Either way closed software sucks I don't want to use fully closed stuff unless I don't have a choice people can make what they want of it. I don't really care.
I care much less about just foss.
I made a language design some years ago. More recently, I had Claude carry out some of the implementation to see if it would work. It did not. I tried again, hand-tailoring the IRs and many of the main algorithms, and it did better but the self-hosting compiler still violates many of the design principles and even behaviors in the design document. I have spent six months of free time reviewing and fixing it myself, and it's just a small pet project. I would not open-source that code any time soon.
I must imagine Mojo is in the same situation.
Basically, same raison d'etre as that of Julia.
Mojo is a fully ahead-of-time (AOT) compiled systems language. Julia is much more dynamic, and its AOT compilation story is still quite weak. Mojo also has explicit memory management, unlike Julia and its real time unfriendly garbage collector.
Mojo also has the concept of ownership, similar to Rust, while Julia does not.
Mojo is being pitched as an efficient, general purpose, Pythonic systems language which can target a variety of hardware types. That seems like a good target to me, I hope it's successful!
One thing to keep an eye on is whether or not a Windows port emerges after it's open sourced...
Am I understanding the current state of things correct?
"AI slop image below the headline" is an unmistakable mark of low-quality content written by a sophomoric AI evangelist. Let them keep watermarking their own content.
They should show some performance comparisions between PyTorch and Mojo, PyTorch+kernel compilation + Triton vs Mojo, ThunderKittens vs Mojo.
The fact that they release 1.0 without doing this, I think says a lot. I personally haven't even started looking into Mojo because of the closed source stuff, but usually you can tell what's going on by looking for what's obviously missing.
LLVM has such a cool tutorial, eventhough I haven't written a programming language myself, it was excitung to go through it to see how static programming languages are lowered to SSA form.
Mojo should have something showing how to write a super fast matmul and especially what's interesting for me is a fast linear attention kernel, as that's where PyTorch is getting much harder to use.
EDIT: I guess this kind of answers my curiosity: https://programming-journal.org/2023/7/2/
But mojo is a superset, not a subset. So why not use a subset, infer what you need and generate mojo?
I've never seen this question actually presented to the company and discussed in more detail.
But I hope they succeed, it's a very interesting approach. Then I will jump on it later on. S
LLMs have enough problems distinguishing between major versions between packages, e.g. where all the imports were moved around and renamed.
python superset would have been perfect.
I do hope the language thrives and gets a community.
All the best to the modular team.
This gave me a chuckle. When I think of languages evolving their standards, I do think of C++. But not, you know, in a good way.
What's wrong with people?
awesome
(And now in the age of LLMs, the barriers to get started with a new programming language are lower than ever)
Additionally, anyone who has seen how Swift evolved should be wary of Lattner saying "the language is mostly stable", or even "the language is released".
Nvidia is also a major contributor to MLIR, which they use for TileIR and ClangIR, so should a compatibility break occur it wouldn't be entirely up to Mojo to fix it.