The Mojo language (by Modular, now Qualcomm) is now open-source • Hacker News Board

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#91

Post by eigenspace » Wed, Aug 19, 2026, 4:05 PM UTC

dnautics wrote: post #84

eigenspace wrote: post #41

Earlier quoted context omitted.

IMO saying julia is literally a lisp is just not worth the type of discussion it generates. I'd much prefer to say the important part: Julia learned a ton of very important lessons from the lisp family of languages, and has integrated a lot of them.

isnt its core literally femtolisp, ehich was written by one of the julia authors?

The parser and lowering passes were in femtolisp, and yes Jeff wrote femtolisp.

However, There's now a pure julia implementation of the parser that's on by default, and the julia implementation of lowering is also almost done and ready to replace the femtolisp one.

But honestly, these things aren't really what I mean when I say julia is lispy, those are just easter eggs. I more mean the language design and semantics.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#92

Post by melodyogonna » Wed, Aug 19, 2026, 4:13 PM UTC

bwfan123 wrote: post #63

melodyogonna wrote: post #51

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…

> 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 uns…

How I wish people will stop spamming me with this garbage, or at least do some basic research first; C/C++ are not lower-level than Mojo, in fact, a core semantic of Mojo is that the programmer is as explicit as possible while defining what they want to accomplish rather than relying on compiler optimisations. You have facilities to interact with MLIR, LLVM, and Assembly intrinsics... in fact, most (if not all) of built-in Mojo types is exactly this, types wrapping low-level compiler MLIR intrisics.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#93

Post by hedgehog » Wed, Aug 19, 2026, 4:18 PM UTC

geodel wrote: post #83

kibwen wrote: post #65

Earlier quoted context omitted.

> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning. Then he has learned the completely wrong lesson. Swift spent its first years floundering from breaking change to breaking change (from Swift 1.0 in 20…

Well I think point was if they had gotten some fundamental things right from beginning they would not have to go through this 4.0 -> 5.0 breakage mess. > Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years One can keep pounding on this but endless d…

I think a bigger issue than open source timing is the community governance necessary to shape a tool that serves the needs of a lot of stakeholders. Swift has lived under the shadow of Apple's (often secret) product priorities. The extremely poor backwards compatibility is why I invested in Rust instead, and I think Chris has expressed some misgivings about how the function builder stuff got added unilaterally. It appears what they're trying to do with Mojo is build a more coherent starting design with a closed process but the experience of client work, and then open having skipped over some of the teething issues. We'll see if it works.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#94

Post by hedgehog » Wed, Aug 19, 2026, 4:19 PM UTC

pjmlp wrote: post #39

flaburgan wrote: post #2

Summarized here: https://www.phoronix.com/news/Modular-Mojo-Open-Source This is by Chris Lattner, known for LLVM and Swift.

Also Swift for Tensorflow, lets not ignore that effort as well.

I was pretty disappointed that didn't work out, but it also is a direct precursor to Mojo which actually makes me more optimistic about Mojo's design choices.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#95

Post by flakiness » Wed, Aug 19, 2026, 4:21 PM UTC

lr1970 wrote: post #50

joshuakelleyds wrote: post #40

I would add quick note to this as title is misleading * It was partially open-sourced before this. There were a lot of cool things they open sourced before like MAX for large scale LLM serving which was outperforming VLLM, Dynamo, etc on a lot of models. (super valuable GPU kernels). This is why Qualcomm acquire them imo. * Chris (also created swift) talked in the past the reason for not fully open-sourcing was more…

> * Chris (also created swift) He also created LLVM compiler

Also MLIR which is so prevalent in the ML compile stack everywhere.

https://mlir.llvm.org/

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#96

Post by flakiness » Wed, Aug 19, 2026, 4:23 PM UTC

If we program NPUs on Qualcomm-based chips using Mojo, the PC AI programming as a hobby would be getting much more interesting. I wish they don't limit this to the server chips.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#97

Post by GeekyBear » Wed, Aug 19, 2026, 4:31 PM UTC

lr1970 wrote: post #50

joshuakelleyds wrote: post #40

I would add quick note to this as title is misleading * It was partially open-sourced before this. There were a lot of cool things they open sourced before like MAX for large scale LLM serving which was outperforming VLLM, Dynamo, etc on a lot of models. (super valuable GPU kernels). This is why Qualcomm acquire them imo. * Chris (also created swift) talked in the past the reason for not fully open-sourcing was more…

> * Chris (also created swift) He also created LLVM compiler

Also Clang and OpenCL.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#98

Post by kibwen » Wed, Aug 19, 2026, 4:54 PM UTC

geodel wrote: post #83

kibwen wrote: post #65

Earlier quoted context omitted.

> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning. Then he has learned the completely wrong lesson. Swift spent its first years floundering from breaking change to breaking change (from Swift 1.0 in 20…

Well I think point was if they had gotten some fundamental things right from beginning they would not have to go through this 4.0 -> 5.0 breakage mess. > Rust was open-sourced from the outset, years before even its 0.1 release in 2012, which then allowed it to explore its design space in the hands of real users improving their own language without having to spend five years One can keep pounding on this but endless d…

> IMO it could a meme "What would Rust people do?" when deciding what should not be done

You betray your own ignorance here. Rust became massively successful despite having no corporate mandate or Big Tech progenitor, precisely because it listened to its users and empowered them to participate in the language design and development process. Trying to feebly gesture in the direction of Rust's async support doubly betrays your ignorance, both because Rust's async support is extremely good for its given design goals (not that it couldn't still be better), but also because you don't appear to realize that being developed in the open was what revealed the disastrous interactions between Rust's goals and the original pre-1.0 green thread runtime which characterized the language for a large proportion of its nascent development. Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#99

Post by jasode » Wed, Aug 19, 2026, 4:57 PM UTC

saghm wrote: post #55

joshuakelleyds wrote: post #40

I would add quick note to this as title is misleading * It was partially open-sourced before this. There were a lot of cool things they open sourced before like MAX for large scale LLM serving which was outperforming VLLM, Dynamo, etc on a lot of models. (super valuable GPU kernels). This is why Qualcomm acquire them imo. * Chris (also created swift) talked in the past the reason for not fully open-sourcing was more…

> Chris (also created swift) talked in the past the reason for not fully open-sourcing was more because he wanted to get all the core design decisions right. He said this was a big thing Swift got wrong as it scaled too quickly being fully ope source at I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes,…

>I don't understand what open source has to do with this. People being able to see your source code doesn't somehow prevent you from changing it however you want. Yes, they can voice their opinion on it, but you can also just ignore it.

Deep link to Chris Lattner interview where he says he learned lessons from Swift being rapidly released as open source meant that early design decisions that were suboptimal caused quick revisions. This caused a lot of complaints when later revisions to Swift caused breakages. This caused a lot of stress for Chris & the Swift team so he says he didn't want to repeat that for Mojo.

https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=2h22m05s

Sure, one can simple redo the exact same playbook with Mojo and iterate out in the open with early versions, and when people complain again about their code breaking, he can "just ignore it" but he didn't like that experience with Swift.

Re: The Mojo language (by Modular, now Qualcomm) is now open-source

#100

Post by MohamedMabrouk » Wed, Aug 19, 2026, 6:18 PM UTC

aeonflux wrote: post #3

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

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.