alt.hn

8/19/2026 at 7:47:19 AM

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

 https://www.modular.com/blog/modcon-announcements

by flaburgan

8/19/2026 at 12:40:26 PM

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

Mojo is an awesome language, I've used it a lot as a Swift/Python lover. A couple things though

* If you want to understand Mojo spend 10x the time in MLIR before. It's just a fancy MLIR wrapper (good thing)

* They still haven't lived up to the python "superset" promise and that's the big thing preventing bigger adoption.

* https://www.spheron.network/blog/modular-max-mojo-gpu-cloud-...

by joshuakelleyds

8/19/2026 at 12:47:14 PM

When people talk about a language being open source they primarily mean the compiler. A closed compiler surrounded by a collection of open source things is an anti-pattern and trap to be avoided if you're interested in open tools, that's why open sourcing the Mojo compiler was so important to many people.

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

This I don't buy so much, as there seem to be a lot of core design decisions still up in the air: https://mojolang.org/docs/roadmap/

by ModernMech

8/19/2026 at 2:03:06 PM

Chris literally was saying it from the very beginning (you can watch early interviews, obviously he was being asked about it), everything that happens with progressive opening is what he said he'll do and he gave rationale for it which is summarized by what parent comment says.

by mirekrusin

8/19/2026 at 3:08:16 PM

That doesn't seem to address what the parent comment says; they're arguing that the rationale for the progressive opening doesn't make sense, not that it didn't or wouldn't happen. If I say "I'm going to work on feature XYZ at work today because the sky is yellow and grass is purple", it would not make sense to defend my claim tomorrow by pointing out that I did work on feature XYZ.

by saghm

8/19/2026 at 7:08:16 PM

[dead]

by mirekrusin

8/19/2026 at 2:35:22 PM

> He said this was a big thing Swift got wrong as it scaled too quickly being fully open source at the beginning

“Too soon”, I could believe, but “at the beginning”? https://en.wikipedia.org/wiki/Swift_(programming_language):

“Development of Swift started in July 2010 by Chris Lattner, with the eventual collaboration of many other programmers at Apple”

and

“It was initially a proprietary language, but version 2.2 was made open-source software under the Apache License 2.0 on December 3, 2015”

by Someone

8/19/2026 at 3:35:35 PM

Has the title changed since you wrote this? It doesn't seem misleading to me. Misleading would be if it still wasn't fully open source. "It was partly open before" doesn't seem like it's worth a big warning. But that's just my impression FWIW

by ajb

8/19/2026 at 2:10:53 PM

> 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, they can voice their opinion on it, but you can also just ignore it. Yes, they might write code that depends on things that could change, but until last week it wasn't even 1.0 anyhow, so it's not like stuff might not break for people even if they didn't do that. Why was the language even being marketed at all pre-1.0 if "scaling" too quickly is a genuine concern?

The only explanation that makes any sense to me is that he (or his employer) just didn't really care about prioritizing making it open. That's totally fair, but being disingenuous about is not. It honestly just sounds like they didn't want to admit that they didn't care to prioritize being open source, and I think that has some potentially concerning implications for what to expect in terms of communication around the direction of the language and ecosystem in the future. The fact that it's being developed in the open now is good, but it doesn't seem like the actual decision making is, and that's a red flag.

by saghm

8/19/2026 at 4:57:54 PM

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

by jasode

8/20/2026 at 10:29:41 AM

That doesn't clarify anything at all to me at least. If the goal was to avoid people depending on it before it was ready, why had I been hearing about it for so long before this? Something being marketed is not consistent with a concern to avoid having people rely on it and voice their opinions.

by saghm

8/20/2026 at 11:49:19 AM

>to avoid people depending on it before it was ready, why had I been hearing about it for so long before this?

There's always been a history of various projects in beta/preview pre-1.0 versions that nevertheless don't wait for the official 1.0 release to generate buzz, attract mindshare, evangelize, etc. Typescript and Rust language did that. And today, Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.

