alt.hn

5/8/2026 at 2:49:01 AM

Mojo 1.0 Beta

 https://mojolang.org/

by sbt567

5/8/2026 at 8:08:54 PM

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc.

Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.

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

by totalperspectiv

5/9/2026 at 6:14:45 PM

> ..., comptime that is more powerful than Zig

It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.

by tapirl

5/10/2026 at 1:10:46 PM

Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/. Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.

by melodyogonna

5/10/2026 at 10:50:05 PM

It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.

by tapirl

5/12/2026 at 2:50:08 PM

That's fair, I think I should have just said "comparable to Zig". The type'd ness is what I was thinking of, but having actually written some zig in the last few days to play with their Io model / see what passing around an allocator is like, Zig is pretty fantastic.

I still prefer the structure in Mojo, but boy do I miss if/switch as expressions.

by totalperspectiv

5/11/2026 at 10:41:00 AM

Well, it certainly allows you to encode invariants in a more precise manner.

by melodyogonna

5/8/2026 at 6:09:28 AM

As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did `len(x)` (turns out they'd opted for more specific byte-vs-codepoint representations, but the docs contradicted the actual implementation).

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.

by ainch

5/8/2026 at 8:20:08 AM

Mojo is cool but I just don't understand the python backwards compat thing. They're holding themselves back with that.

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.

by sureglymop

5/8/2026 at 5:00:55 PM

> All the flaws I can think of in Kotlin are due to the Java compatibility.

All the use of Kotlin in industry are due to Java compatibility. Else there would be ~0% marketshare of Kotlin.

by geodel

5/8/2026 at 7:36:45 PM

Mojo is NOT Python compatible (although they initially wanted it to be). So they got all downsides without the upsides.

by loglog

5/9/2026 at 12:28:40 AM

They claim you can easily mix them so there is some degree of compatibility.

by fiedzia

5/9/2026 at 3:47:51 AM

Every reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.

by Conscat

5/9/2026 at 7:32:13 AM

I don't recall they promised that. They promised it'll be a superset, but Mojo introduces new keyword. Mojo could support all Python features today exactly as they're supported in Python and you wouldn't still be able to copy Python code into Mojo and compile it

by melodyogonna

5/9/2026 at 5:48:16 AM

"All downsides"? What do you mean?

by boxed

5/8/2026 at 8:29:55 PM

There is unfortunately likely a lot of truth to this. I like Kotlin, but, anecdotally, I've only ever chosen it due to needing JVM

by jasonjmcghee

5/8/2026 at 5:32:40 PM

I'm pretty sure that they have decided that backwards-compat is not the best path for Mojo. Matter of fact, the following is the _last_ item on the roadmap on the home page:

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

by davidatbu

5/8/2026 at 12:05:00 PM

Same story with C and Objective-C, C and C++, JavaScript and TypeScript, Java and Scala, Java and Clojure,.....

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.

by pjmlp

5/9/2026 at 5:46:30 AM

> Mojo is cool but I just don't understand the python backwards compat thing. They're holding themselves back with that.

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

by boxed

5/8/2026 at 11:38:25 AM

They coulda made it Scala!

by tasuki

5/8/2026 at 11:28:38 PM

I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax.

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

by rao-v

5/8/2026 at 11:47:12 PM

Both ahead of time compilers and JIT compilers often perform autovectorization of tight loops. The problem is that lots of hot loops are not necessarily simple loops, and in particular a lot of source code is written in a way which uses sequential dependencies that can’t be modeled in SIMD code. Aside from undefined behavior in C/C++, most compilers will fail to autovectorize because doing so would very slightly change the behavior of your code in a very hard to understand way.

by oldmanhorton

5/9/2026 at 12:47:38 AM

Surely a high level language can own the contract of making sane choices of when to auto vectorize and when not to (or just inefficiently auto vectorize - that is fine too!)

by rao-v

5/9/2026 at 2:44:25 AM

That’s like saying “surely a high level language can solve the halting problem.”

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.

by throwup238

5/9/2026 at 4:32:35 AM

It’s really not! We’re not requiring the language to make optimal choices, just that it convert the same code to these different paradigms (and honestly you could just brute force run the 12 versions and choose the fastest one). Absolutely no theory barriers apply!

by rao-v

5/9/2026 at 9:14:38 AM

You should design it!

by bobbyswiss

5/9/2026 at 5:14:37 PM

Some kind soul pointed to Intel’s https://ispc.github.io/ which is basically this.

Missing some features but roughly has the idea. Keep faith with human ingenuity!

by rao-v

5/9/2026 at 4:32:32 AM

Still a bit early but I'm working on kiwi, a k-dialect that can lower to Apple MLX.

Currently supports CPU and GPU on macOS and CPU on linux.

https://kiwilang.com

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, …)

by tosh

5/9/2026 at 4:59:36 AM

Thanks for sharing this is neat!

I’ve yet to find a language that does SIMD / multithreading / GPU with minimal tweaks let along multiprocessing.

by rao-v

5/9/2026 at 5:38:35 AM

Intel Ispc is a compiler for a C superset language that targets CPU SIMD and GPUs.

by mappu

5/9/2026 at 6:11:22 AM

A beautiful find! It’s what 12+ years old at this point?

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?

by rao-v

5/8/2026 at 11:46:23 PM

