upvote
In their original pitch that was definitely part of it: take Python code, add type hints, get a big speedup. As they've built it out it seems to have diverged.
reply
It was always going to be a long-term thing, if it were even possible. You can't make a compiler that can compile Python into efficient machine code in just a year (which was how long Mojo had been in development when it was announced).

The messaging was changed because people got sold too hard on that, and kept trying Mojo with the expectation that it could compile existing Python code when it couldn't. What Modular did was change the messaging to reflect what Mojo is today, and provide a roadmap[1] of what they hope it'll turn into in the future. As it evolves, the messaging will evolve with it to continue reflecting current capabilities.

1. https://mojolang.org/docs/roadmap/

reply
They also advertised a 36,000x speedup over equivalent Python if I remember correctly, without at any point clarifying that this could only be true in extreme edge cases. Feels more like a pump-dump cryptography scheme than an honest attempt to improve the Python ecosystem.
reply
The modern way to advertise: lie a lot.
reply
Well... the article made self deprecating fun of the click bait title, showed the code every step of the way, and actually did achieve the claim (albeit with wall clock time, not CPU/GPU time).

And it wasn't "equivalent python", whatever that means, they did loop unrolling and SIMD and stuff. That can't be done in pure python at all, so there literally is no equivalent python.

reply
Watch Chris Lattner's interview with Lex Fridman. He talks about mojo as a 36,000x speedup over Python without any indication that you need to think about vectorization to achieve it.
reply
I'm looking at this transcript and I'm getting a different picture than what you describe https://podscripts.co/podcasts/lex-fridman-podcast/381-chris... . Yea, he doesn't specifically say vectorization and multi-threading or whatever but he also doesn't say you don't need some skill to get to huge speedups.
reply
Does he say that you _do_ need skill to get huge speedups?

In fairness it's been a long time since I watched this, but I remember being struck by how obviously dishonest Lattner was throughout. For example at one point he talks about approachin mojo from a first principles perspective, using the speed of light as a limiting factor for what's computationally possible. Complete bullshit. You'd have to be working at the hardware layer for that to begin to be relevant, and even then photonic computation is years away. It's essentially technobabble.

reply
Crypto*
reply
If you paid very close attention it was actually clear from the start that the idea was to build a next gen systems language, taking the lessons from Swift and Rust, targeting CPU/GPU/Heterogeneous targets, and building around MLIR. But then also building it with an eye towards eventually embedding/extending Python relatively easily. The Python framing almost certainly helped raise money.

Chris Lattner talked more about the relationship between MLIR and Mojo than Python and Mojo.

reply
So basically Chapel, which is actually being used in HPC.
reply
I don't know Chapel in detail, I was more thinking Hylo. I don't think Chapel has a clear value/reference semantics or ownership/lifetime story? Am I wrong here?

The Mojo docs include two sections dedicated to these topics:

https://mojolang.org/docs/manual/values/

https://mojolang.org/docs/manual/lifecycle/

The metaprogramming story seems to take inspiration from Zig, but the way comptime, parameters and ownership blend in Mojo seems relatively novel to me (as a spectator/layman):

https://mojolang.org/docs/manual/metaprogramming/

I was sort of paying attention to all these ideas and concepts two-three years ago from the sidelines (partially with the idea to learn how Julia could potentially evolve) but it's far from my area of expertise, I might well be getting stuff wrong.

reply
You make use of 'owned', 'shared', 'unmanaged', 'borrowed'.

https://chapel-lang.org/docs/language/spec/classes.html#clas...

reply
I see, seems like the design is not complete and a work in progress (which is the same for Mojos Origins concept I think):

"The details of lifetime checking are not yet finalized or specified. Additional syntax to specify the lifetimes of function returns will probably be needed."

I think Rust proved that lifetimes, ownership and borrow checking can be useful for a mainstream language. The discussions in the Mojo context revolve on how to improve the ergonomics of these versus Rust.

reply
Contrary to Mojo, plenty of people are using it in HPC, and is open source.

https://hpsf.io/blog/2026/hpsf-project-communities-to-gather...

https://developer.hpe.com/platform/chapel/home

See "Projects Powered by Chapel".

reply
So? What point are you making? A different language with different design philosophy, has success in a different niche than Mojo is targeting?
reply
One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0.

Chapel current version is 2.8.0.

reply
I don't think Mojo is targeting HPC at all.
reply
I don't understand this framing, so? Cpp, Julia are more widely adopted, used in HPC. it does not mean that people shouldn't start, learn new languages.
reply
In the LLM age, maybe the focus should be elsewhere instead of syntax.
reply
is that so? People are still reading their code to understand it and ask (or make modifications). even in the (LLM age) language design, readability is still as relevant as before.

I don't see the superficial comparisons between why this new Y when we have X are not really helpful. Languages and system got adopted not for their stated goal only, but for the underlying details capabilities, good design which translates to better user experience and ecosystem growth.

reply
Mojo isn't that far away from 1.0. Some point this year is the target
reply
Is it? Spack has only one package that depends on chapel.
reply
That was what was originaly advertised, they wanted to be what Kotlin is to Java but for Python. They quickly turned tails on this.

That and the not completely open source development model is what has always felt very vaporwary to me.

reply
From the site:

Python interop > Mojo natively interoperates with Python so you can eliminate performance bottlenecks in existing code without rewriting everything. You can start with one function, and scale up as needed to move performance-critical code into Mojo. Your Mojo code imports naturally into Python and packages together for distribution. Likewise, you can import libraries from the Python ecosystem into your Mojo code.

reply
That's because Mojo told you that. https://web.archive.org/web/20231221132631/https://docs.modu...

> Our long-term goal is to make Mojo a superset of Python (that is, to make Mojo compatible with existing Python programs). Python programmers should be able to use Mojo immediately, and be able to access the huge ecosystem of Python packages that are available today.

reply
Mojo has refocused on Python interoperability vs. superset, though yes, the original idea was being a superset.

It's possible the language evolves to that in the longterm, but it's not the short term goal.

We published a Mojo roadmap on Mojolang.org that helps contextualize this: https://mojolang.org/docs/roadmap/

Note: I work at Modular

reply
> they intended to make it compatible with existing Python code

That was the original claim, but it was quietly removed from the website. (Did they fall for the common “Python is a simple language” misconception?).

Now they promise I can “write like Python”, but don’t even support fundamentals like classes (which are part of stage 3 of the roadmap, but they’re still working on stage 1).

Maybe Mojo will achieve all its goals, but so far has been over-promising and under-delivering - it’s starting to remind me of the V language.

reply
The communication had me try to run some very simple python code assuming it of course should run (reading files line by line), which didn't work at all.

For me this was a big disappointment, and I wonder how much this has backfired across developers.

reply
isn't that achieved by Codon?
reply
Really the only thing good about Python is its ecosystem.
reply
Nah, it's also a very fine language for getting an idea down quickly.

Might not have the niceties purists like, but perhaps that's exactly it's a great language for that.

It's like executable pseudocode, and unlike other languages, all the ceremony is optional.

People flocked to it way before it became a "must" for ML and CS thanks to that ecosystem becoming dominant.

reply
but that ecosystem is realy good.
reply
That it is
reply
They just lie a lot, they make fake blogs with fake benchmarks and then they delete them
reply