The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.

Yes, you advised "just ignore it" but he's human and it seems reasonable to accept his answer at face value that he didn't want to redo that stressful timeline all over again for Mojo. But for some reason, his answer is unacceptable to you and prefer to think the delayed open sourcing Mojo is caused by some other hidden agenda.

I think it's as simple as comparing the the community dynamics of 2 different timelines:

- stressful to deal with angry people : iterate and fix language mistakes in 1.0 --> 2.0 --> 4.0

- calmer because of managed expectations : iterate in alpha/beta/preview 0.x --> 0.x+1 --> 1.0

Things can still break in beta .... but then again, that's the expectation around pre-1.0 versions.

by jasode

8/20/2026 at 5:34:06 PM

> Zig is still pre-1.0 and yet has similar active "marketing" via blogs, HN posts, opinion pieces, etc.

Yes, and it's open source, and more to the point, it's because the developers do genuinely seem to want feedback and interaction with the community. That's ostensibly the entire point of having public release announcements, which Mojo has had before 1.0.

> The point of the deep link is to show that for Swift, Chris did actually try your suggested idea of just releasing the early version and fix whatever mistakes are in it out in the open regardless of criticism. He didn't like how the that stressed out the team.

That does not seem accurate in terms of what I'm asking about here; if I'm reading the history right, Swift was not open source until version 2.2.

It's still not clear to me how any what you have said addresses what I'm asking: how does being closed source solve the problem that's cited as the reason for it being closed for so long, and why wouldn't not marketing/releasing the language at all be the actual solution to those sort of problems?

by saghm

8/19/2026 at 3:23:53 PM

Do you remember how long it took Python 2.7 to die after Python 3 came out? Years. It was horrible.

by LoganDark

8/19/2026 at 3:32:21 PM

I don't understand the point you're trying to make. Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time? I don't buy the claim that a pre-1.0 language only a few years old without widespread production use is comparable to one of the most widely used languages on the planet that had been around for close to two decades at the time of what you're describing.

Even if I did think that was a comparable precedent, that still doesn't address the more direct point I made about marketing the language at all if this was a concern. What does being closed source do to prevent people from running old versions of a compiler to avoid updating their code?

by saghm

8/19/2026 at 3:58:39 PM

It prevents endless discussions on github, hurt egos when my precious PR is rejected by committers, and commentary on not being true open source because they are not welcoming source contribution, feature request, when they are trying stabilize compiler and so on.

Now none of these are guaranteed to happen when it is open source. But at least it is guaranteed to not happen when its not open source.

by geodel

8/20/2026 at 10:48:23 AM

I don't understand that argument at all, unless you think that the only value of open source is in the potential for people to say nice things about your project. If you think there's inherent value in something being open source, you don't even need to have a Github repo (a tarball on your website with the source code is open source), and nothing anyone says would take away from that inherent value.

I'm firmly of the opinion that there's inherent value in being open source. I would honestly expect most developers to recognize that nowadays, but maybe I'm wrong. My concern is that someone who doesn't think this is the case is probably more likely to also not want to come right out and say it, because that would potentially prevent them from getting the value they're truly looking for from the stuff they do open source. The justifications that are being given here is that they seem to be heavily predicated on the value of open source being primarily from marketing rather than the very nature of code being open having value on its own, and I would be both surprised and disappointed if that's the opinion of the people in charge of Mojo. I'm sincerely hoping that there's something else going on here though, so I'm trying to give the benefit of the doubt and see if I'm missing something.

by saghm

8/19/2026 at 3:52:25 PM

> Are you claiming that if Mojo was open source earlier, everyone would still be using the old versions for a long time?

No, just saying it's happened before and it doesn't seem unreasonable to be wary of it.

by LoganDark

8/20/2026 at 10:34:14 AM

