upvote
Their communication definitely needs work. I listened to the interview with Chris on the Lex Friedman podcast a few years ago. Back when the pitch still was "minimal python superset that allows us to make it go voom". It wasn't a bad pitch. But it's gotten a lot murkier since then apparently. And obviously pitching a new language just before world plus dog was about to switch to delegating programming work to AI agents wasn't great timing.

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

reply
The Python tie in was always a sales pitch. The technical pitch was "a language built around MLIR taking all the lessons learned by Rust and Swift on board, with an eye towards Python interop". There were MLIR intrinsics and extensive discussions of the ownership model from the start, but never even an attempt to have classes.

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

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

reply
I felt the same way, even after browsing around on the website, and somehow I got to https://mojolang.org/docs/manual/quickstart/, which brings you to mojolang.org instead, which is the real website of the language it seems, instead of "Modular" which I guess is the business.

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.

reply
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime in the realm of Zig, rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.

Very excited for Mojo once it's open sourced later this year.

reply
> LLVM is still involved, but they are using it differently than say, Rust or Zig.

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

reply
> Performance wise it's the first language in long time that isn't just an LLVM wrapper

Why? Because it uses MLIR? Rust has its own MIR, it's even more not-LLVM-wrapper.

reply
Probably because the creator created both LLVM and MLIR.
reply
I'd assume Mojo does more complex transformations at the MLIR level than Rust does at its MIR level.
reply
First, I'm not sure. Rust has MIR optimizations and also other transformations.

But even if yes, MLIR is part of the LLVM project, so it's technically still "just an LLVM wrapper".

reply
MLIR is more a library for building a compiler than a compiler itself IIUC. LLVM can be thought of similarly, but IMO, it's more self contained.
reply
How are compile times compared to Rust? Zig? Go?
reply
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.

reply
> Modular found ways to parralize LLVM code generation by introducing novel techniques

What techniques?

reply
I think they had a good dive here https://www.youtube.com/watch?v=SEwTjZvy8vw The gist is that MLIR (unlike LLVM) was designed to be multithreaded so the whole stack above LLVM IR is parallel, and then LLVM is used as a per-function codegen tool in parallel, so although LLVM itself is single threaded there are multiple seperate contexts of it. also I think they wrote their own linker.
reply
That is hardly novel, here is the thesis for the Oberon multithreaded compiler from 2003.

https://www.research-collection.ethz.ch/entities/publication...

C# compiler is also fully multithreaded since the Roslyn rewrite in 2016.

reply
The novelty is in parrelizing LLVM, which is traditionally a single-thread code generator.
reply
So basically LLVM catching up with times.
reply
From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.
reply
Mojo compiles with O2 by default, it is similar to Go here. Release build is the default, debug is something you opt into. It is still very fast nonetheless
reply
Whoever behind the company communication have done an incredibly terrible job. They start with an extremely unnecessary polished Steve-Jobs-alike debut video when they have zero stuff to offer, while the founder name is already immensely trustworthy. Then follow with a very ugly AI-image-heavy website and blog posts, only to be reverted back to plain website later.

I'd love the language and platform be succesful, nevertheless.

reply
It's supposed to be (currently) a fully native, Python-like language, but for GPUs primarily. Though I am seeing it as having a future as a fully native Python alternative that might get interesting.

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

reply
> their overall goal is to be a fully native superset of Python

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.

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

reply
Language-feature-wise it seems like Nim will be competitive. Ecosystem-wise… yeah it's kind of a nonstarter over in Nim land. There are not many go-to libraries and its culture is not very collaborative. People seem more enamored at what they can hack together than what they can contribute to.
reply
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.
reply
You'd likely enjoy: https://mojolang.org/nightly/docs/vision/ for why we created it, and there's https://mojolang.org/nightly/docs/faq/ as well :)

Feedback welcome as always and thanks for checking it out! Encourage you to watch ModCon next week for some exciting announcements :)

reply
This page really helped me to put it into perspective against Python:

https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...

reply
For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).
reply
I think they wrote an internal memo and by mistake they share with the public. I read because one person I know works there, now I don't know what my friend does there either. Sounds like another VC eating company.
reply
deleted
reply
https://github.com/py2many/static-python-skill