If you're happy with NumPy's API, then surely JAX is exactly what you're looking for.

by JBits

5/9/2026 at 12:45:25 AM

JAX can’t do what Numba can do for example. I just want one way to write simple math-y code like you normally would and automagically convert to run on one of the above approaches.

That’s what compilers and high level languages are supposed to be for!

by rao-v

5/9/2026 at 1:31:25 PM

julia StaticCompiler.jl is the closest to doing this but its buggy, the error messages are terrible, theres no documentation and its ambiguous whether its still in development. but ive looked, nothing better exists.

by QuadmasterXLII

5/9/2026 at 1:20:43 AM

>I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax.

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:

https://github.com/Abdullahlab-n/VGC-for-arxiv

by teleforce

5/9/2026 at 8:07:14 AM

I don't think mojo depends on OpenBLAS or other BLAS implementation. I remember that they took a lot of pride in the early days how linalg primitives like matmul which was completely written in mojo was faster than MLK, openBLAS and other implementations.

by MohamedMabrouk

5/9/2026 at 4:30:13 AM

Delightful thank you! Would love to see a version of D that auto vectorizes to Vulkan or something

by rao-v

5/8/2026 at 7:46:05 AM

>As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs.

Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.

by coldtea

5/8/2026 at 5:13:29 PM

https://mojolang.org/docs/roadmap/#contributing-to-mojo

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

by flakiness

5/9/2026 at 6:02:15 AM

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

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.

by sidkshatriya

5/11/2026 at 3:07:02 PM

Golang was closed for the first 2 years of its development.

by melodyogonna

5/8/2026 at 8:11:13 PM

Indeed, this fall 100%

by chrislattner

5/9/2026 at 4:21:41 AM

Why didn't you just do this the sqlite way, and open source this, some time ago?

Release the source, but don't take code from external contributors. Take issues and discussion instead

by nextaccountic

5/8/2026 at 6:16:38 PM

open source does not mean open community. you can just throw tarballs over the wall

by bmandale

5/8/2026 at 5:14:26 PM

This is exactly how the open sourcing of Swift went so I imagine it will be the same.

by adamnemecek

5/8/2026 at 5:39:14 PM

> We're committed to open-sourcing all of Mojo

Translated from corporatese it means "it will never happen".

by otabdeveloper4

5/8/2026 at 6:38:33 PM

With Chris Lattners track record, there is little reason to doubt they actually will open source this.

by jlundberg

5/8/2026 at 6:52:46 PM

It’s not Chris Lattner who gets to make the call though. He has investors to the tune of $300 million, and making them happy is the reason it hasn’t been done yet. A lot of people, very reasonably, relieve it’s not possible to satisfy them and also the development community, and when when push comes to shove it’ll be the investors who win because they have the money. So it’s not Chris Lattner’s track record that makes people worried — it’s the track record of investors choosing control over openness, which is a pretty solid record.

by ModernMech

5/8/2026 at 7:11:27 PM

how is it in investors self interest to keep a programming language (some thing which no one makes money on today) closed? It also means that library authors can't reason about their code well enough because they don't know the language internals, this also hurts ecosystem growth. Their is no money to be made with a closed language that no body uses. probably modular investors know this.

by MohamedMabrouk

5/9/2026 at 7:33:49 AM

"We're committed" in official speech means "this thing has absolute lowest priority".

by otabdeveloper4

5/8/2026 at 7:57:50 AM

This is a bit ironic, given that people seem to have no problem using CUDA all over the place... Plus they promise to open source with the 1.0 release. We'll see...

by Certhas

5/8/2026 at 11:18:33 AM

I don’t see irony there. We’re locked into CUDA due to past decisions. And in new decisions we don’t want to repeat that mistake.

by _aavaa_

5/8/2026 at 4:54:32 PM

CUDA won because AMD and Intel made a mess out of OpenCL, and Khronos had no vision to support anything beyond C99 dialect until it was too late.

Doesn't matter if it was closed, when the alternatives were much worse.

by pjmlp

5/8/2026 at 8:10:41 PM

Plus NVIDIA clocked that it was also the developer library ecosystem and even now there just aren’t equivalents. The AMD rocFFT library wasn’t even complete compared to FFTW until very recently and cuFFT did that more than a decade ago

by physicsguy

5/8/2026 at 5:07:59 PM

SYCL is the de facto successor to OpenCL that supports higher level languages. So the vision was and is there.

by zozbot234

5/8/2026 at 5:11:25 PM

As mentioned, Khronos only changed their mind when it was too late.

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.

by pjmlp

5/8/2026 at 5:06:58 PM

I'm really not sure that's true.. I can't think of a single Python dev I've worked with who cared about opensource. All they cared about is the language being easy and free to use.

by ktm5j

5/8/2026 at 8:09:19 PM

The people that write the libraries care, why do you think Python is where we’re writing ML code and not MATLAB?

by physicsguy

5/8/2026 at 9:14:14 PM

Mojo is free, though. MATLAB costing money is a bigger issue than it being closed source. R was too late to the game and catered too much to professional math/stats/datascience people rather than programming generalists. Python (with native code interop) hit the sweet spot for breadth/accessibility to the market and capability.

by zbentley

5/8/2026 at 9:13:10 PM

Because MATLAB isn't free to use...

