Rendered at 19:50:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
bobajeff 9 hours ago [-]
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.
eigenspace 9 hours ago [-]
Julia is extremely lispy in its semantics and design, it's mostly separated by syntax.
pjmlp 7 hours ago [-]
Julia is a Lisp, just like Dylan or Lisp 2.
Many Lisps have that capability.
eigenspace 7 hours ago [-]
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.
dnautics 4 hours ago [-]
isnt its core literally femtolisp, ehich was written by one of the julia authors?
eigenspace 4 hours ago [-]
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.
pjmlp 7 hours ago [-]
Agreed.
adsharma 6 hours ago [-]
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).
thimotedupuch 8 hours ago [-]
Indeed Reactant looks like a young, fantastic piece of technology.
joshuakelleyds 7 hours ago [-]
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.
“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”
saghm 6 hours ago [-]
> 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.
eviks 1 hours ago [-]
> but you can also just ignore it.
Apparently, this isn't as easy for some people who are deeply involved
jasode 3 hours ago [-]
>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.
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.
LoganDark 4 hours ago [-]
Do you remember how long it took Python 2.7 to die after Python 3 came out? Years. It was horrible.
saghm 4 hours ago [-]
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?
geodel 4 hours ago [-]
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.
LoganDark 4 hours ago [-]
> 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.
ajb 4 hours ago [-]
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
lr1970 6 hours ago [-]
> * Chris (also created swift)
He also created LLVM compiler
flakiness 3 hours ago [-]
Also MLIR which is so prevalent in the ML compile stack everywhere.
Once they get an async story figured out I will be much more motivated to dive deeper into Mojo
ModernMech 7 hours ago [-]
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.
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.
saghm 5 hours ago [-]
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.
mirekrusin 42 minutes ago [-]
[dead]
kibwen 5 hours ago [-]
> 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.
geodel 4 hours ago [-]
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.
hedgehog 4 hours ago [-]
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.
kibwen 3 hours ago [-]
> 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.
aeonflux 11 hours ago [-]
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...
MohamedMabrouk 2 hours ago [-]
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.
mihaelm 11 hours ago [-]
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.
ubercore 6 hours ago [-]
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.
ElectronCharge 35 minutes ago [-]
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.
augment_me 4 hours ago [-]
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?
> 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.
SJMG 5 hours ago [-]
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.
aeonflux 9 hours ago [-]
> 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?
mathisfun123 6 hours ago [-]
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.
ModernMech 60 minutes ago [-]
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.
This is by Chris Lattner, known for LLVM and Swift.
pjmlp 7 hours ago [-]
Also Swift for Tensorflow, lets not ignore that effort as well.
hedgehog 4 hours ago [-]
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.
tecleandor 11 hours ago [-]
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.
fluidcruft 10 hours ago [-]
Open sourcing was on Mojo's roadmap long before Qualcomm was in the picture.
tonyhart7 9 hours ago [-]
close source language is a dumb concept anyway
knlb 11 hours ago [-]
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.
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
verdagon 5 hours ago [-]
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.
saghm 5 hours ago [-]
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.
melodyogonna 4 hours ago [-]
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.
ameliaquining 5 hours ago [-]
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.
snovymgodym 5 hours ago [-]
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.
saghm 5 hours ago [-]
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.
kibwen 5 hours ago [-]
> 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.
bwfan123 5 hours ago [-]
> 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.
melodyogonna 4 hours ago [-]
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.
stasomatic 4 hours ago [-]
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?
ameliaquining 5 hours ago [-]
I'm confused, C and C++ do require unsafe primitives? I think I must be misunderstanding your comment somehow.
5 hours ago [-]
saghm 4 hours ago [-]
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).
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.
jeltz 8 hours ago [-]
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.
acheong08 11 hours ago [-]
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
ModernMech 7 hours ago [-]
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.
fluidcruft 10 hours ago [-]
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.
martypitt 4 hours ago [-]
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?
Heidaradar 10 hours ago [-]
They made a big mistake by not open sourcing before, doubt they'll ever gain traction now.
ModernMech 8 hours ago [-]
Their goal was to get bought. Now it doesn’t matter whether they get traction, they already made a billion dollars.
adsharma 6 hours ago [-]
[ 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.
flakiness 3 hours ago [-]
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.
brightball 8 hours ago [-]
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.
Finally! I have been waiting for this for years. Mojo has great potential. I would use it for everything if it was for me
woadwarrior01 10 hours ago [-]
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.
flik 11 hours ago [-]
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.
eigenspace 9 hours ago [-]
What sort of projects are you looking at doing?
jbellis 5 hours ago [-]
If it's 2x faster than rustc, I'll switch.
wewewedxfgdf 10 hours ago [-]
Qualcomm is a notoriously closed source company.
Don't reward them with your support just because they are forced to open source something.
cromka 10 hours ago [-]
Notoriously is a stretch if almost all of Linux ARM commits these days come from them
mbanzi 8 hours ago [-]
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
rvz 10 hours ago [-]
They are no better than Nvidia.
I do not see your point.
mbanzi 8 hours ago [-]
NVIDIA is way worse and QCOM are improving
rvz 7 hours ago [-]
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.
NuclearPM 9 hours ago [-]
Did you mean “worse”?
zldar 7 hours ago [-]
I guess they want to go after CUDA for their GPU lines. Now give us the hardware.
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.
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.
cyansands 7 hours ago [-]
Mojo (owned by Qualcomm ®) is now open source™ try it! Just remember we own it
vovavili 5 hours ago [-]
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.
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.
vovavili 4 hours ago [-]
>company running out of money, not by investor pressure
Potato potato
ameliaquining 4 hours ago [-]
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.
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.
Many Lisps have that capability.
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.
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).
* 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-...
“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”
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.
Apparently, this isn't as easy for some people who are deeply involved
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.
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?
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.
No, just saying it's happened before and it doesn't seem unreasonable to be wary of it.
He also created LLVM compiler
https://mlir.llvm.org/
> 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/
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.
> 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.
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.
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 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.
Also, compilers have a lot to prove in 2026. Why not just hill-climb a Triton or Cuda kernel if you need perf?
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.
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?
Edit: a language is by definition an ecosystem. Learning/using a language that no one else uses is completely pointless.
This is by Chris Lattner, known for LLVM and Swift.
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.
https://youtu.be/eFbtGDGbdFU?si=VJ0XSiuNO9Z36DtD&t=30
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.
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.
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.
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.
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?
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.
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.
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?
> 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.
Strategically speaking, I think this only makes sense as an anti-NVIDIA play.
Don't reward them with your support just because they are forced to open source something.
I do not see your point.
At least with Mojo that is open sourced and Nvidia's nvcc is still closed.
[1] https://mojolang.org/docs/roadmap/#phase-2
[2] https://mojolang.org/docs/std/utils/variant/Variant/
Potato potato