I am already using agentic orchestration tools where the language is irrelevant, e.g. Opal, Workato, Boomi.

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.

Probably because the creator created both LLVM and MLIR.

I'd assume Mojo does more complex transformations at the MLIR level than Rust does at its MIR level.

Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig.

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.

Honestly that doesn't really feel like a glowing endorsement of the language. "They announced a crazy goal, then rolled it back because they grossly underestimated how hard it was" doesn't give me confidence in either the long-term design or the people making it, and I feel like "a Python-like language" is both a lot less interesting and a lot more subjective. If the discussions in this thread around significant whitespace aren't already an indication, which parts of Python people think are good and which aren't will vary by person, so without saying more it's hard to tell whether it's a a language someone will love or hate.

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.

That is a mistake. Being fully compatible with Python was a big selling point. Now they are just another knock off that wont get enough traction to make a dent. Unless this GPU programming thing is so amazing it takes over the industry with one small niche feature, guess that is the hope.

> its culture is not very collaborative.

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.

Part of that is because there isn’t yet a package format and a central repository. I have a few libraries I would like to contribute or merge with similar projects.

Updated -> https://mojolang.org/.

"Why Mojo?" is now smack bang on the homepage!

2026 and still talking about python indentation? what's next, `goto` gripes?

Oh nooooo, they fucked it up too. Why would someone make a language that’s whitespace sensitive? It’s confounding.

When has it ever been an issue in use?

People complained about this in 1999 but then I used it and it's never mattered.

Significant indentation is why people love python. Can 2 billion people be wrong?