(Among other reasons, but that's easily the main one.)

by IshKebab

5/9/2026 at 8:15:18 AM

Most of the scientific libraries of note originate in academia where MATLAB is effectively free to users. The cross over to Python was well under way by ~2014

by physicsguy

5/8/2026 at 8:36:37 AM

I think that plan is to open source the compiler with 1.0 which is expected to be this summer. so in ~3-4 months time.

by MohamedMabrouk

5/8/2026 at 6:08:42 PM

It does almost seem like they're trying to recreate the Nim programming language in this regard.

by digdugdirk

5/8/2026 at 7:26:12 AM

> We have committed to open-sourcing Mojo in Fall 2026.

https://docs.modular.com/mojo/faq/#will-mojo-be-open-sourced

by armchairhacker

5/9/2026 at 3:29:12 AM

Nice. I'd love to see the source of an actual state of the art MLIR program.

by dismalaf

5/8/2026 at 6:44:03 PM

Good catch in the noise. Thanks!

by jlundberg

5/8/2026 at 6:25:46 AM

Sadly for them, Nvidia didn't stay still in the meantime and created the next generation of CUDA, CuTile for Python and soon for C++, through CUDA Tile IR (using a similar compiler stack based on MLIR).

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.

by fibonacci112358

5/8/2026 at 9:01:03 AM

And for not staying behind, Intel and AMD are doing similar efforts, and then we have the whole CPython JIT finally happening after so many attempts.

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.

by pjmlp

5/8/2026 at 7:03:43 PM

The CPython JIT has barely had any impact on its performance. CPython is always going to be dog slow.

by IshKebab

5/9/2026 at 6:20:22 AM

Of course, it is still on baby steps and has to be explicitly enabled when installing the right build.

It only has to be good enough, to keep the ecosystem going, and the porting cost not be worthwhile, when Mojo finally reaches parity.

by pjmlp

5/8/2026 at 7:26:40 AM

People keep mistaking Mojo as good syntax for writing GPU code, and so imagine Nvidia's Python frameworks already do that. But... would CuTile work on AMD GPUs and Apple Silicon? Whatever Nvidia does will still have vendor lock-in.

by melodyogonna

5/8/2026 at 9:03:23 AM

Indeed, but Intel and AMD are also upping their Python JIT game, and in the end Mojo code isn't portable anyway.

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.

by pjmlp

5/8/2026 at 12:16:59 PM

It is portable in that you can write code to target multiple platforms in the same codebase. Mojo has powerful compile-time metaprogramming that allows you to tell the compiler how to specialise using a compile-time conditional, e.g. https://github.com/modular/modular/blob/9b9fc007378f16148cfa...

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.

by melodyogonna

5/8/2026 at 12:20:31 PM

Yes you do, you get PyTorch or whatever else, built on top of those vendor-specific libraries.

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.

by pjmlp

5/8/2026 at 3:53:30 PM

Pytorch is built on an amalgamation of these different frameworks, not on one of them used to target different vendors.

by melodyogonna

5/8/2026 at 4:48:55 PM

The point still stands as middleware.

by pjmlp

5/8/2026 at 5:18:31 PM

Have you ever wondered how much work would have been saved by the Pytorch team if they could have used just Cuda for all the platforms they support? If they didn't have to write compatibility abstractions or layers, and instead just focused on the problem of training neural networks? What if all the primitives they used from Cuda and cuDNN worked just as well on AMD GPUs, Apple GPUs, and probably Google's TPUs as they did on Nvidia GPUs?

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.

by melodyogonna

5/9/2026 at 6:24:14 AM

Yes, because one of my hobbies was graphics programming for a long time, and I keep observing all the time how FOSS folks misunderstand the games industry, what gets talked at GDC and IGDA events, isn't one API to rule them all.

by pjmlp

5/9/2026 at 2:26:34 AM

> What if all the primitives they used from Cuda and cuDNN worked just as well on AMD GPUs, Apple GPUs, and probably Google's TPUs as they did on Nvidia GPUs?

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.

by bigyabai

5/9/2026 at 7:17:05 AM

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

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.

by melodyogonna

5/9/2026 at 1:42:32 PM

> Ah, it seems impossible to you. These are very different hardwares...

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?

by bigyabai

5/10/2026 at 11:35:16 AM

> In effect, they are completely different hardware. The only thing any of them have in common is rasterization primitives

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

by melodyogonna

5/9/2026 at 3:54:13 AM

My understanding from speaking with a few Tile IR devs on dates is that its primary motivation was providing better portability for programming tensor cores than PTX offers. Nobody ever told me they saw it as a response to anything other than customer feedback.

by Conscat

5/8/2026 at 6:34:46 AM

Interesting, how big impact is CuTile?

by brcmthrowaway

5/8/2026 at 5:57:12 AM

When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.

by modeless

5/8/2026 at 6:10:53 AM

In their original pitch that was definitely part of it: take Python code, add type hints, get a big speedup. As they've built it out it seems to have diverged.

by ainch

5/8/2026 at 6:52:35 PM

It was always going to be a long-term thing, if it were even possible. You can't make a compiler that can compile Python into efficient machine code in just a year (which was how long Mojo had been in development when it was announced).

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

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

by melodyogonna

5/8/2026 at 11:29:25 PM

[dead]

by infraredshift

5/8/2026 at 6:53:41 AM

They also advertised a 36,000x speedup over equivalent Python if I remember correctly, without at any point clarifying that this could only be true in extreme edge cases. Feels more like a pump-dump cryptography scheme than an honest attempt to improve the Python ecosystem.

by dtj1123

5/8/2026 at 7:18:06 AM

Well... the article made self deprecating fun of the click bait title, showed the code every step of the way, and actually did achieve the claim (albeit with wall clock time, not CPU/GPU time).

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

by boxed

5/8/2026 at 8:37:42 PM

Watch Chris Lattner's interview with Lex Fridman. He talks about mojo as a 36,000x speedup over Python without any indication that you need to think about vectorization to achieve it.

by dtj1123

5/9/2026 at 5:25:53 AM

I'm looking at this transcript and I'm getting a different picture than what you describe https://podscripts.co/podcasts/lex-fridman-podcast/381-chris... . Yea, he doesn't specifically say vectorization and multi-threading or whatever but he also doesn't say you don't need some skill to get to huge speedups.

by boxed

5/9/2026 at 8:02:00 AM

Does he say that you _do_ need skill to get huge speedups?

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

by dtj1123

5/10/2026 at 11:31:03 AM

Speed of light is actually the limiting factor in modern chips and has been for a long time. It's one of the major reasons why process shrinks are jumps in performance: literally the speed of signals in the CPU shrinks.

by boxed

5/10/2026 at 5:51:25 PM

Electrons moving through silicon do not move at the speed of light.

by dtj1123

5/11/2026 at 6:26:23 AM

The speed of electricity is not the speed of electrons first of all. Secondly, the difference here is not very big.

by boxed

5/11/2026 at 9:55:35 AM

Indeed, an electromagnetic pulse travelling through a copper wire will propagate at at something like 85% of the speed of light.

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?

by dtj1123

5/11/2026 at 1:08:38 PM

I re-read that passage where he mentions the speed of light. Clearly he's trying to explain that if you start from the bottom of what the hardware can do and try to get that all to the programmers hands then you have something that is close to the theoretical speed. This is different from trying to go down the stack from python down and seeing where you can optimize.

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.

by boxed

5/12/2026 at 5:47:28 AM

From my perspective, you're reaching for extremely unlikely explanations of his underlying meaning in order to avoid having to consider the possibility that he may have been dishonest, whilst you've been gullible.

However, I'll happily acknowledge that I'm fallible and that perhaps this argument is all a product of my neuroses.

by dtj1123

5/8/2026 at 5:10:00 PM

The modern way to advertise: lie a lot.

by jdiaz97

5/8/2026 at 8:16:57 PM

Crypto*

by dtj1123

5/8/2026 at 7:36:58 AM

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

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

by Certhas

5/8/2026 at 8:57:57 AM

So basically Chapel, which is actually being used in HPC.

by pjmlp

5/8/2026 at 12:38:21 PM

I don't know Chapel in detail, I was more thinking Hylo. I don't think Chapel has a clear value/reference semantics or ownership/lifetime story? Am I wrong here?

The Mojo docs include two sections dedicated to these topics:

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

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

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

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

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

by Certhas

5/8/2026 at 1:21:59 PM

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

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

by pjmlp

5/8/2026 at 1:30:17 PM

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

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

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

by Certhas

5/8/2026 at 2:21:39 PM

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

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

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

See "Projects Powered by Chapel".

by pjmlp

5/8/2026 at 2:42:29 PM

So? What point are you making? A different language with different design philosophy, has success in a different niche than Mojo is targeting?

by Certhas

5/8/2026 at 3:22:58 PM

One is used in production already by key laboratories in HPC research, the other wants to be and is far away from being 1.0.

Chapel current version is 2.8.0.

by pjmlp

5/8/2026 at 4:02:35 PM

I don't understand this framing, so? Cpp, Julia are more widely adopted, used in HPC. it does not mean that people shouldn't start, learn new languages.

by MohamedMabrouk

5/8/2026 at 4:49:50 PM

In the LLM age, maybe the focus should be elsewhere instead of syntax.

by pjmlp

5/8/2026 at 5:42:01 PM

is that so? People are still reading their code to understand it and ask (or make modifications). even in the (LLM age) language design, readability is still as relevant as before.

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

by MohamedMabrouk

5/9/2026 at 7:27:52 AM

I don't think Mojo is targeting HPC at all.

by Certhas

5/8/2026 at 4:00:57 PM

Mojo isn't that far away from 1.0. Some point this year is the target

by melodyogonna

5/8/2026 at 10:57:45 PM

Is it? Spack has only one package that depends on chapel.

by zzzoom

5/8/2026 at 6:35:51 AM

That was what was originaly advertised, they wanted to be what Kotlin is to Java but for Python. They quickly turned tails on this.

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

by mastermage

5/8/2026 at 5:36:18 PM

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

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

by fwip

5/8/2026 at 8:16:39 PM

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

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

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

Note: I work at Modular

by simplyvibecode

5/8/2026 at 6:49:57 AM

From the site:

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

by victorio

5/8/2026 at 7:35:00 AM

> they intended to make it compatible with existing Python code

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

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

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

by pansa2

5/8/2026 at 8:18:36 PM

[dead]

by simplyvibecode

5/8/2026 at 6:17:11 AM

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

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

by samuell

5/8/2026 at 6:51:58 AM

isn't that achieved by Codon?

by kjsingh

5/8/2026 at 6:05:36 AM

Really the only thing good about Python is its ecosystem.

by haskman

5/8/2026 at 7:47:52 AM

Nah, it's also a very fine language for getting an idea down quickly.

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

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

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

by coldtea

5/9/2026 at 7:33:27 PM

Look at my statement in context of Mojo. Why would someone use this language if all they want is to "get an idea down quickly"? They would just use Python instead

by haskman

5/8/2026 at 6:38:12 AM

but that ecosystem is realy good.

by mastermage

5/8/2026 at 4:05:22 PM

That it is

by haskman

5/8/2026 at 5:08:51 PM

They just lie a lot, they make fake blogs with fake benchmarks and then they delete them

by jdiaz97

5/8/2026 at 6:57:51 AM

Advertising prominently with "AI native" seems necessary today, at least for some folks. To me, that's kind of off-putting, since it doesn't really say anything.

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.

by smartmic

5/8/2026 at 7:05:07 AM

It's been really interesting to see all the desperation on hero pages for all these products and services ever since AI came into prominence. I think the funniest for me was opening IBM DB2 product page and seeing it labeled as 'AI database'. Hysterical.

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

by jpnc

5/8/2026 at 7:15:35 AM

I don’t really consider myself an “AI enthusiasts”, but I do use it.

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.

by chillfox

5/8/2026 at 7:42:29 AM

So just like for humans...

by phyrog

5/8/2026 at 7:06:49 AM

I don't know what they meant by it, and I share your opinion that "AI native" is somewhat meaningless for a programming language like this.

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.

by Reubend

5/8/2026 at 7:13:42 AM

I've recently used Claude to write quite a bit of mojo (https://github.com/boxed/TurboKod) and I can quite confidently say that Claude will write deprecated mojo syntax a lot, but the compiler tells it and it fixes it pretty fast too. The only reason I notice is that I look at Claude while it's working and I see the compilation warnings (and sometimes Claude is lazy and doesn't compile so I have to see it).

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.

by boxed

5/8/2026 at 9:14:53 PM

Have you used the Mojo syntax skill with modern LLMs? It is updated to latest Mojo and I can say nearly 100% of my code is written by AI, with good quality, and the compiler helping it too.

by msaelices

5/11/2026 at 6:26:45 AM

Nope. Claude just gets along quite well out of the box.

by boxed

5/8/2026 at 7:30:58 PM

Current LLMs have been trained on extensive libraries of past code. Therefore, LLMs will for the foreseeable future work better for established languages than new ones. Especially languages with a lot of open source code available, like Python. That's a big problem for incumbents without any existing code to train LLMs on.

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.

by Derbasti

5/8/2026 at 2:48:17 PM

It’s the new “…on the blockchain”.

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.

by kstrauser

5/8/2026 at 9:54:59 PM

>It’s the new “…on the blockchain”.

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.

by fuzztester

5/8/2026 at 9:58:03 PM

iow, it's the equivalent of your common or garden variety of teenager proclaiming that this new thing they just found is gr8, all else is shite, only to jump on the next bandwagon next week, month, or more rarely, year.

by fuzztester

5/9/2026 at 5:04:13 AM

its what alan kay talks about when he says programming in general isnt a serious discipline and is instead a pop-culture...

  > only to jump on the next bandwagon next week, month
good for marketing as well; there are a no shortage of juniors who are mesmerized by the new shiny

by andrekandre

5/8/2026 at 7:04:54 AM

Because a coding agent (when instructed well) will try to make a piece of code work in a loop. Static typing and compilation help in the process (no more undefined variables discovered at runtime for instance). But that’s not bullet proof at all as most of us know

by rmnclmnt

5/8/2026 at 8:56:01 AM

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.

If Mojo will still arrive on time to gain wider adoption remains to be seen.

by pjmlp

5/8/2026 at 2:18:05 PM

> Python cuTile JIT compiler allows writing CUDA kernels in straight Python.

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.

by adev_

5/8/2026 at 5:11:04 PM

> Mojo tries to start from a clean sheet instead of hacking the existing crap.

Their whole original pitch was to be a superset of Python btw.

by jdiaz97

5/8/2026 at 7:20:36 PM

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

by adev_

5/8/2026 at 3:01:38 PM

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

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.

by kstrauser

5/8/2026 at 9:11:07 PM

I wouldn't call it "exceptionally nice". Decentish if you use uv & strict Pyright... sure.

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

by IshKebab

5/9/2026 at 8:44:12 AM

> I wouldn't call it "exceptionally nice"

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)

by jz391

5/8/2026 at 7:46:24 PM

> on top of a well designed language constructed over past language design experience

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.

by loglog

5/8/2026 at 2:22:25 PM

I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves, but anyone else that does the same, it is no longer the same language.

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.

by pjmlp

5/8/2026 at 3:01:06 PM

> I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves

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.

by adev_

5/8/2026 at 4:57:21 PM

I would argue Chapel or Futhark could be such languages, but they aren't cool.

by pjmlp

5/8/2026 at 7:18:17 PM

Chapel maybe, but it is too low level to attract a large public outside of the HPC community.

by adev_

5/9/2026 at 12:28:36 AM

Mojo looks neat but I'm pretty satisfied with Julia at this point for high performance numerical computing across CPU, GPU, etc. I can't help but feel this niche is already mostly solved beyond having Python like syntax. Even Python has things like Numba and Triton that are effective for less complicated / more self contained type problems.

by csvance

5/8/2026 at 5:49:55 AM

I remember reading about this 4 years ago as the new Chris Lattner project and was super excited, though a little skeptical.

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.

by dllu

5/8/2026 at 6:07:05 AM

Not to mention that C++ basically can't be made to be safe. But Rust is probably fine.

by boxed

5/8/2026 at 5:00:42 PM

In theory that is the idea behind profiles, in practice it remains to be seen what will they deliver until C++29, and if matters by then.

Microsoft is invested into using AI for C++ code review, for example.

by pjmlp

5/8/2026 at 7:11:12 AM

I’m relatively new to programming but I wish they had used a functional language syntax rather than an object oriented one as the basis for mojo.

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.

by Timot05

5/8/2026 at 7:43:59 AM

The vast majority of real world ML code today is written in languages like Python and C++. Relatively few people outside of academia and online forums are functional language enthusiasts. The industry is also looking like most actual coding is going to be done by LLMs going forward, so it makes little sense to design new languages with a niche potential user base since LLMs need a ton of training data. I’m think that was a factor in deciding to base mojo on Python along with the other reasons they state.

by Revanche1367

5/8/2026 at 8:54:59 AM

agree with all of this. Though i'd say: since the language is mostly read by humans rather than written, in my opinion, it makes even more sense to have a language syntax that actually matches intent. In the case of Machine Learning, it's mostly connecting functions together and acting on them, which matches functional syntax. LLMs are also already very effective at writing ML-inspired syntax (like ocaml or f#) as they have plenty of data to train on, making llms effective from day one if a similar syntax was chosen.

by Timot05

5/8/2026 at 7:14:46 AM

I'm in the same boat, this would've been in the family of the first language that neural nets and AI were created with back decades ago, Lisp. Coming from the awesome project of Swift, which to their credit, was a massive undertaking to convince Apple execs, I was still hoping for a functional language approach like Haskell with the practicality of Clojure.

by arikrahman

5/8/2026 at 5:33:24 AM

Still phase one, doesn't do native Windows.

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.

by pjmlp

5/8/2026 at 6:36:47 AM

I do wonder if Mojo was a great idea just a little too late to the party. Porting ‘prototypes’ from Python to lower level languages is fairly trivial now with LLMs.

by chrismsimpson

5/8/2026 at 9:18:22 PM

Modern LLMs are perfectly capable to learn the syntax of a new language on the fly and write great Code. E.g. there is an official Mojo syntax skill you can use and works well

by msaelices

5/8/2026 at 5:44:40 PM

I know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)

by taylorallred

5/8/2026 at 8:15:20 PM

Me too! I've been using it for bioinformatics related work, and it is absolutely fantastic. I can't wait for it to hit fully open source status so it can be easily recommended.

by totalperspectiv

5/8/2026 at 8:19:15 PM

Full open source Mojo 1.0 coming this fall!

by simplyvibecode

5/8/2026 at 11:01:57 PM

I work in bioimaging. What kind of bioinformatics are you doing that requires mojo level power?

by momojo

5/9/2026 at 12:04:27 AM

"requires" is a strong word, but I implemented an alignment kernel that can do alignments on the GPU.

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

by totalperspectiv

5/9/2026 at 6:08:54 AM

I might have to look into mojo.

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)

