Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- They made a big mistake by not open sourcing before, doubt they'll ever gain traction now.by Heidaradar
- Their goal was to get bought. Now it doesn’t matter whether they get traction, they already made a billion dollars.by ModernMech
- I'm pretty excited about mojo and look forward to it continuing into the phase of supporting systems programming. I have been using rust a lot lately for things I had used python for (that were not computation). I really like rust for static typing and functional programming patterns... but not for numerics. Hopefully mojo can become a serious staticly typed alternative to python.
When mojo 1.0 was announced, I looked into porting my current rust project (a very opinionated type-driven DICOM library/anonymizer that has a spec implemented in haskell) and it wasn't ready for that sort of work yet vs continuing with rust. Which is fine! The numerics side looks great. I'm glad they have reached 1.0 and open sourced.
by fluidcruft - If you like C++, you're going to like Mojo (if you're looking for alternatives). Some of the semantics and designs are inspired by C++, but wrapped in a Python-like skin. The way to think about Mojo, when compared to Rust, is that it was designed by expert C++ programmers as what they imagine a good C++ will look like. When I see Rust, I see designers who loved the functional programming paradigm and wanted to make a lot of the concept mainstream. This is why some of the semantics can seem awkward if you're coming from a procedural languageby melodyogonna
- > it was designed by expert C++ programmers as what they imagine a good C++ will look like
This also describes Rust. The mistake here is thinking that being an expert C++ programmer means that you can't also be an expert OCaml programmer.
by kibwen - > expert C++ programmers as what they imagine a good C++ will look like
Mojo looks nice but with coding agents the landscape has shifted at least in my view. There is no need for DSLs and abstractions that reduce human cognitive load. So, I still struggle with the usecase for Mojo. If you want close to metal performance, code in something that touches metal (c,c++), and doesnt abstract you away from it or require unsafe primitives. As a programmer who cares for performance, you want the least separation between your tools and the hw in the sense that you can visualize precisely what the hw is doing with no abstractions to hide it.
by bwfan123 - Can you explain this in more detail? I'm not really familiar with Mojo but I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s.
- This isn't quite accurate; Mojo uses the same memory safety approach as Rust. It has some mutable aliasing, but only intra-function, so in practice programs will be pretty much Rust-shaped.by verdagon
- This is nice, but the long time it took them to open source I think burnt a lot of the initial traction. I do like the idea & I'll see whether I can make use of itby acheong08
- I'd bet 99% of people who will ever hear about or write in Mojo haven't heard about it for the first time yet.by ModernMech
- I think this submission should be merged with this much older one since they link to the same post: https://news.ycombinator.com/item?id=49348079by melodyogonna
- The actual blog post on open-sourcing: https://www.modular.com/blog/mojo-open-source
I remember being really interested a few years ago when it was billed as a superset of Python. I know they pivoted away from that, but I might play with it now that the compiler is also open source.
by mihaelm - I am much more interested in it now that it is not a subset of Python. That felt like something which would hold it back and seems like they agreed.by jeltz
- I had been holding off on testing out mojo till it was open sourced, and started picking it up this week.
So far I've been enjoying the language (pythonic, comptime, tile support) and plan to spend time using it to work with gpus to learn more, the puzzles are also pretty cool.
by knlb - This is how I imagined you seeing Qualcomm :Dby chanux
- Maybe I'm a party pooper, but given Qualcomm history, open sourcing just after acquisition feels like they don't care about it and they're going to let it die while they cut Modular in pieces and extract all the juice possible of their cloud offering.by tecleandor
- Open sourcing was on Mojo's roadmap long before Qualcomm was in the picture.by fluidcruft
- Summarized here: https://www.phoronix.com/news/Modular-Mojo-Open-Source
This is by Chris Lattner, known for LLVM and Swift.
by flaburgan - Also Swift for Tensorflow, lets not ignore that effort as well.by pjmlp
- Does this project have any meaningful traction? Seemed like a cool idea, but I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...by aeonflux
- You can read a lot more about it here: https://mojolang.org/docs/vision/by jdnier
- The "problem" it might solve for me, personally, is having a systems-level language that matches my personal style a bit better than Rust or other more modern systems level languages.
I know they're putting a lot of weight on GPU programming, which is fine and probably solves problems, but this is the part that would motivate me personally.
by ubercore - the main value proposition of mojo is being a (modern language for heterogenous compute). when writing code for the CPU, it is a nice language. it looks a bit like python, have arguably one of the best SIMD abstraction, a bit easier than Rust .. etc. but in my opinion, that does not justify deep investment in learning the language vs rust or zig. what sets Mojo apart is that it was designed from the grounds up to natively supprt other types of hardware (starting with GPUs). I have been in the mojo community from the beginning and almost every other project presentation starts with (I wanted to do XYZ in my domain and I could match or get close to Rust, C++ perf but then I wanted to see if I can make work on the GPU and it was much easier than expected and now I can solve my problem 10x faster). this is massive advantage that is underutilized outside of the AI/LLM and few other niches. running natively and being portable to NVIDIA/AMD/Apple GPUs means that you can transform any arbitrary workload you have in mind to the GPU and you won't need to worry about the separate CUDA/ROCm/Metal stacks, slightly different programming models, building headaches. you will be using the same language and the same compiler for CPUs and GPUs (all of them). or you won't need to coerce your problem in the shape of Triton to make it portable. If you have a problem in mind and don't like what you see? write your own GPU abstractions, containers, data moving and pipelining logic, work partitioning .. etc. this is extremely powerful and it sets Mojo apart from any other mainstream systems language that I have seen. that's why bigger mojo projects (even pre 1.0) like NuMojo and Marrow are all dabbling with GPU support even before the first stable release.
and now with support for TPUs and Trainium chips it is becoming even better. some problems will work better on some architectures and you will be able to split your problem to the best hardware doing some work on the CPU and some work on the accelerator(s) of choice, all with a modern language and one compiler with good tooling. that seems to be a good enough value proposition for me.
- I think the compiler not being open-source hurt with getting people to check it out. Today, people are accustomed to most of it regarding PL development being out in the open, and Mojo was an outlier here.by mihaelm
- > But I wasn't even sure what problem does it solves. Looks like its completely missing from the regular discussion / news outlets. Every 1-2 years some barely visible post/article reminds me it even exists...
At this point "developers" these days sound a lot more like consumers than those who actually do research on a tool that solves a problem. Ocaml is barely mentioned in the news and rarely HNers here use that language, but it is Jane Street that maintains and uses it.
Judging by hype isn't a great way of evaluating a language. I am not going to check the entire Nvidia stack, from CUDA, to CUTLASS to cuDNN and even on PyTorch's side just to solve a runtime error that could have originated from either place when Mojo solves all of that.
by rvz - I found that a big issue with it in practice is that the numbers are just not great, and the repo is very vibe-coded. When the numbers are great, it's sometimes cheating with the setup. For example some GEMMs only compute each 8th value and reach close to peak TFLOPs because of this, but it's a vibe-coded reward hack and the verifier does not check all numbers of the target.
Also, compilers have a lot to prove in 2026. Why not just hill-climb a Triton or Cuda kernel if you need perf?
by augment_me - I'm glad that it's open source now and they are supporting a lot more hardware. There are some interesting features that I hope the language design community pays attention to.
It's built on top of MLIR so you can make compiler optimizations in a library instead of the compiler. I believe Reactant.jl has been using MLIR for optimizing higher level abstractions in Julia. Imagine a Lisp with that capability.
by bobajeff - Indeed Reactant looks like a young, fantastic piece of technology.
- Julia is a Lisp, just like Dylan or Lisp 2.
Many Lisps have that capability.
by pjmlp - Mojo as MLIR++ is how I've thought about it as well.
Many users will find transpiling static python to mojo an interesting path.
Updating py2many --mojo to 1.0 to see what breaks.
Also looking forward to translating existing python adt module to mojo Variant in phase 2. I hope the mojo pattern matching proposal looks more like rust (expression) and not like python (statement).
by adsharma