Okay, but by that logic, if I can point to one instance of something suboptimal happening due to software being closed source, then it's reasonable to be wary of that too. I don't see how this is a plausible justification for keeping something closed source in the absence of taking into account the likelihood of something similar happening here, and for the reasons I laid out previously, I think it's borderline absurd to claim that was a real concern in the timeline that Mojo was closed.

by saghm

8/20/2026 at 1:40:00 PM

People choose what to worry about. You can say it's unfair because they could've worried about a different set of things, but at the end of the day it's their choice.

by LoganDark

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

I'm not saying you can't worry about this; I'm saying it does not seem to be a particular compelling reason for Mojo being closed source for so long, and I'm dubious that the rationale was due to anything like this.

by saghm

8/21/2026 at 3:00:34 AM

> I'm not saying you can't worry about this

The relentless demand for justification is indistinguishable from a demand for others to stop doing things you don't like.

by chambers

8/19/2026 at 6:27:04 PM

> but you can also just ignore it.

Apparently, this isn't as easy for some people who are deeply involved

by eviks

8/19/2026 at 8:41:03 PM

E.g. GRRM avoids reading fan theories so that he doesn't change his writings to actively thwart them.

by conmod278

8/19/2026 at 2:47:06 PM

> 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 2014 to approximately Swift 5.0 in 2019) precisely because it wasn't open-sourced from the outset, instead being developed in the traditional airtight Apple fashion. In contrast, 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 pushing embarrassing major releases to an allegedly-1.0 language to fix problems that any actual user could have identified.

by kibwen

8/19/2026 at 3:46:23 PM

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 discussions about pros/cons Rust Async model, library, framework bifurcation and shortcuts to deal with it does not seem like given an open design win that many in Rust community assume.

Going by the way Rust always seems to get inserted in any language related discussion no matter what, IMO it could a meme "What would Rust people do?" when deciding what should not be done.

by geodel

8/19/2026 at 4:18:14 PM

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.

by hedgehog

8/19/2026 at 4:54:03 PM

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

by kibwen

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

> Please don't bother speaking on Rust's history or development process again, to spare us your tiresome and consistent ignorance.

Well, one can always head back to their echo chamber to avoid hurt feelings, instead of telling others to not speak their mind.

by geodel

8/21/2026 at 3:05:01 AM

"There is a cult of ignorance in the United States, and there has always been. The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'" ~ Isaac Asimov, 1980

by kibwen

8/19/2026 at 1:37:34 PM

> * Chris (also created swift)

He also created LLVM compiler

by lr1970

8/19/2026 at 4:21:06 PM

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

https://mlir.llvm.org/

by flakiness

8/19/2026 at 4:31:00 PM

Also Clang and OpenCL.

by GeekyBear

8/19/2026 at 1:32:36 PM

Once they get an async story figured out I will be much more motivated to dive deeper into Mojo

by ubercore

8/19/2026 at 10:58:33 AM

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

8/19/2026 at 11:10:58 AM

Julia is extremely lispy in its semantics and design, it's mostly separated by syntax.

by eigenspace

8/19/2026 at 2:09:22 PM

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

8/19/2026 at 12:28:55 PM

Julia is a Lisp, just like Dylan or Lisp 2.

Many Lisps have that capability.

by pjmlp

8/19/2026 at 12:42:49 PM

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.

by eigenspace

8/19/2026 at 3:47:22 PM

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

by dnautics

8/19/2026 at 4:05:48 PM

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.

by eigenspace

8/19/2026 at 12:53:54 PM

Agreed.

by pjmlp

8/19/2026 at 11:51:51 AM

Indeed Reactant looks like a young, fantastic piece of technology.

by thimotedupuch

8/19/2026 at 8:50:16 AM

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

8/19/2026 at 3:34:13 PM

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

8/19/2026 at 10:41:36 AM

> 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

8/19/2026 at 2:21:13 PM