by momojo

5/8/2026 at 6:08:40 AM

I was excited when Mojo launched and thought it might grow big quick. I don't see much traction. The pitch is compelling. What could be the issue?

by insumanth

5/8/2026 at 6:26:42 AM

I have no time for or interest in proprietary compilers. The standard library is Apache 2, but the license link on their home page is to a long terms of service thing. I’d like to be wrong because it looks interesting. Until then, this doesn’t exist in my world.

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.

by kstrauser

5/8/2026 at 6:24:45 AM

As someone who would have strong reasons to invest time in Modular (simple high performant language for implementing bioinformatics scripts), I would say primarily the worry that development might be too tied to Modular, the startup behind it, which eventually might pivot into other priorities.

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.

by samuell

5/8/2026 at 9:08:31 AM

- Doesn't support Windows, which is what many companies give their employees, outside Silicon Valey like culture

- 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

by pjmlp

5/8/2026 at 6:25:11 AM

Mojo is still NOT open source (the standard library is but not the compiler). Open source is table stakes for a modern programming language.

by williamstein

5/8/2026 at 11:20:13 PM

It's a language that wanted to make money from the start.

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.

by xiphias2

5/8/2026 at 6:21:21 AM

When it was announced it was not generally available for everyone to try out. There was a waitlist phase.