You can stick to python and generate mojo or rust or lean.

There is more than one solution to the two language problem.

reply
i think the main idea is that by using MLIR[1] instead of the usual LLVM path it can target gpus directly

1. https://mlir.llvm.org/

reply
Do you mean the Modular site or the Mojo site? https://mojolang.org/ makes some clear statements.
reply
Python, but good.
reply
So, without significant indentation?
reply
2026 and still talking about python indentation? what's next, `goto` gripes?
reply
its not becauae its 2026 that stupid indentation got better
reply
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.

reply
It’s an issue when generating python, I can tell you from experience. It’s also a pain to not be able to safely rely on an auto formatter
reply
Every python developer I know uses an auto formatter today, and never needs to think about it (ruff, black). It's not ambiguous and is immediately visible if something has the wrong indent.

(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)

reply
Today and forever, I was using ActiveState IDEs back in the day, I started using Python in version 1.6.

Also it isn't the only one, many ML derived languages also use indentation, including the famous F#, Standard ML, OCaml, Haskell,....

reply
You missed the point. I’m well aware python has formatters, I use them and implemented my own. The point was that when generating/manipulating python code you cannot just generate in whatever format then run a formatter. you need to carefully keep track of the exact indentation at place where the code in written
reply
Fair. That is a very slight friction on what is quite a small niche, though (compared to the wider ecosystem of developers). And most that need similar will use AST or runtime construction.

The trivial kind of raw source generation is still trivial, but I'm guessing you're doing embedding/templates or something?

reply
It’s definitely niche!
reply
If I were doing this, and the code generator was itself in Python, I'd probably use ast and/or tokenize to avoid having to manipulate literal whitespace.
reply
Have you never tried to paste python code from the internet into an editor? At least half the time the indentation is screwed up and I have to go in and figure out manually where to put the spaces in. Indentation gets screwed up by pasting in other languages too, but with those I can generally tell the editor to reindent and it can because the information is included in the source code.
reply
Python's significant indentation does have real costs, but they mostly don't affect experienced programmers working on real codebases in real editors or IDEs. Rather, they are things like, it makes the REPL more cumbersome, and newbies sometimes find that code they copy-paste from the Web mysteriously fails to work.
reply
Oh nooooo, they fucked it up too. Why would someone make a language that’s whitespace sensitive? It’s confounding.
reply
Why would someone make a language where the programmer and the interpreter have two different ways of figuring out where blocks start and end?
reply
at the closing curly?
reply
Programmers look at the indentation.
reply
this discussion is so dated...
reply
llms prefer indents too
reply
They seem to be quite okay with oneliners, have you not noticed ?
reply
To weed out programmers who don't indent.
reply
identation should be something the compiler does not care about
reply
Like with array base indexes, there are plenty of languages that start with something other than zero, and many that use indentation, including a few well known in hacker circles, Python isn't alone.
reply
I never understood this.

What kind of special whitespace requirements do people have?

reply
I like significant invitation, but I still wouldn’t choose it if I was designing a language today.

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.

reply
True anonymous functions has nothing to do with indentation, ML derived languages are also indentation based.

Guido doesn't want them in the language, as simple as that.

reply
As I understand it, Mojo’s goal is to be able to match state of the art performance for parallel algorithms and be able to use the exotic GPU hardware. A functional style is not necessarily productive in that context.

One interesting PL concept they implement are linear types https://mojolang.org/docs/std/traits/anytype/AnyType/

reply
Haskell has significant indentation and anonymous functions.
reply
Haskell's significant indentation is, in my experience, much worse than Python's at fading into the background by matching what you would have done anyway.
reply
Scala 3, F#, CoffeeScript, Nim, Haskell, Elm, PureScript...
reply
deleted
reply
It's really not that bad
reply
Significant indentation is why people love python. Can 2 billion people be wrong?
reply
deleted
reply
I could get started about religions now...
reply
yes the majority is often very wrong
reply
I mean, it feels like "Python, but aiming at a completely different vertical that values native compilation and a borrow checker"? Which is not quite the same thing
reply