Jane Street's use of OCamel gives them a comparative advantage in hiring. Many devs put a premium on the tools they use. Same story with Anduril/Mercury using Haskell. You can run a successful prop trading firm/weapons design shop/startup-banking(?) platform without these things. They differentiate you from your competitors by being cool, not by being the best technical solution. If anything they were otherwise unprove at scale and out of pure engineering consideration a gamble. Developers are consumers.

by SJMG

8/19/2026 at 10:54:51 AM

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

No need for snarky comments. These days tools/frameworks/languages/libraries/etc are popping all the time. Do you expect people to research every simple signal they catch in the wild?

by aeonflux

8/19/2026 at 1:35:38 PM

How noob do you have to be to really feel this way lol

Edit: a language is by definition an ecosystem. Learning/using a language that no one else uses is completely pointless.

by mathisfun123

8/19/2026 at 6:50:40 PM

The interesting opportunity in 2026 for languages is that an LLM doesn't complain if there's an ecosystem or whether any other LLMs or people are using a language, they'll just write the code in whatever language you tell it to. Already authors are writing languages with features aimed at making it more more attractive for AI to write than people. Also great for working with research languages. I just used AI to write a Halide program and I wouldn't have bothered to do so before, for the reasons you state.

by ModernMech

8/19/2026 at 6:18:14 PM

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.

by MohamedMabrouk

8/19/2026 at 9:16:09 AM

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

8/19/2026 at 1:34:52 PM

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

8/19/2026 at 7:15:45 PM

I'm in the same category, but GPU support is definitely interesting too. The idea of offloading intensive processing to the GPU has its merits.

by ElectronCharge

8/19/2026 at 11:09:10 AM

[flagged]

by jkwang

8/19/2026 at 7:47:19 AM

Summarized here: https://www.phoronix.com/news/Modular-Mojo-Open-Source

This is by Chris Lattner, known for LLVM and Swift.

by flaburgan

8/19/2026 at 12:30:50 PM

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

by pjmlp

8/19/2026 at 4:19:36 PM

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.

by hedgehog

8/19/2026 at 9:15:03 AM

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

8/19/2026 at 9:52:53 AM

Open sourcing was on Mojo's roadmap long before Qualcomm was in the picture.

by fluidcruft

8/19/2026 at 10:52:53 AM

close source language is a dumb concept anyway

by tonyhart7

8/21/2026 at 6:20:48 AM

nearly as bad as closed source compilers. Looking at you ADA (one of the imho nicest designed languages) suffering from an awfull network of closed source compilers.

by mastermage

8/19/2026 at 9:11:09 AM

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

8/19/2026 at 9:18:37 AM

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

8/19/2026 at 12:15:56 PM

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

8/19/2026 at 9:11:14 AM

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 it

by acheong08

8/19/2026 at 12:49:30 PM

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

8/19/2026 at 1:37:59 PM

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 language

by melodyogonna

8/19/2026 at 2:37:22 PM

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

8/19/2026 at 3:12:14 PM

Their comment seems to be mostly focused on surface-level syntax from what I can tell (e.g. "wrapped in a Python-like skin"; "what they imagine a good C++ will look like"). Rust code probably does resemble functional languages to someone who uses C++ primarily, and Mojo doesn't resemble them as much. I don't find that to be a particularly enlightening insight, but I have to imagine that the syntax of Mojo is one of the first things that will catch people's attention, so it's not surprising to me that it's something that people will have a lot to say about.

My hot take is that what a good C++ will act like is basically just already Rust, mostly because the main problems with C++ can only be solved by taking away some of what makes it C++ in the first place. Some C++ developers will probably not be happy with a language that takes away the parts they still want to use, but others might just not like what Rust "looks like", so if dressing up the same Rust semantics in a new skin ends up getting the world more code written without the bad parts of C++, that's probably a good thing.

by saghm

8/19/2026 at 4:00:43 PM

