Mojo 1.0 Beta
mojolang.org
mojolang.org
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.
I still prefer the structure in Mojo, but boy do I miss if/switch as expressions.
Hopefully they get Mojo to a good place for more general ML, but at the moment it still feels quite limited - they've actually deprecated some of the nice builtins they had for Tensors etc... For now I'll stick with JAX and check in periodically, fingers crossed.
Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.
Doesn't matter if it was closed, when the alternatives were much worse.
I can also recite the whole story, the missteps in OpenCL 2. , OpenCL C++, the OpenCL 3.0 reboot, how SYCL came to, CodePlay only proper available implementation, Intel acquisition of CodePlay and everything else.
(Among other reasons, but that's easily the main one.)
> We're committed to open-sourcing all of Mojo, but the language is still very young and we believe a tight-knit group of engineers with a common vision moves faster than a community-driven effort. So we will continue to plan and prioritize the Mojo roadmap within Modular until more of its internal architecture is fleshed out.
I hope they stick to their original promise. And the 1.0 release would be a great time to deliver this.
Translated from corporatese it means "it will never happen".
Release the source, but don't take code from external contributors. Take issues and discussion instead
This is a false dichotomy.
For years Golang was developed in the open but strictly moved on the vision of its creators rather than being "community-driven". Many other venerable open source projects don't involve the community in serious strategy discussions. The community mainly acts as a bug finder/fixer. Mojo could do the same: be open source but choose its own priorities internally.
I'm guessing that Mojo is still looking for a monetization strategy. Keeping important things proprietary in Mojo at this stage helps I'm sure (nothing wrong with that).
But I feel the era of proprietary programming language play is over. Unless you create some hardware (which the Mojo guys don't) it's going to be tough.
All the flaws I can think of in Kotlin are due to the Java compatibility. They could've made it work here by being more explicit but the way it currently works seems doomed.
Yes the underlying platform they based their compatibility on, is the reason they got some design flaws, some more than other.
However that compatibility is the reason they won wide adoption in first place.
All the use of Kotlin in industry are due to Java compatibility. Else there would be ~0% marketshare of Kotlin.
> Supporting more of Python's dynamic features like classes, inheritance, and untyped variables to maximize compatibility with Python code.
What's more, note how it says "to maximize compatibility" not "to achieve full compatibility."
In reality I think they've dropped that pretty hard. Literally you can't even get the length of a string with `len(s)` in the latest release. They also removed negative indexing, which I find baffling and frustrating. The roadmap does say they don't intend to have any "syntax sugar" until later in the implementation, but negative indexing is such a core part of what makes Python so much nicer to work with compared to say C++...
Surely this is the sort of thing compiler / language design nerds dream about?
It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist!
My understanding is that we can make such a language … but it’s not caught the fancy of someone who could do it
That’s what compilers and high level languages are supposed to be for!
Yes, it can, but only by eliminating the features that make it Turing complete. It’s relatively easy to vectorize map with a closure that can’t mutate anything but once you have nontrivial control flow, the compiler can’t make those kinds of assumptions.
Missing some features but roughly has the idea. Keep faith with human ingenuity!
It's already (partly) existed called D language, by default it's garbage collected (GC), can also be program without it or hybrid. It's a modern, backward compatible with C and it's included in GCC.
The linear algebra system in D or Mir GLAS is standalone BLAS implementation written directly in D [1]. It's already proven faster than the other widely existing conventional BLAS like OpenBLAS back in 2016, about ten years ago!
This popular OpenBLAS include Fortran based LAPACK (yes you read it right Fortran) and it is being used by almost all data processing languages currently Matlab, Julia, Rust and also Mojo [2].
Interestingly there is a very early stage of standalone BLAS implementation written directly in Mojo namely mojoBLAS similar to Mir GLAS just started very recently [3].
>Surely this is the sort of thing compiler / language design nerds dream about?
You can say this again.
Especially on the GC side of the programming language since this SIMD / multi thread / multiprocessing / GPU can be abstracted away.
Actually someone recently proposed VGC or virtualized garbage collector for Python in C++ for heteregenous GC [4],[5]. However, the current evaluation excludes JIT compilation, AOT optimization, SIMD acceleration, and GPU offloading.
[1] OpenBLAS:
https://en.wikipedia.org/wiki/OpenBLAS
[2] Numeric age for D: Mir GLAS is faster than OpenBLAS and Eigen:
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...
[3] mojoBLAS:
https://github.com/shivasankarka/mojoBLAS
[4] Virtual Garbage Collector (VGC): A Zone-Based Garbage Collection Architecture for Python's Parallel Runtime:
https://arxiv.org/abs/2512.23768
[5] VGC-for-arxiv:
Currently supports CPU and GPU on macOS and CPU on linux.
https://github.com/kiwi-array-lang/kiwi
Kiwi runs computations on small dense arrays in its own runtime, when they are larger it will lower to MLX CPU and eventually to MLX GPU when it is worth it.
As user you don't have to change any code, you just write k.
I'm sure there are other languages designed to take advantage of modern GPUs.
But even with SIMD you can get quite far with array oriented code and many array language implementations will make use of it (BQN, ngn/growler/k, goal, ktye k has a version with SIMD support, …)
I’ve yet to find a language that does SIMD / multithreading / GPU with minimal tweaks let along multiprocessing.
Definitely the closest thing so far (doesn’t do multiprocessing) but does seem to do SIMD / multithreading and GPU auto parallelizing!
Any idea why it’s so little known?
https://ispc.github.io/ Also seems promising
https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced
IREE [2] is very actively developed ML compiler + runtime, also MLIR-based.
Event though it's not portable, it will likely have far greater usage than Mojo just by being heavely promoted by Nvidia, integrated in dev tools and working alongside existing CUDA code.
Tile IR was more likely a response to the threat of Triton rather than Mojo, at least from the pov of how easy is to write a decently performing LLM kernel.
You always need to touch the hardware/platform APIs at some level, because even if the same code executes the same, the observed performance, or in the case of GPUs the numeric accuracy has visible side effects.
Of course, this won't be necessary in most cases if you're building on top of abstractions provided by Modular.
You don't get this choice using vendor-specific libraries; you're locked into this or that.
That is the thing with Mojo, when it arrives as 1.0, the LLM progress and the investment that is being done in GPU JITs for Python, make it largely irrelevant for large scale adoption.
Sure some customers might stay around, and keep Modular going, the gold question is how many.
Mojo and Modular's Max platform would do to heterogeneous compute what LLVM did to programming language development. People who dismiss the real value offering here know nothing. Modular have already raised $350m+ from industry giants (including Nvidia and Google) to solve this, and I believe they will.
Why should they? CUDA is a GPGPU paradigm, AMD/Apple/Intel all ship diverse raster-focused hardware, and TPUs are a systolic array. How much can you realistically expect to abstract with unified primitives? How much performance do you perceive to be left on the table with native CUDA-based implimentations?
Pytorch's abstractions answer this by ignoring raster hardware conventions entirely. The underlying ATen library is basically a CUDA wrapper, which is not much of a surprise since nobody else is willing to standardize a better alternative. We learned as much when OpenCL died, and now that Khronos is riding into the sunset it's unlikely we'll even see that level of paltry early-2010s cooperation. Mojo really should have taken Vulkan's lessons to heart; you need stakeholders to succeed, simply "disrupting" the proprietary status quo is a recipe for coming dead last in adoption rates.
> People who dismiss the real value offering here know nothing.
So explain the value, then. This is not an "optimize this IR for MIPS and x86" problem, the Lattner Fairy can't shoehorn shaders into every CUDA Compute Capability to make raster GPUs a viable GPGPU platform. If you followed Geohot's gradual descent into (sadly, quite literal) insanity then this would have been glaringly obvious from the offset. Tinygrad has an IR, industry-scale support, multiplat deployment, and it's still a dumpster fire. The project exacerbated all of the issues in ROCm and Metal, without contributing to any form of upstream cooperation between CUDA's competitors. If Mojo goes the same route with a more ambitious goal, they'll end up entrenching CUDA and obsoleting themselves. As much as people hate to admit it, CUDA is less of a software moat and more of a hardware one.
Ah, it seems impossible to you. These are very different hardwares... It is hard enough to make compatibility among different hardwares of the same vendor. Very difficult to imagine building primitives for hardwares with completely different memory layouts.
> How much performance do you perceive to be left on the table with native CUDA-based implimentations?
Zero is the idea. And I wasn't saying there should be a native cuda-based implementation, I'm asking you to imagine how much easier everything would have been if Cuda was cross-platform without any performance or ergonomic penalties.
Mojo is a foundational step here. The big HOW is powerful parametric programming. So much information could be passed during compile time which the compiler uses to specialize.
In effect, they are completely different hardware. The only thing any of them have in common is rasterization primitives, so unless you're focused on render workloads you're nearly better off software-accelerating the language for CPUs instead. As a point of comparison, go look at early ray tracing implementations on GPUs that have no dedicated RT blocks or hardware-accelerated denoising. They were oftentimes slower than software-accelerating the same thing on a cheaper CPU.
> I'm asking you to imagine how much easier everything would have been if Cuda was cross-platform
...you are aware of what CUDA actually does, right? Mojo is not a cross-platform version of it. At risk of repeating myself, creating an OpenCL-style library without a Khronos-style consortium does not address the problem. CUDA is a hardware solution, you need to define standards around GPGPU programming because that's what Nvidia does internally. Ignoring industry-wide standardization is the express bet that Nvidia and Google are making, investing in Mojo. Without any hardware stakeholders, Mojo's only opportunity is to become a DirectML/ONNX-style middleware like @pjmlp suggested. Spoiler: that's not a super disruptive or successful goal. Certainly not an LLVM scale opportunity.
> So much information could be passed during compile time which the compiler uses to specialize.
Like what? None of this is a rhetorical question, explain to me what information would help bring GPUs and TPUs up to parity with CUDA. What information are you thinking of that isn't currently expressed in SPIR-V and MLIR? What optimizations do you have in mind?
They can also do matrix multiplication, which is the relevant thing here.
Mojo is not an OpenCL-style library; it is a programming language, and it doesn't really abstract much. However, it is designed to support compilation to exotic hardware. Cuda CPP can also be thought of as a language; however, the compilation model and core primitives are fundamentally tied to Nvidia hardware.
> Like what? None of this is a rhetorical question, explain to me what information would help bring GPUs and TPUs up to parity with CUDA.
One primitive would be a data/memory abstraction libary like CuTe but for more than Nvidia: https://mojolang.org/nightly/docs/layout/
Another is a programming model that allows you to specialise based on hardware and hardware capabilities: - https://github.com/modular/modular/blob/c71933db1b22b6a91749... - https://github.com/modular/modular/blob/c71933db1b22b6a91749...
And finally, a novel compilation model that knows how to compile and link code for esoceteric hardwares: - https://www.youtube.com/watch?v=77Z_kngHs00
Not to mention efforts like GraalPy and PyPy.
And all these efforts work today in Windows, which is quite relevant in companies where that is the assigned device to most employees, even if the servers run Linux distros.
I keep wondering if this isn't going to be another Swift for Tensorflow kind of outcome.
It only has to be good enough, to keep the ecosystem going, and the porting cost not be worthwhile, when Mojo finally reaches parity.
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.
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.
For me this was a big disappointment, and I wonder how much this has backfired across developers.
That and the not completely open source development model is what has always felt very vaporwary to me.
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.
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.
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.
Leaving aside that this is still distinct from the speed of light, can you tell me how this would have in any way influenced the design of mojo?
I think you're a bit too angry already to interpret what he's saying as how he meant it. You seem to be twisting everything to make it sound stupid.
However, I'll happily acknowledge that I'm fallible and that perhaps this argument is all a product of my neuroses.
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.
Chris Lattner talked more about the relationship between MLIR and Mojo than Python and Mojo.
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.
https://chapel-lang.org/docs/language/spec/classes.html#clas...
"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.
https://hpsf.io/blog/2026/hpsf-project-communities-to-gather...
https://developer.hpe.com/platform/chapel/home
See "Projects Powered by Chapel".
Chapel current version is 2.8.0.
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.
> 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.
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
Can anyone of the AI enthusiasts here explain, why, or, what is meant by
> As a compiled, statically-typed language, it's also ideal for agentic programming.
> why, or, what is meant by More errors caught at compile time means an agent can quickly check their work statically without unit and other tests.
Regarding compilation and static typing, it's extremely helpful to be able to detect issues at compile time when doing agentic programming. That way, you don't run into as many problems at runtime, which of course the agent has more difficulty addressing. Unit tests can help bridge the gap somewhat but not entirely.
What's not stated on their website is that Mojo is likely a bad choice for agentic programming simply because there isn't much Mojo training data yet.
But yea, to write mojo 1.0 code even after getting errors might take a new training round, so next or even next-next models.
So, agents tend to do better the more feedback they can get. Type checking is pretty good for catching a bunch of dumb mistakes automatically.
The point is more hints for the agent is more better most of the time.
Python+ruff+pycheck and TypeScript are compiled to bytecode instead of machine code. They’re not statically typed in the Rust sense. And yet, I’ve watched model crank out good, valid in both of those without needing to be either strictly “compiled” or “statically typed”. Turns out AI couldn’t care less about those properties as long as you have good tooling to quickly check the code and iterate.
yes, except it's more ... on the same lines, just to hammer the point home:
it's web 2, it's SaaS, it's the latest weekly, er, sorry, daily, hottest JS framework, its the latest rap / punk / hippie / dreadlock / crewcut / swami / grunge/ guru hairstyle, it's agile, it's functional programming, it's OOP, it's OOAD, it's UML, its the Unix philosophy, its Booch notation, it's CASE tools, ... going back even further, it's structured programming, it's high-level languages, it's assemblers, its veganism, it's the keto diet, it's the Atkins diet, it's the paleo diet, it's cholesterol is bad, no, it's good, etc etc etc.
> only to jump on the next bandwagon next week, month
Thus this desparate "AI native" marketing is probably necessary to even be considered relevant in an "agentic" world. Whether it's enough, only time will tell.
Python cuTile JIT compiler allows writing CUDA kernels in straight Python.
AMD and Intel are following up with similar approaches.
If Mojo will still arrive on time to gain wider adoption remains to be seen.
It is currently not straight Python and will never be.
All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.
They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues.
Lets not lie to ourself: Python is inherently bad for efficiency and performance.
And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency.
The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse.
Mojo is different.
Mojo tries to start from a clean sheet instead of hacking the existing crap.
And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old)
And just for that, I wish them success.
As for Python not being the ideal, there we agree, but the solutions with proper performance already exist, Lisp, Scheme, Julia, Futhark,...
Heck maybe someone could dig out StarLisp.
I did not argue about CUDA being proper C++ :)
I honestly believe that the best days of C++ as an accelerator language are behind.
That is the main problem currently: We do miss a modern language for system programming that play well with accelerators. C++ is not (really) one of them (Hello aliasing).
I do not know if Mojo will succeed there, but I wish them good luck.
Which is the whole point. Python has properties that make it bad for massive, fast number twiddling. However, it’s exceptionally nice for doing all the command line parsing and file loading and setup and other wrapping tasks required to run those pipelines.
Fortran’s fantastic at math stuff. I’d sure hate to have to write all the related non-math stuff in it.
And yes, Python’s slower than other languages. But in production, most Python code spends a huge chunk of its time waiting for other code to execute. It takes more CPU for Python to parse an HTTP request or load data files than an AOT language would take, but it’s as efficient sitting there twiddling its thumbs waiting for a DB query or numeric library to finish.
> most Python code spends a huge chunk of its time waiting for other code to execute.
Highly dependent on what you are doing. That hasn't been my experience most of the time.
I guess depends on your reference point :-) I recall in the beginning, python offering an easier/more readable alternative to Perl, which itself was a step up from awk/sed/sh script (for the tasks/uses GP mentions)
Their whole original pitch was to be a superset of Python btw.
To my understanding, they offer a full python compatibility but guide the user to something else.
For instance, Mojo itself is statically typed.
While I believe that Chris Lattner is a great compiler designer, his language design record has been less stellar. Swift bidirectional type inference for instance feels like it was implemented because they had a compiler algorithm that they wanted to use, rather than a genuine need, and is just a completely avoidable problem. Trying to make a HPC language that is also Python compatible was doomed from the start. Hopefully the damage from going into this direction will remain limited.
I think that nowadays with vibe/agentic coding, high performance Python-like languages become ever more important. Directly using AI agents to code, say, C++, is painful as the verbose nature of the language often causes the context window to explode.
Microsoft is invested into using AI for C++ code review, for example.
From my experience, AI revolves a lot around building up function pipelines, computing their derivatives, and passing tons of data through them; which composability and higher order functions from functional programming make it a breeze to describe.
I also feel that other fields than AI are moving towards building up large functional pipelines to produce outputs, which would make mojo suitable for those fields as well. I’m building in the space of CAD for example and I’d love to use a “functional mojo” language.
Meanwhile Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA.
Python cuTile JIT compiler allows writing CUDA kernels in straight Python.
AMD and Intel are following up with similar approaches.
So will Mojo still arrive on time to gain wider adoption?
Time will tell.
One would want to see either a strong community build up around it, or really hard evidence for a long-term commitment to the language from Modular. And the latter will take a long time to be assured of I think.
Also, editing tools need to catch up before very wide adoption of a language with a lot of new syntax.
I bet that’s true for a great many people. There are too many wonderful FOSS languages to bother with one you can’t fix or adapt or share.
- The MLIR approach, which was also designed by Chris Lattner while at Google, has proven quite valuable to create Python JIT DSL
- The Python ecosystem now being taken seriously by the main GPU vendors, thanks to MLIR, as all their proprietary compilers are based out of LLVM
- Others remember Swift for Tensorflow
For example you need to use some Mojo Max library to have fast optimized LLM kernels, but at that point you can just stay with Python that has fast optimized LLM kernels, like flashinfer.
Overall I think there is going to be a lot of "old" gpu compute hanging around, and now that writing kernels is a lot easier than it has been, we might as well try and see what algorithms we can get working there.
I originally picked up Mojo for the SIMD, not for the GPU kernels. The SIMD usability in Mojo is outstanding.
Paper on the tool I wrote: https://doi.org/10.1093/bioadv/vbaf292
What's "alignment" in your context. In bioimaging it usually refers to aligning something to a reference atlas (like the Allen Reference Mouse Brain Atlas) or aligning two microscope channels (like the red channel and green channel)
I have been pretty hopeful about Mojo as I find many of the modern compiled languages these days requires an surprisingly excessive amount of ceremony just to open a file and read it line by line. At least this is the case with Go, as I've written about [1].
If Mojo is providing any kind of python like experience in this matter, I will be all into it again (it lacked these features when I last tried).
The syntax i Mojo really seems to shine a lot ... though I still wonder if the train has already left now that so much bioinfo work is already done in Rust.
Someone else here is bringing up Julia. Which I think is a fine language but the compiler error messages and the library documentation are not what I would want in a language as far along as it is. I'm also worried about the correctness issues I've read about in a blog awhile back. Also I don't feel like I can make the kind of Python module I want with it (because of binary size and time to first x)
That being said I'm only hoping that Mojo can become an option. But I really like to use a REPL and I like the dynamicness of Python. So I might not ever get around to doing anything outside of maybe Numpy for performance.
I also think Mojo is more focused on being an industrial strength language. I was shocked to see the first iteration of Julia ahead of time compilation did not provide file I/O.
For me it's the opposite - the only thing I like about Python is it's syntax. That's why I really like Nim - you get C speed, "comptime", metaprogramming, powerful type system, memory safety and code is often short and elegant.
Mojo seems interesting too, but so far they're mostly focused on ML stuff and not general programming. And I believe compiler is still not open-source?
If more than a few percent of execution time is spent in Python you are probably doing it wrong.
Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages:
<https://pypi.org/project/rustimport/>
<https://pypi.org/project/import-zig/>
Note that you can even start threads in those languages and use function calls as pseudo-RPC. All without an overly complex build system.
Already available on GCC 16.
Also tools like numba can beat them all at way less effort.
Imho, dropping into other languages should be the last resort in any project.
Every program that starts with 1% of Python writes more Python and gets to 20,40, 60 and than 99% of it.
> Mojo 1.0 will be finalized later this year, along with opening the compiler and providing language stability.
https://www.modular.com/blog/modular-26-3-mojo-1-0-beta-max-...
Since there is not much Mojo code in the wild so the LLMs were trained on it, I wonder how it will work in practice.
Probably the agents will make lots of mistakes and you will spend 10x the tokens compared to using a language the model are well versed in.
If Mojo succeeds, it could be the one language spanning across those levels, while simplifying heterogeneous hardware programming.
But then I read this:
> AI native
> Mojo is built from the ground up to deliver the best performance on the diverse hardware that powers modern AI systems. As a compiled, statically-typed language, it's also ideal for agentic programming.
Well, no thank you. I know the irony here but I want nothing to do with a language made for robots.
Go on, give it a shot. It stops being intimidating soon! And remember that the uv we all love was heavily influenced by Cargo.
I remember Rust very fondly in fact. And I had the same experience as you, learning Rust made me a better Javascript programmer. Lets see if a little neural network can be as fun.
Some alternatives are as old as 1958.
Things like optimizing away object allocations, pure function inlining, tail call optimization?
Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
Funny you should say that... there was recently a very interesting announcement for a Julia-to-WASM compiler and a full-stack signals-based web framework:
https://discourse.julialang.org/t/ann-experimental-wasmtarge...
> Both repos were built iteratively with LLM coding agents
I think I would rather just use Rust.
Modular is giving you at least a public promise that they will open source Mojo it this year but some how here it is a problem.
Unbelievable.
For instance, you can write Python without using CUDA. CUDA's existence doesn't make Python less useful. But what do you do when you bump into a bug in Mojo? You have no ability to fix it yourself. At best, you can report it to the authors and hope they care enough about it to put in the work and release an update. If you run into a Python problem, you, or someone in your org, or a paid consultant, can fix it even if the Python core team doesn't care about it.
But somehow it is a problem when Modular gives a single promise to open-source their Mojo compiler?
> For instance, you can write Python without using CUDA. CUDA's existence doesn't make Python less useful. But what do you do when you bump into a bug in Mojo? You have no ability to fix it yourself.
You don't use AI training / inference with bare Python at all.
PyTorch (which almost all AI researchers use) primarily uses CUDA as the default and it is less useful without it (all other backends are slower). If there is a bug in anywhere from PyTorch to the silicon, you need to investigate if it is a PyTorch problem, C++ or Python issue or both, or a CUDA driver issue.
So a bug in one place (Mojo) vs a bug in 4 different places and one of them (CUDA) will never be open source. The latter is worse.
> At best, you can report it to the authors and hope they care enough about it to put in the work and release an update. If you run into a Python problem, you, or someone in your org, or a paid consultant, can fix it even if the Python core team doesn't care about it.
You are assuming Modular will never open source the Mojo compiler, when it is clear that Nvidia has been completely hostile to opening anything related to CUDA and its compiler.
That's a very big claim.
Just wanted to provide an easy counterpoint to the logical fallacy by IceDane.
The “build”/run/deploy system was the other major issue. All the python versions, virtual env etc seemed like a mess. A compiled language is so much better(I.e Go, Rust etc) IMHO.
What’s that supposed to mean?