Given that NVidia now decided to get serious with Python JIT DSLs in CUDA as announced at GTC 2025, I wonder how much mindshare Mojo will managed win across researchers.
There is also Julia, as the black swan many outside Python community have moved into, with much more mature tooling, and first tier Windows support, for those researchers that for whatever reason have Windows issued work laptops.
Mojo as programming language seems interesting as language nerd, but I think the judge is still out there if this is going to be another Swift, or Swift for Tensorflow, in regards to market adoption, given the existing contenders.
Mojo (and Modular's whole stack) is pretty much completely focused at people who are interested in inference, not training nor research so much at this moment.
So going after people who need to build low latency high-throughput inference systems.
Also as someone else pointed out, they also target all kinds of hardware, not just NVidia.
I think the big value add of Mojo is that you are no longer writing GPU code that only runs on one particular GPU architecture.
In the same way that LLVM allows CPU code to target more than one CPU architecture, MLIR/Mojo allows GPU code to target multiple vendor's GPUs.
There is some effort required to write the backend for a new GPU architecture, and Lattner has discussed it taking about two months for them to bring up H100 support.
What about Candle, made by Huggingface? Seems to at least allow the basics and has lots of examples, all of them run on both CPU and GPU. Haven't dived deeper into it, but played around with it a bit and found it good enough for embedding purposes at least.
Currently looks more like CPUs and eventually AMD, from what I have been following up on their YouTube sessions, and whole blog post series about freedom from NVidia and such.
There's pretty broad support for server-grade and consumer GPUs. It's a bit buried, but one of the most reliable lists of supported GPUs is in the Mojo info documentation.https://docs.modular.com/mojo/stdlib/gpu/host/info/
Already GPU code, kernels, and complete models can run on datacenter AMD GPUs using the same code, the same programming model, and same language constructs.
not sure, modular is focusing mainly on enterprise applications. but if you look at the current PRs you can see people hacking support for standalone consumer-grade Nvidia and AMD gpus because it is easy, you just add the missing or different intrinsics for the architecture in the lowest level (in pure mojo code) and wire it up in a few places and voila you already program and run code on this GPU. iGPU/Apple GPUs are still not supported yet but it would interesting to see their integration
Just as LLVM doesn't automatically have a backend or every new CPU architecture, Mojo/MLIR doesn't automatically have a backend for every new CPU/GPU/TPU.
However, writing an LLVM backend for RISC-V sure did add support for a whole lot of different programming languages and the software you have access to through them in one fell swoop.
The same is true here.
Instead of rewiting all your GPU code every time you need to target a new GPU/TPU architecture, you just need a new backend.
Chris Lattner (the tech lead behind Mojo, LLVM, Clang, Swift and MLIR) appeared on a podcast a bit over a week ago and discussed the state of Mojo and where it is going.
He also discussed open sourcing Mojo and where the company expects to make its money.
Funny how the already weak case for not working on Julia instead of creating a new language is becoming even more flimsy :
FAQ:
> Why not make Julia better?
> We think Julia is a great language and it has a wonderful community, but Mojo is completely different. While Julia and Mojo might share some goals and look similar as an easy-to-use and high-performance alternative to Python, we’re taking a completely different approach to building Mojo. Notably, Mojo is Python-first and doesn't require existing Python developers to learn a new syntax.
>We oversold Mojo as a Python superset too early and realized that we should focus on what Mojo can do for people TODAY, not what it will grow into. As such, we currently explain Mojo as a language that's great for making stuff go fast on CPUs and GPUs.
> Julia: Julia is another great language with an open and active community. They are currently investing in machine learning techniques, and even have good interoperability with Python APIs.
The share of projects that start out “we’re going to do X, and conpletely support using the syntax and semantics of existing language Y, but add more on top” that end up “we’re going to do X, in a language vaguely reminiscent of Y” is very hard to distinguish from 100%.
I think the real reason is that Chris Lattner doesn’t want to work on Julia. He’s likely very (and justifiably so) opinionated about these topics, and probably wants a certain degree of creative authority over his projects.
Although from the way some Modular videos are done, it seems nowadays he is more in an overseer role and setting up the direction, while others are the ones actually pushing Mojo and Max tooling forward.
Maybe I just misunderstand it from the presentation format.
He works on Mojo a lot, mostly on weekends. In the past few months, he has worked on strings, collection literals, dependent types, reference captures,
comprehensions, and many other nice language features.
Additionally Julia works on Windows, lots of its issues have been ironed out throught the last decade, and many folks are invested into it, instead of a single company product.
Yes many of the mainstream languages started as single company product, but lets put it this way, would anyone be writing one of such languages today, had those not been languages gatekeeped to access a specific platform?
So outside accessing Max and its value preposition as product enabler for XYZ, who would be rushing to write Mojo code, instead of something else.
I think the modular proposition is to solve the AI infra problem using a modern systems programming language but with a python syntax (to keep the mental overhead low) it is mainly trying to replace C++/CUDA. I am not sure Julia is suitable for such endeavour. Julia is not marketed as a systems programming language and I find it hard to believe that it can be one as dyamically typed langauge with GC and JIT.
Could Julia replace python in the high-level dynamic code space used in research and training? maybe. but I find it really hard to believe that it can replace CUDA/ROCm/C++ .. etc.
Lisp Machines from Xerox PARC, Texas Instruments and Genera proved their point, even if the market wasn't up to their price point versus UNIX graphical workstations.
Dylan was going to be Newton's system programming language, and while the language group lost the the C++ team (Apple had two competing teams for the Newton OS), it was still NewtonScript for everything userspace, and it was getting a JIT by the time the project was canceled.
Objective-C is dynamically typed beyond the common subset with C, and was used even to write NeXTSTEP drivers.
I don't know how much of a chance Julia has against CUDA/ROCm/C++, especially now that everyone on the GPU space has decided to give feature parity to Python on their hardware, via day one bindings to the compute libraries and JIT DSLs, so that makes Mojo even less of a chance than Julia has.
Julia has an established ecosystem, and presence on the scientific community with ties to MIT.
Python is the champion, and most folks writing CUDA/ROCm/C++ are already using it.
So who would be reaching out to Mojo, instead of Python JIT DSLs/bindings or Julia, when having Fortran, C, C++ allergy?
Creating DSL/Bindings for Julia or python to underlaying platform like CUDA is not really replacing it, it is yet adding another layer on top of the existing platforms or creating a prototyping envirnoment for research. The question is not can Julia interface with CUDA, it is can Julia replace C++/CUDA/ROCm in an end-to-end scenarios (preferably with portability across GPUs vendors)? if not then there is no comparison between the stated goals of Julia and Mojo. they are different langauges targeting completly different use cases.
Julia does not just have bindings to CUDA. Native Julia code can compile to build .ptx kernels https://cuda.juliagpu.org/stable/development/kernel/. This same code can also generate kernels for AMD GPUs, Intel GPUs, and Metal.
We for example built software that generates kernels on-demand that embed user functions for all 4 of these systems and showed it's much faster than just CUDA bindings for array functions for certain nonlinear systems (https://www.sciencedirect.com/science/article/abs/pii/S00457...)
It's the Latent Space podcast, published June 13. It's a pretty decent podcast for keeping on top of AI stuff. Swyx, one of the co-hosts, is active here on HN.
I guess they abandoned the python superset idea? I followed them for a bit when they first publicly launched and they said "don't worry, we'll be a real python superset soon" and the biggest omission was no support for classes. A few years later, it looks to be missing the same set of python features but added a lot of their own custom language features.
It was highly aspirational goal, and practically speaking it's better right now to take inspiration from Python and have stronger integration hooks into the language (full disclosure, I work at Modular). We've specifically stopped using the "superset of Python" language to be more accurate about what the language is meant for right now.
Being a Python superset and being fast are fundamentally in tension. It would be possible, maybe, to have a Python superset where you get the highest performance as long as you avoided the dynamic features of Python. However, I suspect it would make the user base grumpy to have a hidden performance cliff that suddenly showed up when you used dynamic features (or depended on code that did the same).
The dynamic features of Python are no different from the dynamic features of Smalltalk, Self, Common Lisp, but people have been educated to expect otherwise due to the adoption failure of dynamic compilers in Python community.
From Chris Lattner on Modular discord few days ago:
Yep, that's right. Int behaving like a machine integer is very important for systems performance. Leaving the "int" namespace untouched allows us to have a object-based bigint in the future for compatibility with python.
As others have mentioned above, it is still a goal to be compatible with python in time, just not a short term priority
It's not a specific bitwidth in a sense that it maps to whatever largest integer type is natively supported by the target architecture (i.e. basically 32-bit or 64-bit).
Python is a hacky language that was never designed other than laying it's eggs against the grain of what we seem to mostly agree is godo — e.g. functional programming and composition.
Big tech spends a lot of money to avoid python in critical infra.
I'm glad the blazing-fast tech is finally making it to python. Those guys were pretty busy with Rust for like the past 10 years. I'm glad they are finally starting to making a blazing-fast python stuff.
I am really rooting for Mojo. I love what the language is trying to do, and making it easier to run SOTA AI workloads on hardware that isn't Nvidia + CUDA will open up all kinds of possibilities.
I'm just nervous how much VC funding they've raised and what kind of impacts that could have on their business model as they mature.
If they can manage to make good on their plans to open-source it, I'll breathe a tentative sigh of relief. I'm also rooting for them, but until they're open-source, I'm not willing to invest my own time into their ecosystem.
They already released their code under the Apache 2.0 license. Not everything in their stack is open source but the core things appear to be open source.
One of the big differences here is that the Mojo/Python interop package is doing a lot of the heavy lifting of compiling and loading the code. The goal here is to have a language that's close to Python that gives you hardware acceleration as you need it, without having to configure and build C++ code for every platform.
We've run a few events this year (disclosing again that I work for Modular, to put my comments into context), and we've had some great feedback from people who have never done GPU programming about how easy it was to get started using Mojo.
C++ is a powerful and mature language, but it also has a steep learning curve. There's a lot of space for making GPU (and other high performance computing) easier, and platforms/languages like Triton and Julia are also exploring the space alongside Mojo. There's a huge opportunity to make GPU programming easier, and a bit part of that opportunity is in abstracting away as much of the device-specific coding as you can.
I was a HPC C++ programmer for a long time, and I always found recompiling for new devices to be one of the most painful things about working in C++ (for example, the often necessary nightmare of cmake). Mojo offers a lot of affordances that improve on the programming experience at the language, compiler, and runtime levels.
I am not that intrigued that Python that can call some pre-compiled functions, this is already possible with any language that produces a dynamic library.
The space that I am interested in is execution time compiled programs. A usecase of this is to generate a perfect hash data structure. Say you have a config file that lists out the keywords that you want to find, and then dynamically generate the perfect hash data structure compiled as if those keywords are compile time values (because they are).
Or, if the number of keywords is too small, fallback to a linear search method. All done in compile time without the cost of dynamic dispatch.
Of course, I am talking about numba. But I think it is cursed by the fact that the host language is Python. Imagine if Python is stronger typed, it would open up a whole new scale of optimization.
I would rather image CPython being like Common Lisp, Scheme, Raket, Smalltalk, Self compilation model.
Sadly the contenders on the corner get largely ignored, so we need to contend with special cased JIT DSLs, or writing native extensions, as in many cases CPython is only implementation that is available.
Jitting like you mentioned is supported by the MAX graph API: https://docs.modular.com/max/tutorials/build-custom-ops. It could have a nicer syntax though to be more like Numba, I think you have an interesting idea there.
> I am not that intrigued that Python that can call some pre-compiled functions, this is already possible with any language that produces a dynamic library.
> The space that I am interested in is execution time compiled programs. A usecase of this is to generate a perfect hash data structure. Say you have a config file that lists out the keywords that you want to find, and then dynamically generate the perfect hash data structure compiled as if those keywords are compile time values (because they are).
I'm not sure I understand you correctly, but these two seem connected. If I were to do what you want to do here in Python I'd create a zig build-lib and use it with ctypes.
Can Zig recompile itself if I change a config in production? I am talking about this
```
python program.py --config <change this>
```
It is basically a recompilation of the whole program at every execution taking into account the config/machine combination.
So if the config contains no keyword for lookup, then the program should be able to be compiled into a noop. Or if the config contains keyword that permits a simple perfect hash algorithm, then it should recompile itself to use that mechanism.
I dont think any of the typical systems programming allows this.
The thing I focus on when writing compiled extensions for Python isn't the speed of the extension, but rather the overhead of the call and the overhead of moving objects from Python -> compiled and compiled -> Python.
Is there a zero-copy interface for larger objects? How do object lifetimes work in that case? Especially if this is to be used for ML, you need to haul over huge matrices. And the GIL stuff is also a thing.
I've never been thats sold on Mojo, I think I'm unfairly biased away from it because I find new languages interesting, and its big sell is changing as little as possible from an existing language.
That said, importing into Python this easily is a pretty big deal. I can see a lot of teams who just want to get unblocked by some performance thing, finding this insanely helpful!
> its big sell is changing as little as possible from an existing language.
This is not really true. Even though Mojo is adopting Python's syntax, it is a drastically different language under the hood. Mojo is innovating in many directions (eg: mlir integration, ownership model, comptime, etc). The creators didn't feel the need to innovate on syntax in addition to all that.
You're right- I probably should have said something like "part of its sell" or "one of its selling points" or something.
I didn't mean to undermine the ambitious goals the project has. I still wish it was a little bolder on syntax though, Python is a large and complex language as is, so a superset of Python is inherently going to be a very complicated language.
> as I'm definitely in the market for a simple compiled language that can offer Python some really fast functions
So, Nim? https://github.com/yglukhov/nimpy
The real point of Mojo is not the language, it's the deep roots into MLIR which is an attempt to do what LLVM did for compilers, and do it on GPUs / ML hardware. Chris Lattner is leading the project and he created LLVM and MLIR.
FTA (emphasis added): “Chris Lattner mentioned that Python can actually CALL Mojo code now”
So, the message is that it is possible to create nice Python bindings from Mojo code, but only if your Mojo code makes the effort to create an interface that uses PythonObject.
Useful, but I don’t see how that’s different from C code coding the same, as bindings go.
Both make it easier to gradually move Python code over to a compiled language.
Mojo presumably will have the advantage that porting from Python to Mojo is much closer to a copy paste job than porting Python to C is.
wow, it compiles to python callable '.so' via PythonModuleBuilder without extra C layer needed. test cases show tight loop performance gains prime count up to 20k runs 0.011s vs 0.446s in pure python. this unlocks low friction speedups where python hits the wall. there's still type constraints factorial(100) overflows due to fixed int width, no bigint fallback. worth tracking how array handling evolves, since that'll decide if mojo stays in compute heavy corners or becomes viable for broader use. it's early but usable is the key word
For a language that announced itself (and raised a lot of money on the premise of) claiming to be "a Python superset", this does not sound like a huge achievement.
In all fairness, their website now reads: "Mojo is a pythonic language for blazing-fast CPU+GPU execution without CUDA. Optionally use it with MAX for insanely fast AI inference."
So I suppose now is just a compiled language with superficially similar syntax and completely different semantics to Python?
I think it was pretty clear immediately that running python code was a far away goal. There was a lot more talk about lifetimes and ownership semantics than details about Python interop. Mojo is more like: Can we take the learnings of Swift and Rust and solve the usability and compile time issues, while building on MLIR to target arbitrary architectures efficiently (and call it a Python superset to raise VC money).
That said, the upside is huge. If they can get to a point where Python programmers that need to add speed learn Mojo, because it feels more familiar and interops more easily, rather than C/CPP that would be huge. And it's a much lower bar than superset of python.
It marketed itself explicitly as a "Python superset", which could allow Python programmers to avoid learning a second language and write performant code.
I'd argue that I am not sure what kind of Python programmer is capable of learning things like comptime, borrow checking, generics but would struggle with different looking syntax. So to me this seemed like a deliberate misrepresentation of the actual challenges to generate hype and marketing.
Which fair enough, I suppose this is how things work. But it should be _fair_ to point out the obvious too.
Absolutely. The public sales pitch did not match the reality. This is what I meant with the "Claim to be Ṕython to get VC money" point.
To first order, today every programmer starts out as a Python programmer. Python is _the_ teaching language now. The jump from Python to C/Cpp is pretty drastic, I don't think that it's absurd that learning Mojo concepts step by step coming from Python is simpler than learning C. Not syntactically but conceptually.
Maybe young generations have some issue learning polyglot programming, I guess.
While I agree using Mojo is much preferable to writing C or C++ native extensions, back on my day people learned to program in K&R C or C++ ARM in high school, kids around 12 years old, hardly something pretty drastic.
Many famous Speccy and C64 titles, written in Assembly, were written by bedroom coders between the ages of 14 and 16 years old, getting some pocket money writing them on the UK scene.
Get hold of Retro Gamer magazine for some of their stories.
I've tried learning C a couple times and given up because the curve is too steep to be worth the climb. It's not even the language itself, it's the inherited weight of half a century's worth of cruft. I can't spend weeks fighting with compiler nonsense, header files and #include. Screw it, I'll just use Go instead.
I'm learning Rust and Zig in the hope that I'll never have to write a line of C in my career.
Geez, what a comment. C is much much more simpler than Rust. You’re not supposed to be spending weeks fighting includes or compiler errors, that means you’re have some very basic misconceptions about the language.
Just read K&R “The C programming language” book.
It’s fairly small and it’s a very good introduction to C.
C syntactically is straight forward, but conceptually may be harder than Rust. You’re exposed to the bare computer (memory management, etc) far more than with a GC language or even Rust arguably, at least for simple programs.
Towards deployment is even harder. You can very easily end up writing exploitable, unsafe code in C.
If I were a Python programmer with little knowledge about how a computer works, I’d much prefer Go or Rust (in that order) to C.
This is true, but when you get something wrong related to the memory model in C, it just says "segfault". Whereas in Rust it will give you a whole explanation for what went wrong and helpful suggestions on how to fix it. Or at the very least it will tell you where the problem is. This is the difference between "simple" and "easy".
That applies only if you take "memory model" to mean modeling the effects of concurrent accesses in multithreaded programs.
But the term could also be used more generally to include stuff like pointer provenance, Rust's "stacked borrows" etc.
In that case, Rust is more complicated than C-as-specified. But C-in-reality is much more complicated, e.g. see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm
The model you're referring to, a Memory Ordering Model, is literally the same model as Rust's. The "exception" is an ordering nobody knows how to implement which Rust just doesn't pretend to offer - a distinction which makes no difference.
I do sympathize with the parent: The language itself might not be that difficult but you also have to factor in the entire ecosystem. What's the modern way to a build a GUI application in C? What's the recommended way to build a CLI, short of writing your own arg parser? How do you handle Unicode? How do you manage dependencies, short of vendoring them? Etc.
Errors too. When, inevitably, you make mistakes the C might just compile despite being nonsense, or you might get incomprehensible diagnostics. Rust went out of its way to deliver great results here.
I am not arguing about how good or easy it is to use C in production, I’m merely stating that parent complaints about weeks of insolvable errors and issues with includes screams that he needs to read some good resource like book, because he is definitely misunderstanding something important.
THe thing is, if one is an expert it is incredibly difficult to understand the beginner perspective. Here is one attempt:
C is simpler than Rust, but C is also _much_ simpler than Python. If I solve a problem in Python I have a good standard library of data types, and I use concepts like classes, iterators, generators, closures, etc... constantly. So if I move to Rust, I have access to the similar high-level tools, I just have to learn a few additional concepts for ressource management.
In comaprison, C looks a lot more alien from that perspective. Even starting with including library code from elsewhere.
FWIW generics are already a thing in pure Python as soon as you add type annotations, which is fast becoming the default (perhaps not the least because LLMs also seem to prefer it).
I think one of the "Python superset" promises was that any particular dev wouldn't need to learn all of that at once. There could exist a ramp between Python and "fast python" that is more gradual than the old ways of dropping into C, and more seamless than importing and learning the various numpy/numba/polars libraries.
I suppose if you accept the innocent-looking "#"+"#"=="##" then your example kind of algebraically follows. Next it's time to define what exp("#") is :)
* does different things depending on the types of the operands, which is Python's strong typing at work, not Perlesque weak typing. Repeating a string is a useful thing to be able to do, and this is a natural choice of syntax for it. The same thing works for lists: [1]*3 == [1, 1, 1].
It does unfortunately mean that sometimes `*` will work (and produce an incorrect result) rather than immediately failing loudly with a clear error message in the context in which it's actually intended to be numerical.
More broadly this is the same argument as whether overloading `+` for strings is a bad idea or not, and the associated points, e.g. the fact that this makes it non-commutative - the same all applies to `*` as well, and to lists as much as strings. At least Python is consistent here.
Although there is one particular aspect that is IMO just bad design: the way `x += y` and `x = y` work. To remind, for lists these are not equivalent to `x = x + y` and `x = x y` - instead of creating a new list, they mutate the existing one in place, so all the references observe the change. This is very surprising and inconsistent with the same operators for numbers, or indeed for strings and tuples.
The real unique selling point of Mojo is "CPU+GPU execution without CUDA", specifically, you write code that looks like code without worrying about distinctions like kernels and device functions and different ways of writing code that runs on GPU vs. code that runs on CPU, and mojo compiles it to those things.
> For a language that announced itself (and raised a lot of money on the premise of)
claiming to be "a Python superset", this does not sound like a huge achievement
I feel like that depends quite a lot on what exactly is in the non-subset part of the language. Being able to use a library from the superset in the subset requires being able to translate the features into something that can run in the subset, so if the superset is doing a lot of interesting things at runtime, that isn't necessarily going to be trivial.
(I have no idea exactly what features Mojo provides beyond what's already in Python, so maybe it's not much of an achievement in this case, but my point is that this has less to do with just being a superset but about what exactly the extra stuff is, so I'm not sure I buy the argument that the marketing you mention of enough to conclude that this isn't much of an achievement.)
I've written this somewhere else before, Modular did not raise $130m to build a programming language, nobody does that.
They raised that much money to revolutionize AI infrastructure, of which a language is just a subset. You should definitely check some of the things they've put together, they're amazing
Yes. They are revolutionizing AI infrastructure but I guess a lot of world is just babbling about AI, but not every developer needs to worry about AI.
And so his improvements in mojo and now calling mojo code from python just make a lot more net positive to the community than being, some other Ai infrastructure company.
So I do wish a lot of good luck to mojo. I have heard that mojo isn't open source but it has plans to do so. I'd like to try it once if its as fast / even a little slower than rust and comparable to understanding as python.
I don't think investors look at what makes a net positive to the community when making large investments like in Modular. I was calling out the part of the post that said Modular raised a lot of Money to develop Mojo, that isn't entirely true as just creating a language isn't enough reason to invest $130m into a company, no matter how much net-positivity the language would bring.
Agreed, Modular is walking a very fine line, and they're doing so by trading on the reputation of Chris Lattner.
On the one had, as the other poster noted, no one raises $100M+ for a programming language; programming languages have no ROI that would justify that kind of money. So to get it, they had to tell VCs a story about how they're going to revolutionize AI. It can't just be "python superset with MLIR". That's not a $100M story.
On the other hand, they need to appeal to the dev community. For devs, they want open source, they want integration with their tools, they don't want to be locked into a IP-encumbered ecosystem that tries to lock them in.
That's where the tension is. To raise money you need to pretend you're the next Oracle, but to get dev buy-in you have to promise you're not the next Oracle.
So the line they've decided to walk is "We will be closed for now while figure out the tech. Then later once we have money coming in to make the VCs happy, we can try to make good on our promise to be open."
That last part is the thing people are having trouble believing. Because the story always goes: "While we had the best intentions to be open and free, that ultimately came secondary to our investors' goal of making money. Because our continued existence depends on more money, we have decided to abandon our goal of being open and free."
And that's what makes these VC-funded language plays so fraught for devs. Spend the time to learn this thing which may never even live up to its promises? Most people won't, and I think the Darklang group found that out pretty decisively.
> Further, we decided that the right long-term goal for Mojo is to adopt the syntax of Python (that is, to make Mojo compatible with existing Python programs) and to embrace the CPython implementation for long-tail ecosystem support
It was never going to have Python semantics and be fast. Python isn't slow because of a lack of effort or money, it's slow because of all the things happening in the interpreter.
My impression is that mojo is not python, there are similarities, but under the hood mojo is much more similar to c++/rust.
As part of this it has a stronger type/lifecycle/memory model than python.
Maybe you could write, some level of transpiler, but so much of the optimizations rely on things that python does not expose (types), and there are things that python can do that are not supported.
The Python function is implemented in C and uses a faster algorithm [1], and this particular factorial is so small they put it in a lookup table [2]. It is a strange and very unequal choice for a demo.
My guess is that the slight overhead of interacting with mojo led to this speed discrepancy, and if a higher factorial (that was within the overflow limits etc) was run, this overhead would become negligible (as seen by the second example). Also similar to jax code being slower than numpy code for small operations, but being much faster for larger ones on cpus etc.
I’m someone who should be really excited about this, but I fundamentally don’t believe that a programming language can succeed behind a paywall or industry gatekeeper.
I’m always disappointed when I hear anything about mojo. I can’t even fully use it, to say nothing of examine it.
We all need money, and like to have our incubators, but the LLVM guy thinks like Jonathan Blow with jai?
I don’t see the benefit of joining an exclusive club to learn exclusively-useful things. That sounds more like a religion or MLM than anything RMS ever said :p
> the LLVM guy thinks like Jonathan Blow with jai?
I would not compare Chris Lattner with Jonathan Blow. Lattner is a person with a reputation for delivering programming languages and infrastructure; whereas for Blow, it seems like an ego issue. He's built a nice little cult of personality around his unreleased language, and releasing it will kill a lot of that magic (running a language project with actual users that has to make good on promises is much different than running a language project with followers and acolytes that can promise anything and never deliver on it).
Lattner has a record of actually delivering dev products people can download and use. Mojo is closed source to make raising money easier, but at least you can actually use it. Jai isn't even available for people to use, and after a decade of Blow dangling it in front of people, it's not clear it'll ever be available, because I'm not sure he wants it to be available.
> Functions taking more than 3 arguments. Currently PyTypeBuilder.add_function() and related function bindings only support Mojo functions that take up to 3 PythonObject arguments: fn(PythonObject, PythonObject, PythonObject).
Lol wut. For the life of me I cannot fathom what design decision in their cconv/ABI leads to this.
There was a similar pattern in the Guava library years ago, where ImmutableList.of(…) would only support up to 20 arguments because there were 20 different instances of the method for each possible argument count.
> We have committed to open-sourcing Mojo in 2026. Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out.
> That rules it out of any production deployment until 2026 so.
Has that stopped everyone before? Java, C#/.NET, Swift and probably more started out as closed-source languages/platforms, yet seemed to have been deployed to production environments before their eventual open-sourcing.
I don't think Java (when it was owned by Sun) nor .NET (even currently) run the risk of a VC "our incredible journey" event causing "barrel bending" nor the backing company running out of money. In the first flavor, they'd want their pound of flesh and the "our new compiler pricing is ..." would be no good. In the latter, even if they actually opened the platform on the way out, it still would require finding a steward who could carry the platform forward, which is a :-( place to be if you have critical code running upon it
I guess the summary is that neither Java [at the time] nor .NET were profit centers for their owners, nor their only reason for existing
They certainly were, because no one other than a few hardlines were writing Java or C# and VB code in bare bones editors and compiling from command line, as only the bare bones SDKs were free beer, and for the desktop.
IDEs, implementations for embedded and phones, were all paid products, IDEs by developers or their employers, the others by OEMs.
My point is the early days, JCafe, Visual Age, Visual Studio, Forte, before free beer IDEs for them became common.
Java side with Eclipse/Netbeans, .NET side with the Visual Studio Express editions.
Yes, and there is a reason for that: Both are deeply integrated in Microsofts ecosystem, and whether one likes that or not, that ecosystem is the dominant platform for desktop computing, especially in commercial settings.
Yeah, I also get confused with references. I was annoyed from the start, when "Mojo" was announced as a Python family language. Mojolicious uses the "Mojo" namespace and is referred to as that quite often. I know Perl is not as popular as it used to be, but Mojolicious is probably the most popular framework of a language that is roughly in the same "space" as Python, so that naming choice was very ignorant IMHO.
Given that NVidia now decided to get serious with Python JIT DSLs in CUDA as announced at GTC 2025, I wonder how much mindshare Mojo will managed win across researchers.
"1001 Ways to Write CUDA Kernels in Python"
https://www.youtube.com/watch?v=_XW6Yu6VBQE
"The CUDA Python Developer’s Toolbox"
https://www.nvidia.com/en-us/on-demand/session/gtc25-S72448/
"Accelerated Python: The Community and Ecosystem"
https://www.youtube.com/watch?v=6IcvKPfNXUw
"Tensor Core Programming in Python with CUTLASS 4.0"
https://www.linkedin.com/posts/nvidia-ai_python-cutlass-acti...
There is also Julia, as the black swan many outside Python community have moved into, with much more mature tooling, and first tier Windows support, for those researchers that for whatever reason have Windows issued work laptops.
https://info.juliahub.com/industries/case-studies
Mojo as programming language seems interesting as language nerd, but I think the judge is still out there if this is going to be another Swift, or Swift for Tensorflow, in regards to market adoption, given the existing contenders.
Mojo (and Modular's whole stack) is pretty much completely focused at people who are interested in inference, not training nor research so much at this moment.
So going after people who need to build low latency high-throughput inference systems.
Also as someone else pointed out, they also target all kinds of hardware, not just NVidia.
Why not use PyO3 instead? It had a much cleaner interface than cython and c++ libraries.
The primary advantage of mojo seems to be Gil-free syntax that is as close to Python as possible.
GPU programming in Rust isn't great.
In Mojo it's pretty much the whole point of the language. If you're only using CPUs, then yeah, PyO3 is a good choice.
I think the big value add of Mojo is that you are no longer writing GPU code that only runs on one particular GPU architecture.
In the same way that LLVM allows CPU code to target more than one CPU architecture, MLIR/Mojo allows GPU code to target multiple vendor's GPUs.
There is some effort required to write the backend for a new GPU architecture, and Lattner has discussed it taking about two months for them to bring up H100 support.
Indeed, but not only GPUs but accelerators in general. Mojo will be able to target weird esoteric hardware (portably if that is important)
What about Candle, made by Huggingface? Seems to at least allow the basics and has lots of examples, all of them run on both CPU and GPU. Haven't dived deeper into it, but played around with it a bit and found it good enough for embedding purposes at least.
Currently looks more like CPUs and eventually AMD, from what I have been following up on their YouTube sessions, and whole blog post series about freedom from NVidia and such.
They also miss CPUs on Windows, unless using WSL.
There's pretty broad support for server-grade and consumer GPUs. It's a bit buried, but one of the most reliable lists of supported GPUs is in the Mojo info documentation.https://docs.modular.com/mojo/stdlib/gpu/host/info/
Already GPU code, kernels, and complete models can run on datacenter AMD GPUs using the same code, the same programming model, and same language constructs.
Laptops?
Yes, recent NVIDIA and AMD consumer GPUs are supported: https://docs.modular.com/max/faq/
not sure, modular is focusing mainly on enterprise applications. but if you look at the current PRs you can see people hacking support for standalone consumer-grade Nvidia and AMD gpus because it is easy, you just add the missing or different intrinsics for the architecture in the lowest level (in pure mojo code) and wire it up in a few places and voila you already program and run code on this GPU. iGPU/Apple GPUs are still not supported yet but it would interesting to see their integration
Mojo is marketed as a way to get maximum hardware performance on any hardware, not just nvidia.
This may appeal to people wanting to run their code on different hardware brands fro various reasons.
True, however that goal is not yet available today, it doesn't even run on Windows natively.
And for those that care, Julia is available today on different hardware brands, as there are other Python DSL JITs as well.
I agree they will get there, now the question is will they get there fast enough to matter, versus what the mainstream market cares about.
Mojo GPU kernels can run on both Nvidia and AMD GPUs today
Specific models if I recall correctly.
Just as LLVM doesn't automatically have a backend or every new CPU architecture, Mojo/MLIR doesn't automatically have a backend for every new CPU/GPU/TPU.
However, writing an LLVM backend for RISC-V sure did add support for a whole lot of different programming languages and the software you have access to through them in one fell swoop.
The same is true here.
Instead of rewiting all your GPU code every time you need to target a new GPU/TPU architecture, you just need a new backend.
Nah, outside of Models you can write Mojo code today that work on both Nvidia and AMD gpus, the code itself doesn't have to be AI specific.
I think they meant models of GPU, not models of LLM.
The limitations of DSLs and the pull of Python make it a practical sweet spot I think if they manage to get the Python compatibility up to par.
I love Julia and want to see it break through. It suffers from the lack of a big corporate patron.
Plenty of them exist already, that is why I pointed out this, that HNers keep overlooking
https://info.juliahub.com/industries/case-studies
Sure, a bunch of companies use Julia but none of them are backing it the way Google backs Go, Oracle backs Java, or Mozilla (formerly) backed Rust.
Didn't hurt that much for Python, Ruby, not having a big name in the early days.
Just like I would consider MIT and a few of the companies on that listing as relevant, doesn't need to always be a FAANG.
Mojo runs on nVidia and AMD.
The competitor is Triton, not CUDA or Julia...
Chris Lattner (the tech lead behind Mojo, LLVM, Clang, Swift and MLIR) appeared on a podcast a bit over a week ago and discussed the state of Mojo and where it is going.
He also discussed open sourcing Mojo and where the company expects to make its money.
https://www.youtube.com/watch?v=04_gN-C9IAo
He popped up on r/programminglanguages last week to say a bit about that as well: https://www.reddit.com/r/ProgrammingLanguages/comments/1lfz9...
Funny how the already weak case for not working on Julia instead of creating a new language is becoming even more flimsy :
FAQ:
> Why not make Julia better? > We think Julia is a great language and it has a wonderful community, but Mojo is completely different. While Julia and Mojo might share some goals and look similar as an easy-to-use and high-performance alternative to Python, we’re taking a completely different approach to building Mojo. Notably, Mojo is Python-first and doesn't require existing Python developers to learn a new syntax.
https://docs.modular.com/mojo/faq/#why-not-make-julia-better
Now :
>We oversold Mojo as a Python superset too early and realized that we should focus on what Mojo can do for people TODAY, not what it will grow into. As such, we currently explain Mojo as a language that's great for making stuff go fast on CPUs and GPUs.
Even funnier: https://github.com/tensorflow/swift/blob/main/docs/WhySwiftF...
> Julia: Julia is another great language with an open and active community. They are currently investing in machine learning techniques, and even have good interoperability with Python APIs.
Yeah that was a missed opportunity fore sure, joining forces 8 years ago would probably had yield better results that the current situation.
The share of projects that start out “we’re going to do X, and conpletely support using the syntax and semantics of existing language Y, but add more on top” that end up “we’re going to do X, in a language vaguely reminiscent of Y” is very hard to distinguish from 100%.
I think the real reason is that Chris Lattner doesn’t want to work on Julia. He’s likely very (and justifiably so) opinionated about these topics, and probably wants a certain degree of creative authority over his projects.
Why deal with others when you are big enough of a name to launch your own and make all the decisions yourself?
Although from the way some Modular videos are done, it seems nowadays he is more in an overseer role and setting up the direction, while others are the ones actually pushing Mojo and Max tooling forward.
Maybe I just misunderstand it from the presentation format.
He works on Mojo a lot, mostly on weekends. In the past few months, he has worked on strings, collection literals, dependent types, reference captures, comprehensions, and many other nice language features.
Additionally Julia works on Windows, lots of its issues have been ironed out throught the last decade, and many folks are invested into it, instead of a single company product.
Yes many of the mainstream languages started as single company product, but lets put it this way, would anyone be writing one of such languages today, had those not been languages gatekeeped to access a specific platform?
So outside accessing Max and its value preposition as product enabler for XYZ, who would be rushing to write Mojo code, instead of something else.
I think the modular proposition is to solve the AI infra problem using a modern systems programming language but with a python syntax (to keep the mental overhead low) it is mainly trying to replace C++/CUDA. I am not sure Julia is suitable for such endeavour. Julia is not marketed as a systems programming language and I find it hard to believe that it can be one as dyamically typed langauge with GC and JIT. Could Julia replace python in the high-level dynamic code space used in research and training? maybe. but I find it really hard to believe that it can replace CUDA/ROCm/C++ .. etc.
Lisp Machines from Xerox PARC, Texas Instruments and Genera proved their point, even if the market wasn't up to their price point versus UNIX graphical workstations.
Dylan was going to be Newton's system programming language, and while the language group lost the the C++ team (Apple had two competing teams for the Newton OS), it was still NewtonScript for everything userspace, and it was getting a JIT by the time the project was canceled.
Objective-C is dynamically typed beyond the common subset with C, and was used even to write NeXTSTEP drivers.
I don't know how much of a chance Julia has against CUDA/ROCm/C++, especially now that everyone on the GPU space has decided to give feature parity to Python on their hardware, via day one bindings to the compute libraries and JIT DSLs, so that makes Mojo even less of a chance than Julia has.
Julia has an established ecosystem, and presence on the scientific community with ties to MIT.
Python is the champion, and most folks writing CUDA/ROCm/C++ are already using it.
So who would be reaching out to Mojo, instead of Python JIT DSLs/bindings or Julia, when having Fortran, C, C++ allergy?
Creating DSL/Bindings for Julia or python to underlaying platform like CUDA is not really replacing it, it is yet adding another layer on top of the existing platforms or creating a prototyping envirnoment for research. The question is not can Julia interface with CUDA, it is can Julia replace C++/CUDA/ROCm in an end-to-end scenarios (preferably with portability across GPUs vendors)? if not then there is no comparison between the stated goals of Julia and Mojo. they are different langauges targeting completly different use cases.
Julia does not just have bindings to CUDA. Native Julia code can compile to build .ptx kernels https://cuda.juliagpu.org/stable/development/kernel/. This same code can also generate kernels for AMD GPUs, Intel GPUs, and Metal.
We for example built software that generates kernels on-demand that embed user functions for all 4 of these systems and showed it's much faster than just CUDA bindings for array functions for certain nonlinear systems (https://www.sciencedirect.com/science/article/abs/pii/S00457...)
That video is restricted, do you have a public link?
Doesn't seem to be restricted. Do you mean region locked?
Video isn't region locked according to the tool I normally use
https://polsy.org.uk/stuff/ytrestrict.cgi
It's the Latent Space podcast, published June 13. It's a pretty decent podcast for keeping on top of AI stuff. Swyx, one of the co-hosts, is active here on HN.
Sorry, but I'm not having any issue with that link.
Here is a link to the episode listing for that podcast, which might help.
https://www.youtube.com/@LatentSpacePod
Just worked fine for me.
I'm logged into youtube, if you're not something with that perhaps?
The factorial test giving zero on majo suggests they aren't doing arbitrary precision integer arithmetic.
I liked mojo as a python superset. Wanted to be able to run arbitrary python through it and selectively change parts to use the new stuff.
A "pythonic language" sounds like that goal has been dropped, at which point the value prop is much less clear to me.
I guess they abandoned the python superset idea? I followed them for a bit when they first publicly launched and they said "don't worry, we'll be a real python superset soon" and the biggest omission was no support for classes. A few years later, it looks to be missing the same set of python features but added a lot of their own custom language features.
I'd say less abandoned, and more deferred.
It was highly aspirational goal, and practically speaking it's better right now to take inspiration from Python and have stronger integration hooks into the language (full disclosure, I work at Modular). We've specifically stopped using the "superset of Python" language to be more accurate about what the language is meant for right now.
Deferred means it’s coming, but we don’t know if it will ever come. I’d bet it won’t.
Being a Python superset and being fast are fundamentally in tension. It would be possible, maybe, to have a Python superset where you get the highest performance as long as you avoided the dynamic features of Python. However, I suspect it would make the user base grumpy to have a hidden performance cliff that suddenly showed up when you used dynamic features (or depended on code that did the same).
The dynamic features of Python are no different from the dynamic features of Smalltalk, Self, Common Lisp, but people have been educated to expect otherwise due to the adoption failure of dynamic compilers in Python community.
From Chris Lattner on Modular discord few days ago:
Yep, that's right. Int behaving like a machine integer is very important for systems performance. Leaving the "int" namespace untouched allows us to have a object-based bigint in the future for compatibility with python. As others have mentioned above, it is still a goal to be compatible with python in time, just not a short term priority
Taking unchanged Python and making it fast is basically impossible.
Sure - but you can support unchanged Python at regular Python speed, and also have extensions to the language that can be run at higher speed.
They explicitly casted it to an 'Int' on the mojo side, but the modular website claims that isnt a specific bit-width so i am surprised
It's not a specific bitwidth in a sense that it maps to whatever largest integer type is natively supported by the target architecture (i.e. basically 32-bit or 64-bit).
[flagged]
Your comment is quite subjective, and Python's popularity both in teaching and in industry would suggest otherwise.
Taste is subjective yes, very novel insight.
Python is a hacky language that was never designed other than laying it's eggs against the grain of what we seem to mostly agree is godo — e.g. functional programming and composition.
Big tech spends a lot of money to avoid python in critical infra.
For anyone not up to speed on Mojo: Mojo is a pythonic language for blazing-fast CPU+GPU execution without CUDA:
https://news.ycombinator.com/item?id=35790367
I'm glad the blazing-fast tech is finally making it to python. Those guys were pretty busy with Rust for like the past 10 years. I'm glad they are finally starting to making a blazing-fast python stuff.
It could already be -fast, even if not blazing, if there was more love for projects like PyPy.
I am really rooting for Mojo. I love what the language is trying to do, and making it easier to run SOTA AI workloads on hardware that isn't Nvidia + CUDA will open up all kinds of possibilities.
I'm just nervous how much VC funding they've raised and what kind of impacts that could have on their business model as they mature.
If they can manage to make good on their plans to open-source it, I'll breathe a tentative sigh of relief. I'm also rooting for them, but until they're open-source, I'm not willing to invest my own time into their ecosystem.
They already released their code under the Apache 2.0 license. Not everything in their stack is open source but the core things appear to be open source.
Their compiler is not open source. They only released stdlib code.
No, Python cannot run Mojo. Like Cython and hundreds of other projects, Mojo creates a C-extension, which is then loaded.
https://docs.modular.com/mojo/manual/get-started/
No, thanks. C++ is easier.One of the big differences here is that the Mojo/Python interop package is doing a lot of the heavy lifting of compiling and loading the code. The goal here is to have a language that's close to Python that gives you hardware acceleration as you need it, without having to configure and build C++ code for every platform.
We've run a few events this year (disclosing again that I work for Modular, to put my comments into context), and we've had some great feedback from people who have never done GPU programming about how easy it was to get started using Mojo.
C++ is a powerful and mature language, but it also has a steep learning curve. There's a lot of space for making GPU (and other high performance computing) easier, and platforms/languages like Triton and Julia are also exploring the space alongside Mojo. There's a huge opportunity to make GPU programming easier, and a bit part of that opportunity is in abstracting away as much of the device-specific coding as you can.
I was a HPC C++ programmer for a long time, and I always found recompiling for new devices to be one of the most painful things about working in C++ (for example, the often necessary nightmare of cmake). Mojo offers a lot of affordances that improve on the programming experience at the language, compiler, and runtime levels.
The example in the article seemed a lot easier to build and use than a C++ extension.
It's unclear to me from this comment, what exactly your pushback is.
> C++ is easier.
I expect that opinion will not be universally agreed upon.
I am not that intrigued that Python that can call some pre-compiled functions, this is already possible with any language that produces a dynamic library.
The space that I am interested in is execution time compiled programs. A usecase of this is to generate a perfect hash data structure. Say you have a config file that lists out the keywords that you want to find, and then dynamically generate the perfect hash data structure compiled as if those keywords are compile time values (because they are).
Or, if the number of keywords is too small, fallback to a linear search method. All done in compile time without the cost of dynamic dispatch.
Of course, I am talking about numba. But I think it is cursed by the fact that the host language is Python. Imagine if Python is stronger typed, it would open up a whole new scale of optimization.
I would rather image CPython being like Common Lisp, Scheme, Raket, Smalltalk, Self compilation model.
Sadly the contenders on the corner get largely ignored, so we need to contend with special cased JIT DSLs, or writing native extensions, as in many cases CPython is only implementation that is available.
Doesn't Mojo already support this in its parameter system? https://docs.modular.com/mojo/manual/parameters/
Jitting like you mentioned is supported by the MAX graph API: https://docs.modular.com/max/tutorials/build-custom-ops. It could have a nicer syntax though to be more like Numba, I think you have an interesting idea there.
> I am not that intrigued that Python that can call some pre-compiled functions, this is already possible with any language that produces a dynamic library.
> The space that I am interested in is execution time compiled programs. A usecase of this is to generate a perfect hash data structure. Say you have a config file that lists out the keywords that you want to find, and then dynamically generate the perfect hash data structure compiled as if those keywords are compile time values (because they are).
I'm not sure I understand you correctly, but these two seem connected. If I were to do what you want to do here in Python I'd create a zig build-lib and use it with ctypes.
Can Zig recompile itself if I change a config in production? I am talking about this
``` python program.py --config <change this> ```
It is basically a recompilation of the whole program at every execution taking into account the config/machine combination.
So if the config contains no keyword for lookup, then the program should be able to be compiled into a noop. Or if the config contains keyword that permits a simple perfect hash algorithm, then it should recompile itself to use that mechanism.
I dont think any of the typical systems programming allows this.
The thing I focus on when writing compiled extensions for Python isn't the speed of the extension, but rather the overhead of the call and the overhead of moving objects from Python -> compiled and compiled -> Python.
Is there a zero-copy interface for larger objects? How do object lifetimes work in that case? Especially if this is to be used for ML, you need to haul over huge matrices. And the GIL stuff is also a thing.
I wonder how Mojo handles all that.
AFAIK, there is a zero-copy interface for objects like numpy array and torch tensors where you can do in-place manipulation in mojo.
I've never been thats sold on Mojo, I think I'm unfairly biased away from it because I find new languages interesting, and its big sell is changing as little as possible from an existing language.
That said, importing into Python this easily is a pretty big deal. I can see a lot of teams who just want to get unblocked by some performance thing, finding this insanely helpful!
> its big sell is changing as little as possible from an existing language.
This is not really true. Even though Mojo is adopting Python's syntax, it is a drastically different language under the hood. Mojo is innovating in many directions (eg: mlir integration, ownership model, comptime, etc). The creators didn't feel the need to innovate on syntax in addition to all that.
You're right- I probably should have said something like "part of its sell" or "one of its selling points" or something.
I didn't mean to undermine the ambitious goals the project has. I still wish it was a little bolder on syntax though, Python is a large and complex language as is, so a superset of Python is inherently going to be a very complicated language.
> as I'm definitely in the market for a simple compiled language that can offer Python some really fast functions So, Nim? https://github.com/yglukhov/nimpy
The real point of Mojo is not the language, it's the deep roots into MLIR which is an attempt to do what LLVM did for compilers, and do it on GPUs / ML hardware. Chris Lattner is leading the project and he created LLVM and MLIR.
FTA (emphasis added): “Chris Lattner mentioned that Python can actually CALL Mojo code now”
So, the message is that it is possible to create nice Python bindings from Mojo code, but only if your Mojo code makes the effort to create an interface that uses PythonObject.
Useful, but I don’t see how that’s different from C code coding the same, as bindings go.
Both make it easier to gradually move Python code over to a compiled language.
Mojo presumably will have the advantage that porting from Python to Mojo is much closer to a copy paste job than porting Python to C is.
wow, it compiles to python callable '.so' via PythonModuleBuilder without extra C layer needed. test cases show tight loop performance gains prime count up to 20k runs 0.011s vs 0.446s in pure python. this unlocks low friction speedups where python hits the wall. there's still type constraints factorial(100) overflows due to fixed int width, no bigint fallback. worth tracking how array handling evolves, since that'll decide if mojo stays in compute heavy corners or becomes viable for broader use. it's early but usable is the key word
For a language that announced itself (and raised a lot of money on the premise of) claiming to be "a Python superset", this does not sound like a huge achievement.
In all fairness, their website now reads: "Mojo is a pythonic language for blazing-fast CPU+GPU execution without CUDA. Optionally use it with MAX for insanely fast AI inference."
So I suppose now is just a compiled language with superficially similar syntax and completely different semantics to Python?
I think it was pretty clear immediately that running python code was a far away goal. There was a lot more talk about lifetimes and ownership semantics than details about Python interop. Mojo is more like: Can we take the learnings of Swift and Rust and solve the usability and compile time issues, while building on MLIR to target arbitrary architectures efficiently (and call it a Python superset to raise VC money).
That said, the upside is huge. If they can get to a point where Python programmers that need to add speed learn Mojo, because it feels more familiar and interops more easily, rather than C/CPP that would be huge. And it's a much lower bar than superset of python.
It marketed itself explicitly as a "Python superset", which could allow Python programmers to avoid learning a second language and write performant code.
I'd argue that I am not sure what kind of Python programmer is capable of learning things like comptime, borrow checking, generics but would struggle with different looking syntax. So to me this seemed like a deliberate misrepresentation of the actual challenges to generate hype and marketing.
Which fair enough, I suppose this is how things work. But it should be _fair_ to point out the obvious too.
Absolutely. The public sales pitch did not match the reality. This is what I meant with the "Claim to be Ṕython to get VC money" point.
To first order, today every programmer starts out as a Python programmer. Python is _the_ teaching language now. The jump from Python to C/Cpp is pretty drastic, I don't think that it's absurd that learning Mojo concepts step by step coming from Python is simpler than learning C. Not syntactically but conceptually.
Maybe young generations have some issue learning polyglot programming, I guess.
While I agree using Mojo is much preferable to writing C or C++ native extensions, back on my day people learned to program in K&R C or C++ ARM in high school, kids around 12 years old, hardly something pretty drastic.
No wonder there's so much terrible unsafe C floating around...
Many famous Speccy and C64 titles, written in Assembly, were written by bedroom coders between the ages of 14 and 16 years old, getting some pocket money writing them on the UK scene.
Get hold of Retro Gamer magazine for some of their stories.
I've tried learning C a couple times and given up because the curve is too steep to be worth the climb. It's not even the language itself, it's the inherited weight of half a century's worth of cruft. I can't spend weeks fighting with compiler nonsense, header files and #include. Screw it, I'll just use Go instead.
I'm learning Rust and Zig in the hope that I'll never have to write a line of C in my career.
Geez, what a comment. C is much much more simpler than Rust. You’re not supposed to be spending weeks fighting includes or compiler errors, that means you’re have some very basic misconceptions about the language.
Just read K&R “The C programming language” book. It’s fairly small and it’s a very good introduction to C.
C syntactically is straight forward, but conceptually may be harder than Rust. You’re exposed to the bare computer (memory management, etc) far more than with a GC language or even Rust arguably, at least for simple programs.
Towards deployment is even harder. You can very easily end up writing exploitable, unsafe code in C.
If I were a Python programmer with little knowledge about how a computer works, I’d much prefer Go or Rust (in that order) to C.
Rust memory model is very complicated. C memory model is very straightforward.
This is true, but when you get something wrong related to the memory model in C, it just says "segfault". Whereas in Rust it will give you a whole explanation for what went wrong and helpful suggestions on how to fix it. Or at the very least it will tell you where the problem is. This is the difference between "simple" and "easy".
C before C11 has no memory model. Rust doesn't have one but effectively it inherits the C++/C memory model, so there is actually no difference.
That applies only if you take "memory model" to mean modeling the effects of concurrent accesses in multithreaded programs.
But the term could also be used more generally to include stuff like pointer provenance, Rust's "stacked borrows" etc. In that case, Rust is more complicated than C-as-specified. But C-in-reality is much more complicated, e.g. see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2263.htm
The model you're referring to, a Memory Ordering Model, is literally the same model as Rust's. The "exception" is an ordering nobody knows how to implement which Rust just doesn't pretend to offer - a distinction which makes no difference.
I do sympathize with the parent: The language itself might not be that difficult but you also have to factor in the entire ecosystem. What's the modern way to a build a GUI application in C? What's the recommended way to build a CLI, short of writing your own arg parser? How do you handle Unicode? How do you manage dependencies, short of vendoring them? Etc.
Errors too. When, inevitably, you make mistakes the C might just compile despite being nonsense, or you might get incomprehensible diagnostics. Rust went out of its way to deliver great results here.
I am not arguing about how good or easy it is to use C in production, I’m merely stating that parent complaints about weeks of insolvable errors and issues with includes screams that he needs to read some good resource like book, because he is definitely misunderstanding something important.
Even more than that: "How do you do a string?" has like 100 answers in C depending on what libraries are available, what your deploy target is...
THe thing is, if one is an expert it is incredibly difficult to understand the beginner perspective. Here is one attempt:
C is simpler than Rust, but C is also _much_ simpler than Python. If I solve a problem in Python I have a good standard library of data types, and I use concepts like classes, iterators, generators, closures, etc... constantly. So if I move to Rust, I have access to the similar high-level tools, I just have to learn a few additional concepts for ressource management.
In comaprison, C looks a lot more alien from that perspective. Even starting with including library code from elsewhere.
Agreed, I do bash C a lot, and it has plenty of issues, but hardly a monster that a mythological hero has to face.
And as tip for pointers, regardless of the programming language, pen and paper, drawing boxes and arrows, are great learning tools.
Writing hello world in C is easy. Writing complex software without memory issues and vulnerability is pretty hard.
FWIW generics are already a thing in pure Python as soon as you add type annotations, which is fast becoming the default (perhaps not the least because LLMs also seem to prefer it).
I think one of the "Python superset" promises was that any particular dev wouldn't need to learn all of that at once. There could exist a ramp between Python and "fast python" that is more gradual than the old ways of dropping into C, and more seamless than importing and learning the various numpy/numba/polars libraries.
They've backed off a little from the Python superset claims and leaned more into "Python family".
> I'd argue that I am not sure what kind of Python programmer is capable of learning things like comptime, borrow checking
One who previously wrote compiled languages ;-). It's not like you forget everything you know once you touch Python.
The second part of the sentence is very important ;)
"... but would struggle with different looking syntax"
I think the point was that Python syntax is simpler than e.g. borrow checking.
Although Python has some seriously PERLesque YOLO moments, like "#"*3 == "###". This is admittedly useful, but funny nonetheless.
I suppose if you accept the innocent-looking "#"+"#"=="##" then your example kind of algebraically follows. Next it's time to define what exp("#") is :)
* does different things depending on the types of the operands, which is Python's strong typing at work, not Perlesque weak typing. Repeating a string is a useful thing to be able to do, and this is a natural choice of syntax for it. The same thing works for lists: [1]*3 == [1, 1, 1].
It does unfortunately mean that sometimes `*` will work (and produce an incorrect result) rather than immediately failing loudly with a clear error message in the context in which it's actually intended to be numerical.
More broadly this is the same argument as whether overloading `+` for strings is a bad idea or not, and the associated points, e.g. the fact that this makes it non-commutative - the same all applies to `*` as well, and to lists as much as strings. At least Python is consistent here.
Although there is one particular aspect that is IMO just bad design: the way `x += y` and `x = y` work. To remind, for lists these are not equivalent to `x = x + y` and `x = x y` - instead of creating a new list, they mutate the existing one in place, so all the references observe the change. This is very surprising and inconsistent with the same operators for numbers, or indeed for strings and tuples.
I was referring to the "creative syntax" and it wasn't meant to be an attack on Python.
We cannot deny that Python has some interesting solutions, such as the std lib namedtuple implementation. It's basically a code template & exec().
I don't think these are necessarily bad, but they're definitely funny.
> and call it a Python superset to raise VC money
What else was proclaimed just to raise VC money?
The real unique selling point of Mojo is "CPU+GPU execution without CUDA", specifically, you write code that looks like code without worrying about distinctions like kernels and device functions and different ways of writing code that runs on GPU vs. code that runs on CPU, and mojo compiles it to those things.
> For a language that announced itself (and raised a lot of money on the premise of) claiming to be "a Python superset", this does not sound like a huge achievement
I feel like that depends quite a lot on what exactly is in the non-subset part of the language. Being able to use a library from the superset in the subset requires being able to translate the features into something that can run in the subset, so if the superset is doing a lot of interesting things at runtime, that isn't necessarily going to be trivial.
(I have no idea exactly what features Mojo provides beyond what's already in Python, so maybe it's not much of an achievement in this case, but my point is that this has less to do with just being a superset but about what exactly the extra stuff is, so I'm not sure I buy the argument that the marketing you mention of enough to conclude that this isn't much of an achievement.)
I've written this somewhere else before, Modular did not raise $130m to build a programming language, nobody does that. They raised that much money to revolutionize AI infrastructure, of which a language is just a subset. You should definitely check some of the things they've put together, they're amazing
Yes. They are revolutionizing AI infrastructure but I guess a lot of world is just babbling about AI, but not every developer needs to worry about AI.
And so his improvements in mojo and now calling mojo code from python just make a lot more net positive to the community than being, some other Ai infrastructure company.
So I do wish a lot of good luck to mojo. I have heard that mojo isn't open source but it has plans to do so. I'd like to try it once if its as fast / even a little slower than rust and comparable to understanding as python.
I don't think investors look at what makes a net positive to the community when making large investments like in Modular. I was calling out the part of the post that said Modular raised a lot of Money to develop Mojo, that isn't entirely true as just creating a language isn't enough reason to invest $130m into a company, no matter how much net-positivity the language would bring.
Agreed, Modular is walking a very fine line, and they're doing so by trading on the reputation of Chris Lattner.
On the one had, as the other poster noted, no one raises $100M+ for a programming language; programming languages have no ROI that would justify that kind of money. So to get it, they had to tell VCs a story about how they're going to revolutionize AI. It can't just be "python superset with MLIR". That's not a $100M story.
On the other hand, they need to appeal to the dev community. For devs, they want open source, they want integration with their tools, they don't want to be locked into a IP-encumbered ecosystem that tries to lock them in.
That's where the tension is. To raise money you need to pretend you're the next Oracle, but to get dev buy-in you have to promise you're not the next Oracle.
So the line they've decided to walk is "We will be closed for now while figure out the tech. Then later once we have money coming in to make the VCs happy, we can try to make good on our promise to be open."
That last part is the thing people are having trouble believing. Because the story always goes: "While we had the best intentions to be open and free, that ultimately came secondary to our investors' goal of making money. Because our continued existence depends on more money, we have decided to abandon our goal of being open and free."
And that's what makes these VC-funded language plays so fraught for devs. Spend the time to learn this thing which may never even live up to its promises? Most people won't, and I think the Darklang group found that out pretty decisively.
Fwiw the website still claims this:
> Further, we decided that the right long-term goal for Mojo is to adopt the syntax of Python (that is, to make Mojo compatible with existing Python programs) and to embrace the CPython implementation for long-tail ecosystem support
Which I don't think has changed.
I believe they're still working towards making the syntax and semantics more python-like.
It was never going to have Python semantics and be fast. Python isn't slow because of a lack of effort or money, it's slow because of all the things happening in the interpreter.
I like mojo for being closer to python than other systemsy languages.
But asking people to learn another language and migrate is a tall barrier.
Why not write python and transpile to mojo?
My impression is that mojo is not python, there are similarities, but under the hood mojo is much more similar to c++/rust.
As part of this it has a stronger type/lifecycle/memory model than python.
Maybe you could write, some level of transpiler, but so much of the optimizations rely on things that python does not expose (types), and there are things that python can do that are not supported.
Transpilers in general tend to be significantly less well maintained and optimised than direct APIs
I'm not a disinterested observer.
Py2many has had a mojo backend for a year now.
https://github.com/py2many/py2many/tree/main/tests/expected
The plan is to have a mechanical tool someday that can transpile Python code to Mojo
Are labels on first output misplaced or mojo was actually slower?
’’’ 3628800 Time taken: 3.0279159545898438e-05 seconds for mojo
3628800 Time taken: 5.0067901611328125e-06 seconds for python ’’’
The Python function is implemented in C and uses a faster algorithm [1], and this particular factorial is so small they put it in a lookup table [2]. It is a strange and very unequal choice for a demo.
[1] https://github.com/python/cpython/blob/0d9d48959e050b66cb37a...
[2] https://github.com/python/cpython/blob/0d9d48959e050b66cb37a...
My guess is that the slight overhead of interacting with mojo led to this speed discrepancy, and if a higher factorial (that was within the overflow limits etc) was run, this overhead would become negligible (as seen by the second example). Also similar to jax code being slower than numpy code for small operations, but being much faster for larger ones on cpus etc.
I hope this ends up superseding Cython
Same, and I literally started Cython. :-)
What's your current take on Cython vs other options? E.g. DSLs and I guess PyO3?
I think that's one of the real strong use cases I see coming up.
If they can make calling Mojo from Python smooth it would be a great replacement for Cython. You also then get easy access to your GPU etc.
I really want to use mojo/max for graphics and game programming, but they don't seem interested in going that route.
I’m someone who should be really excited about this, but I fundamentally don’t believe that a programming language can succeed behind a paywall or industry gatekeeper.
I’m always disappointed when I hear anything about mojo. I can’t even fully use it, to say nothing of examine it.
We all need money, and like to have our incubators, but the LLVM guy thinks like Jonathan Blow with jai?
I don’t see the benefit of joining an exclusive club to learn exclusively-useful things. That sounds more like a religion or MLM than anything RMS ever said :p
> the LLVM guy thinks like Jonathan Blow with jai?
I would not compare Chris Lattner with Jonathan Blow. Lattner is a person with a reputation for delivering programming languages and infrastructure; whereas for Blow, it seems like an ego issue. He's built a nice little cult of personality around his unreleased language, and releasing it will kill a lot of that magic (running a language project with actual users that has to make good on promises is much different than running a language project with followers and acolytes that can promise anything and never deliver on it).
Lattner has a record of actually delivering dev products people can download and use. Mojo is closed source to make raising money easier, but at least you can actually use it. Jai isn't even available for people to use, and after a decade of Blow dangling it in front of people, it's not clear it'll ever be available, because I'm not sure he wants it to be available.
> Functions taking more than 3 arguments. Currently PyTypeBuilder.add_function() and related function bindings only support Mojo functions that take up to 3 PythonObject arguments: fn(PythonObject, PythonObject, PythonObject).
Lol wut. For the life of me I cannot fathom what design decision in their cconv/ABI leads to this.
I was wondering if it is function overloads of the same name, defining it non-variadically:
add_function(PythonObject)
add_function(PythonObject, PythonObject)
add_function(PythonObject, PythonObject, PythonObject)
There was a similar pattern in the Guava library years ago, where ImmutableList.of(…) would only support up to 20 arguments because there were 20 different instances of the method for each possible argument count.
Probably not, since they would surely up it at least 15 arguments, instead of 3. But what else, then?
> truck of salt
:)))
i wish python were as fast as perl for equivalent string-based workloads
https://en.wikipedia.org/wiki/Mojo_(programming_language)
> As of February 2025, the Mojo compiler is closed source
And that's where the story begins and ends for me.
https://docs.modular.com/mojo/faq/#open-source
> Will Mojo be open-sourced?
> We have committed to open-sourcing Mojo in 2026. Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out.
Soon it might be though.
Many thanks for the update on this particular aspect of it. That rules it out of any production deployment until 2026 so.
> That rules it out of any production deployment until 2026 so.
Has that stopped everyone before? Java, C#/.NET, Swift and probably more started out as closed-source languages/platforms, yet seemed to have been deployed to production environments before their eventual open-sourcing.
Many developers had no problem using .NET and C# in production despite them starting out as closed-source for years.
I don't think Java (when it was owned by Sun) nor .NET (even currently) run the risk of a VC "our incredible journey" event causing "barrel bending" nor the backing company running out of money. In the first flavor, they'd want their pound of flesh and the "our new compiler pricing is ..." would be no good. In the latter, even if they actually opened the platform on the way out, it still would require finding a steward who could carry the platform forward, which is a :-( place to be if you have critical code running upon it
I guess the summary is that neither Java [at the time] nor .NET were profit centers for their owners, nor their only reason for existing
They certainly were, because no one other than a few hardlines were writing Java or C# and VB code in bare bones editors and compiling from command line, as only the bare bones SDKs were free beer, and for the desktop.
IDEs, implementations for embedded and phones, were all paid products, IDEs by developers or their employers, the others by OEMs.
My point is the early days, JCafe, Visual Age, Visual Studio, Forte, before free beer IDEs for them became common.
Java side with Eclipse/Netbeans, .NET side with the Visual Studio Express editions.
Yes, and there is a reason for that: Both are deeply integrated in Microsofts ecosystem, and whether one likes that or not, that ecosystem is the dominant platform for desktop computing, especially in commercial settings.
What would be comparable driver for Mojo?
https://i.imgur.com/0NaxFGB.png
Was lowkey hoping this was about Mojolicious, the Perl web framework
Yeah, I also get confused with references. I was annoyed from the start, when "Mojo" was announced as a Python family language. Mojolicious uses the "Mojo" namespace and is referred to as that quite often. I know Perl is not as popular as it used to be, but Mojolicious is probably the most popular framework of a language that is roughly in the same "space" as Python, so that naming choice was very ignorant IMHO.