by tweakimp

5/9/2026 at 12:33:37 AM

I've been keeping my eye on mojo. Honestly though the thing I least like about Python is it's syntax.

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.

by bobajeff

5/9/2026 at 2:46:16 AM

> the thing I least like about Python is it's syntax.

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?

by archargelod

5/9/2026 at 12:50:50 AM

I’m a big fan of Mojo’s design. It isn’t comparable to Julia since it has deterministic memory management.

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.

by Recurecur

5/8/2026 at 7:57:53 PM

Python is basically the master glue language at this point.

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.

by coppsilgold

5/8/2026 at 9:51:22 PM

Cython is a no-brainer really. You write the same language with immense speedup (matching what the "other languages" can achieve at much less effort).

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.

by sirfz

5/8/2026 at 8:14:29 PM

Mojo aims to be this (other language) arguably with easier programming model that rust, familiar syntax to python devs, and a modern design in general. Its stated goal now, is the easiest way to extend python. it provides the same interface for zero-hassle import of .mojo files

by MohamedMabrouk

5/8/2026 at 8:08:26 PM

Cython and PyBind and Nanobind are good for wrapping an existing library written in C++ and crafting an interface that doesn’t feel like it’s a C++ one. They were a big step from ctypes and SWIG

by physicsguy

5/9/2026 at 6:28:34 AM