Yeah exactly. Rust could also be thought of as a much better C++ (semantically) but syntatically it is much more functional, while Mojo adopts (and even extends) similar memory safety ideas but dressed in a skin that is potentially much more approachable to people used to procedural programmng.

by melodyogonna

8/19/2026 at 2:37:18 PM

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.

by ameliaquining

8/19/2026 at 3:10:07 PM

Rust's type system is very Haskell/ML inspired, specifically the first class support for algebraic types and pattern matching.

Modern C++ has come a long way with typed optionals and variants, but it's very tacked-on and lacks the safety guarantees and ergonomics of a language designed with this paradigm at a fundamental level.

by snovymgodym

8/19/2026 at 3:19:36 PM

So what does this actually translate to in terms of Mojo? Rust has algebraic types and pattern matching, C++ has some specific use cases that are "tacked-on", to use your phrasing, so when the parent comment says that Mojo is what a good C++ would look like, they're saying...it doesn't have algebraic types, or that they're tacked on? It's not clear to me why that would be a selling point, so giving the parent commenter the benefit of the doubt, I don't think this sounds like what they were trying to say.

by saghm

8/21/2026 at 2:50:03 PM

I don't know about Mojo. I was just answering "...I can't think of obvious ways in which Rust's semantics (as opposed to syntax) are more functional than C++'s"

by snovymgodym

8/19/2026 at 2:40:53 PM

> 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

8/19/2026 at 4:13:41 PM

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.

by melodyogonna

8/19/2026 at 2:49:25 PM

I'm confused, C and C++ do require unsafe primitives? I think I must be misunderstanding your comment somehow.

by ameliaquining

8/19/2026 at 3:22:45 PM

It sounds like they were saying that they think you shouldn't have to use a language primitive like `unsafe` to be able to do the stuff that C/C++ does. (To be clear, I completely disagree with this viewpoint, because I don't think there's any evidence at all that agents won't struggle with the same fundamental problems in writing C/C++ that humans do, but I think it's what they're saying).

by saghm

8/19/2026 at 3:41:33 PM

that you can visualize precisely what the hw is doing with no abstractions to hide it.

How can one hold the nuances of different architectures in their head, unless you stick to something like a console that doesn't evolve much for a half a decade or more? Don't you want at least some abstraction?

by stasomatic

8/19/2026 at 2:39:15 PM

> 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

8/19/2026 at 9:51:41 AM

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

8/19/2026 at 9:33:06 AM

They made a big mistake by not open sourcing before, doubt they'll ever gain traction now.

by Heidaradar

8/19/2026 at 11:52:43 AM

Their goal was to get bought. Now it doesn’t matter whether they get traction, they already made a billion dollars.

by ModernMech

8/19/2026 at 9:57:57 AM

Really happy to see this. Kudos to Qualcomm for releasing it under a liberal Apache 2.0 license.

Strategically speaking, I think this only makes sense as an anti-NVIDIA play.

by woadwarrior01

8/19/2026 at 11:40:43 AM

If anybody wants to give a talk on this at the 2027 Carolina Code Conference, our call for speakers will be open from January to March. Love featuring languages like this.

by brightball

8/19/2026 at 2:14:35 PM

[ mojo explaining why they didn't create an embedded DSL]

> This is particularly problematic if you're trying to introduce fundamental new concepts because you can't change the grammar of Python or C++.

Yet, this is exactly the approach py2many is taking.

Keep it 99% python compatible. Deviate from the python grammar only for new features and where python made a decision incompatible with compiled language backends.

by adsharma

8/19/2026 at 3:51:54 PM

Slightly OT - but what's the process for training an LLM to author a new language like this proficiently?

I ask because I have my own language I maintain, and we're currently prompt-stuffing to get LLM's to author it - but I wonder what type of training set you'd need, and what base image one would use to fine-tune a model, and how effective it'd be?

by martypitt

8/19/2026 at 9:14:20 AM

Exciting. For hobby projects, I was looking into what should be my programming language. Open source was a criteria. Now I have choice between Rust and Mojo.

by flik

8/19/2026 at 11:09:50 AM

What sort of projects are you looking at doing?

by eigenspace

8/19/2026 at 11:57:33 AM

Finally! I have been waiting for this for years. Mojo has great potential. I would use it for everything if it was for me

by xmorse

8/19/2026 at 4:23:27 PM

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.

by flakiness

8/19/2026 at 9:54:42 AM

Qualcomm is a notoriously closed source company.

Don't reward them with your support just because they are forced to open source something.

by wewewedxfgdf

8/19/2026 at 10:05:45 AM

Notoriously is a stretch if almost all of Linux ARM commits these days come from them

by cromka

8/19/2026 at 11:36:42 AM

Qualcomm is changing a lot. They are learning and adopting open source. I’ve seen this in other Silicon vendors, they used to deal only with big corps and would talk to you only if you promised to buy millions of parts. Now they are all moving to a model where they want an open ecosystem , attract developers, promote open source. It’s changing , it’s not going to be perfect, there will be false steps but the direction is good and we all benefit from this change. As someone else said they are way ahead of NVIDIA in open source adoption so you should keep an eye on Qualcomm

by mbanzi

8/19/2026 at 10:02:40 AM

They are no better than Nvidia.

I do not see your point.

by rvz

8/19/2026 at 11:39:11 AM

NVIDIA is way worse and QCOM are improving

by mbanzi

8/19/2026 at 12:44:48 PM

I agree. Saying "Qualcomm is a notoriously closed source company." isn't really a point in the semiconductor space. They all are.

At least with Mojo that is open sourced and Nvidia's nvcc is still closed.

by rvz

8/19/2026 at 10:54:36 AM

Did you mean “worse”?

by NuclearPM

8/19/2026 at 12:24:26 PM

I guess they want to go after CUDA for their GPU lines. Now give us the hardware.

by zldar

8/19/2026 at 2:55:11 PM

If it's 2x faster than rustc, I'll switch.

by jbellis

8/19/2026 at 12:14:52 PM

I'm waiting for Phase 2[1]: especially "Algebraic data types & pattern matching". Current tagged union[2] use is pretty awkward/verbose and lacks exhaustiveness checking and typed error handling.

[1] https://mojolang.org/docs/roadmap/#phase-2

[2] https://mojolang.org/docs/std/utils/variant/Variant/

by rubymamis

8/19/2026 at 1:50:51 PM

Extensible trait support seems like another big one if the ecosystem is going to significantly grow. Not having clearly defined traits in the language made larger projects composing many libraries in Julia difficult.

by jakebol

8/19/2026 at 12:48:51 PM

Mojo (owned by Qualcomm ®) is now open source™ try it! Just remember we own it

by cyansands

8/19/2026 at 2:32:34 PM

I'd rather have an established company give broad autonomy to PL developers at a loss (Go at Google, Swift at Apple) than risk eventual squeeze when VCs ask for their money back.

by vovavili

8/19/2026 at 2:44:06 PM

Has that ever happened to a programming language?

by ameliaquining

8/19/2026 at 2:50:32 PM

Darklang is probably the closest thing that comes to mind - https://blog.darklang.com/goodbye-dark-inc-welcome-darklang-...

by vovavili

8/19/2026 at 3:13:27 PM

This was caused by the company running out of money, not by investor pressure, and it resulted in the language becoming more open rather than less. So it doesn't seem like an example at all.

by ameliaquining

8/19/2026 at 3:51:15 PM

>company running out of money, not by investor pressure

Potato potato

by vovavili

8/19/2026 at 3:58:09 PM

Those seem quite different to me? Any kind of endeavor reliant on paid labor needs a source of funding and has to shut down if it can't find any; that's different from a situation where a business could have been sustainable by itself but has already taken investment from VCs for whom that's not good enough.

by ameliaquining