Plus, even if it has a Perl like feeling to it, C++26 reflection will make this even easier.

Already available on GCC 16.

by pjmlp

5/9/2026 at 1:10:46 AM

> If more than a few percent of execution time is spent in Python you are probably doing it wrong.

Every program that starts with 1% of Python writes more Python and gets to 20,40, 60 and than 99% of it.

by fiedzia

5/8/2026 at 3:59:00 PM

>As a compiled, statically-typed language, it's also ideal for agentic programming.

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.

by DeathArrow

5/8/2026 at 6:02:09 AM

Right now majority of beginners start programming with a high-level language, say Python or JavaScript - then for more advanced system-level tasks pickup C/C++/Rust/Zig etc.

If Mojo succeeds, it could be the one language spanning across those levels, while simplifying heterogeneous hardware programming.

by 0xpgm

5/8/2026 at 6:23:44 AM

I am actually on a lookout for a low level language which compiles to web assembly to write a (relatively small) supervised learning model which I plan to be good enough for 5 year old phone CPUs. I have a working prototype in Julia and was planning on (eventually) rewrite it in Rust mostly for the web assembly target. I come from a high level language background so the thought of rewriting in rust is a little daunting. So I was excited to learn about Mojo and find out if they had a WebAssembly target in their compiler.

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.

by runarberg

5/8/2026 at 6:42:26 AM

I’ve written Python for the past 25 years or so. I dig it. But I don’t think I’ve started a new Python project since starting to experiment with Rust. A lot (not all!, but a lot) of Rust patterns look a lot like Python if you squint at it just right. I also think that writing lots of Rust has made me better at writing Python. The things Rust won’t let you get away with are things you shouldn’t be doing almost anywhere else.

Go on, give it a shot. It stops being intimidating soon! And remember that the uv we all love was heavily influenced by Cargo.

by kstrauser

5/8/2026 at 7:09:20 AM

I actually have written Rust, but it has been a minute. I think my last project (a backend for a massive online multiplayer theremin jam session [site no longer up; but HN discussion still exists: https://news.ycombinator.com/item?id=10875211] 10 years ago).

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.

by runarberg

5/8/2026 at 9:11:51 AM

I can't go get coffee so many times per day, there are better compiled languages to chose from, while offering Python like ergonomics.

by pjmlp

5/8/2026 at 1:57:11 PM

I can only go get coffee waiting for my Python test suite to finish so many times per day. I write Rust because the strict type system accelerates the iteration speed for producing correct code more than any other language in its class.

by kibwen

5/8/2026 at 2:17:43 PM

Which is why the solution is to pick neither, rather something with Python like productivity and a mix of JIT/AOT tooling.

Some alternatives are as old as 1958.

by pjmlp

5/8/2026 at 6:59:41 AM

If you’re searching for a language that has the same strong memory safety than rust but is a bit easier to write, you should give Swift a go.

by frizlab

5/8/2026 at 3:10:10 PM

Good call. It’s not the first language I think of for most things but there’s no great reason why not to. I probably reach for Rust first because I’m more familiar with it and the projects I want to work on were already written in it.

by kstrauser

5/8/2026 at 7:55:30 AM

Mojo has been suffering in their communication from targeting VCs rather than users. They never actually had a clear "Mojo extends Python" MVP or even strategy to get to an MVP anytime soon. And the language started developing before AI Agents were a thing and has more to do with building around state of the art LLVM tooling than AI Agents. But I guess "easier lifetime semantics than Rust and native access to MLIR intrinsics" doesn't raise money...

by Certhas

5/8/2026 at 10:40:50 PM

Might want to take a look at WasmTarget.jl it’s rather new and experimental but could be what you’re looking for!

by FacelessJim

5/9/2026 at 12:27:30 AM

Too much vibe code for my taste.

by runarberg

5/8/2026 at 9:53:59 AM

Is there any project that showcases Mojo for running neural network models on the GPU - like ideally something like llama.cpp that could run one or more existing models to showcase the readability and performance?

by tveita

5/9/2026 at 7:53:58 AM

The changelog looks reasonable, seems like the language is moving in the right direction. I'm excited to try it out once it's open sourced. The dependency on glibc is an unfortunate limitation as it means you can't install Mojo on musl-based systems.

[1] https://mojolang.org/releases/v1.0.0b1/

by andriamanitra

5/8/2026 at 8:39:37 AM

Doesn't anyone here have _one_ kind word to say about its features? Every one seems to be starting with "on the other hand".

by sriram_malhar

5/8/2026 at 9:05:26 AM

Many of us were already around during Swift for Tensorflow.

by pjmlp

5/9/2026 at 3:29:58 AM

Congrats to Chris Lattner and crew! Seems like a neat project. I listened to him talk about Mojo on some podcast a while back and was really impressed. Swift was a runaway success, and I hope he can pull it off again with Mojo! :)

by jadar

5/9/2026 at 6:47:49 AM

Does anyone know if Mojo is more suitable for functional programming that Python?

Things like optimizing away object allocations, pure function inlining, tail call optimization?

by rienbdj

5/8/2026 at 6:17:59 AM

Am I old or remembering this wrong... didn't Zuck write the first iteration of Facebook in PHP, and then spend millions to hire people to write something that converted the code to C++?

by noduerme

5/8/2026 at 6:08:20 AM

Very bold of them expecting people to use a language with a closed source compiler in the 2020s.

by logicchains

5/8/2026 at 6:25:15 AM

If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/

by evertheylen

5/8/2026 at 7:21:32 AM

I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me.

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.

by runarberg

5/8/2026 at 9:12:16 PM

> mostly for the web assembly target

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

by ssivark

5/8/2026 at 9:53:49 PM

I saw that, but then I saw this:

> Both repos were built iteratively with LLM coding agents

I think I would rather just use Rust.

by runarberg

5/8/2026 at 9:46:12 PM

WOW. Thanks for the comment I don't need to waste my time. So many choices for programming languages why would I go with something that isn't fully open source?

by redlewel

5/8/2026 at 6:10:47 AM

from what I understand the goal for now is not to get the people to use it, but for enthusiasts to try it

by walterlw

5/8/2026 at 6:28:25 AM

What enthusiast worth getting feedback from is going to tinker with a locked up language?

by kstrauser

5/8/2026 at 7:28:33 AM

You'd be surprised. Anyway, the compiler will be opened with 1.0 release, that's why reaching beta is exciting.

by melodyogonna

5/8/2026 at 6:12:27 AM

They've said they'll open source the compiler alongside the 1.0 release.

by ainch

5/8/2026 at 6:55:39 PM

CUDA is closed source (and will never be open sourced) and everyone is fine with it.

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.

by rvz

5/8/2026 at 7:41:40 PM

CUDA is not a programming language. It's a package with adapters for lots of languages. IMO, it's not relevant here at all. Sure proprietary packages exist for just about every language, but most modern languages are open source. You can use them, distribute them, patch them, or whatever else.

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.

by kstrauser

5/8/2026 at 8:18:12 PM

It's not just CUDA and it's runtime. I am talking about its compiler, nvcc and that is closed source. [0]

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.

[0] https://en.wikipedia.org/wiki/Nvidia_CUDA_Compiler

by rvz

5/8/2026 at 6:21:52 AM

>No more choosing between productivity and performance - Mojo gives you both.

That's a very big claim.

by DeathArrow

5/8/2026 at 6:45:35 AM

Does it have the indentation thing? That would be a no go for a lot of people

by thefounder

5/8/2026 at 6:50:03 AM

Only incredibly inexperienced people think indentation in python is a problem.

by IceDane

5/8/2026 at 7:08:24 AM

I have tons of experience with python, possibly more actual work experience than any other language, and I do think the indentation is a bit of a problem. Obviously not a huge one, but still something I wished they had done differently. Because I like to have a robust format-on-save wired into my editor, and you just cannot quite have that when indentation is meaningful.

by vga1

5/8/2026 at 8:09:47 AM

Use black as format on save and you will never have a problem with that. https://github.com/psf/black

by tweakimp

5/8/2026 at 11:25:47 AM

Sure, black's pretty good and definitely better than nothing.

Just wanted to provide an easy counterpoint to the logical fallacy by IceDane.

by vga1

5/9/2026 at 1:06:39 AM

I must admit that I’ve tried python in my early days and indentation was the main reason why I just didn’t pursue the language further. It felt just brittle and hard to read. Of course if I had be forced I would have probably managed to master it but I had the freedom to use whatever I wanted as programming language and python was just not an attractive option.(despite being seduced by its “zen” and all that. Felt like form over function design.

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.

by thefounder

5/8/2026 at 9:43:53 PM

Yes, I remember having a problem with python indentation. For some reason tabs and spaces were causing my code to fail to run!! This was when I was first learning programming and didn't know anything. Once I understood the syntax of the language it hasn't been a problem ever since. Its like being upset that your yaml doesn't work because you have mixed spaces and tabs.

by redlewel

5/8/2026 at 10:56:46 PM

Seems just as valid as any of the other syntactical nitpicks of other languages, except it touches every line of code you write and it’s unavoidable.

by nothinkjustai

5/8/2026 at 11:42:24 AM

Yes, indeed, indentation is one of the very few things in Python which aren't problematic!

by tasuki

5/9/2026 at 5:13:56 AM

How the fuck could you possibly even possibly begin to validate such a claim. Lol. Asshole.

by Petersipoi

5/12/2026 at 3:51:20 AM

Is what?

by VerifiedReports

5/8/2026 at 8:34:27 PM

> AI native

What’s that supposed to mean?

by AbuAssar

5/8/2026 at 9:14:25 PM

My guess is that they expose first party skills and maybe other agent friendly docs? Not positive though.

by jjice