Tbh, Modular getting acquired happened sooner than I would have expected, if ever. Don't know how to feel about this one.
Also so many mixed feelings about Mojo, the programming language powering Modular. Of course Chris Lattner is free to pursue whatever he wants, his many contributions to tech will always be highly regarded, but to me it feels as if he "wasted" lots of his precious mental capacity on making Mojo a python-like language instead of trying to come up with something better from first principles. I know, the promise of Mojo eventually being a Python superset has been taken back, which I think is the right move, and I understand why Mojo's initial motivation for being close to Python was to attract ML folks, but I'm getting counterfactual regret just by thinking about what Chris Lattner could have achieved by making a new programming language truly from scratch and not letting some undesireable pythonisms muddy the language.
Anyway, sorry for rambling. Congrats to the team at Modular!
I'm actually mostly worried about the future of Mojo at this time.
Though hopefully it will be fully released open source still, but I feel there are question marks around whether it will be a priority to continue to develop by Qualcomm, or if they are mainly interested in the AI compute stack?
Time will tell I guess, but a lot feels to be up in the air.
Maybe Chris was a little unhappy about where Mojo ended up, and sees this as an opportunity to start anew on a properly designed language from scratch :D
No, this was pure speculation based on what seems like a popular view on where Mojo ended up, where the initial Python-focus don't seem to help it that much anymore.
But they changed their goal from being a python superset to pythonish language with great python interoperability. The only other thing they could've done differently is making the language not look like python superficially.
I think chris achieved his goal of creating a language which takes full advantage of MLIR and also not repeating some of the mistakes made with swift's development.
indeed, open sourcing is only half (or even less) of the picture: who is driving the open source community and how it is driven (i.e. governing structure) are probably more important IMHO. There are countless of cases where an open source project is either killed by slow death, or dictated by a single entity. Chris's previous projects like LLVM and MLIR are fortunate enough to grow and thrive organically, and that takes years if not decades to cultivate
Though, Modular should have been the team to do it. My theory is that they raised too much money too soon. With that kind of money, you get anxious investors waiting to see some magic on quarterly timelines. So Modular was forced to be compatible with Python as there's no other way to win quick developer mindshare. (Though I don't think they managed to do that either).
A closest counter path I would have expected Modular to follow was Zig or Oxide computers (I know not apples to apples comparision). Start actually attacking the problem with hindsight and lessons of 30 years of Python, build something fresh, and try to patiently win the market.
Rust is not going to win this market. The language has too much syntax friction to win over data science/AI folks and doesn't offer too much in parallel programming world. Julia, although beautiful attempt, couldn't gather enough support outside academia.
In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is likely to be in the similar position that C/C++ have been in embedded and firmware world.
Mojo already lost the moment AMD, NVIDIA and Intel decided to fully support Python and Julia.
Additionally all of the parallel programming improvements in ISO C++ are coming from them as well, Modular did not have much moat when being a follower and not a driver.
How did Mojo already lose when Qualcomm just made a $4B bet on it? You're forgetting that the language is still pre-1.0.
The way I think of this... if Modular is able to remain an open platform, being part of an established corporation with existing customers is a better way to drive penetration compared to acquiring new customers.
I'm not really sure if Mojo has lost or not, but the community has felt quite different than other language communities I have encountered. The development feels less organic and more driven by venture capital. This is most acutely felt in the current closed source development of mojo itself, which seems like it will continue into the near future.
I look forward to seeing open source mojo and the community that will bring.
> The development feels less organic and more driven by venture capital
The development has been driven by the needs of Modular.
> This is most acutely felt in the current closed source development of mojo itself
Mojo compiler is closed, the language development is quite open. Some of the proposed changes have been shelved or tweaked based on community feedback. However, you should understand that the compiler is closed to avoid design by committee and bike-shedding, Modular will and does veto decisions on core language semantics, see: https://forum.modular.com/t/canonicalize-apis-around-int/253...
> which seems like it will continue into the near future.
The compiler is getting opened this August. I must admit, a lot of people who would be normally interested in the language are hesitant to poke at it with a stick with the current license (myself included).
The language has really great set of features and functionalities wrapped in a familiar syntax, I have zero doubt it'll reach mainstream adoption.
Ha! I think whether Mojo will make mainstream or not is already a forgone conclusion. It solves too much of a technical problem to be niche. To me, it is a matter of when... not if.
It is not the only solution to that technical problem though. Past attempts at this have shown a clear preference for solutions that actually are extensions of CPython rather than distinct tool chains.
Past attempts at what exactly, I'm not sure I follow. Are you talking about two-language problem, heterogenous compute, or cross-platform accerelated compute stack?
> My theory is that they raised too much money too soon.
That's also my feeling. And that's the curse of many VC funded companies. And they are not even in the classical state of enshitification yet.
> Rust is not going to win this market.
Agree. Rust will never win this market. Nor Zig, which has the same genetical flaws as C++ for accelerators (excessive usage of pointer semantics among others).
> Julia, although beautiful attempt, couldn't gather enough support outside academia.
I will look mean, but for me, Julia is a language that never went to the design board. It sticked to a "Let's put Python on top of LLVM and add a proper GC" with one single objective: "let's make a clone of Python but fast".
My feeling is also that it is an academia niche and will remain one.
> In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment.
It is, and it is honestly pretty depressing.
Triton solves most of the performance issues of Python for accelerators but also introduces one (several on fact) more DSL, one more tooling ecosystem and solves none of the (long list of) issues related to Python/Numpy programming model.
I think this is unfair to Julia. It has a strong lisp lineage, the just ahead of time compilation model is interesting and I think they were the first to make it work.
I agree that it's lacking in many ways, but it's not just Python on LLVM.
I do not think Julia ever intended to be a Python clone. Julia was created in 2009 when Python was not as popular as today.
I think the statement is a strange one to make about a language that emerged from a PhD thesis. While one could say the objectives of Julia's design were academic (e.g. multiple dispatch) and more attention could have been paid to the practical application of the approach (e.g. where and how do we cache all this machine code we are generating), I find it incredulous to say a six year long PhD dissertation process was not a design phase.
> Swift for Tensorflow, the project hardly survived one year after the public announcement.
This was doom to fail from the beginning.
Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change.
Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.
"Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig
Mojo builds on the Multi-Level Intermediate Representation (MLIR) compiler software framework, instead of directly on the lower level LLVM compiler framework like many languages such as Julia, Swift, C++, and Rust.[16][17]
MLIR is a newer compiler framework that allows Mojo to exploit higher level compiler passes unavailable in LLVM alone, and allows Mojo to compile down and target more than only central processing units (CPUs), including producing code that can run on graphics processing units (GPUs), Tensor Processing Units (TPUs), application-specific integrated circuits (ASICs) and other accelerators.
It can also often more effectively use certain types of CPU optimizations directly, like single instruction, multiple data (SIMD) with minor intervention by a developer, as occurs in many other languages"
"first principles" and "from scratch" are predictable failure modes... he had very good reason to pursue a Python-like language given the circumstances and objectives
I think I get what you mean and I should have been more precise in my wording. I didn't mean that an alien language that looks nothing like we have ever seen but for the sake of doing it "right" from scratch would have been a good idea. A new programming language definitely should steal the ideas of other languages that turned out to be good. But Mojo also adopted some of the arguably bad ideas from Python just because there was too much design pressure to appeal to Python programmers. I wonder what Mojo could have looked like without this particular pressure. Basically, with what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
> what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
That's what the Chris Lattner from back then came up with. I doubt that early Swift is what he would repeat exactly as it was when he would get the chance to do it these days. And current Swift definitely is far away from what he would do, I think he has been quite outspoken about that. So maybe I should make my question more precise and ask what kind of programming language Chris Lattner would come up with in 2026, having learned from all the mistakes that C++, Swift, Mojo (and many others) did?
The "else" after a for-loop that executes only when the loop completely finished without a "break" or "return". While maybe a nice concept in general, using "else" for this is only to look familiar to Python programmers. The "else" word itself is really counter intuitive here in my opinion. For more, see https://mojolang.org/docs/manual/control-flow/#for-loop-cont...
Then there's "foo if cond else bar" which is Python's kind of ternary operator and it's at least slightly contentious. One could argue if a language even needs such a construct, but at least for me, I have an easier time reading the control flow when I look at "cond ? foo : bar". It gets even worse when you nest that stuff, although that's something you shouldn't do anyway. For more, see https://mojolang.org/docs/manual/control-flow/#conditional-e...
Also, indentation based syntax... well, it's a choice. I don't know if Lattner would have chose that in a language that he would have designed to his liking from scratch. For more, see https://mojolang.org/docs/reference/compound-statements/
Then there is some scoping related badness from Python that I think is really awful. In Python and Mojo (with a caveat) you can do this:
if cond:
foo = 42
print(foo)
So the scope of a variable is function-level and Mojo adopted this and called it implicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-decla...) as opposed to the concept of explicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-decla...) they added on top which uses the "var" keyword and forces block-level scoping which I'd argue is the sane default. But no, to appease Python programmers, they have this awful function-level scoping by default and you have to opt into block-level scoping by adding a "var" in front of your variable declaration.
But earlier, I was talking about a caveat in Mojo, so it's slightly less awful, because the compiler would complain in the code example above that "foo" might be uninitialized when getting to the print statement, so that's at least something nice, where the static type system prevents stupid mistakes that function-level scoping makes possible. To be fair, all the serious type checkers for Python would catch this as well.
But I hope you get the idea. Those are things I highly doubt would have made it into the language if Lattner could have designed it to his liking from scratch.
Else on for loops is truly terrible yea. I don't understand why Python STILL hasn't come up with alternate syntax and a deprecation path.
I think the trinary op in Python is way superior to Cs, and I came to Python from C.
The variable that was never declared when you hit is bad too yea, but I don't think block level scoping is any good. Pythons rule of having just two scopes (mostly) is imo the sane thing to do. Every single block adding a scope is just chaos, and C++ really screws this up with implicit this.
Modular now joins SYCL, OpenCL, and One API on the list of cross platform languages which never really became cross platform.
After so long and so much investment in AI, the best cross-platorm API we've got for high performance Kernels is vulcan, a graphics API. That is sad.
Still, this is pretty good for Modular's employees, probably good for Qualcomm. It's just terribly disappointing for anyone who invested time learning mojo in the hope it might actually become cross platform.
I might be reading this differently, but isn't the acquisition a bet that Modular will become a manufacturer-agnostic software stack?
> "We believe the future belongs to developer-friendly, horizontal platforms that can run across diverse compute environments and give customers real choice in how and where they deploy AI," Qualcomm CEO Cristiano Amon said.
I also believe this. And I think very few people can pull it off, and Chris Latt ner is precisely one of them. I hope that the agreement includes open sourcing Mojo at some point. Chris mentioned fall 2026, iirc.
one of the reasons I rarely read press releases is that I don't believe in promises -- I believe in _incentives_. In this case, what will Qualcomm be incentivized to do? What are in their interests?
Ok, what will be Qualcomm incentive? Selling few hundred Mojo license for few thousand dollars each. Or making it open source hoping it may make big in AI / data science community and may help sell more Qualcomm hardware?
Having Mojo support multiple platforms creates incentive to adopt Mojo and therefore write code in a language which can compile and run on Qualcomm hardware. This is good for Qualcomm.
However the danger is that the language sees wide adoption but nobody uses it with Qualcomm hardware. Instead it might encourage people to buy AMD. This is a terrible outcome for Qualcomm. They paid to boost someone else's sales.
So the incentive is to make sure it runs best on Qualcomm and to at least slightly hobble other hardware. But the safest thing overall is to support Nvidia, Qualcomm, and that's it.
I think a strategy for Qualcomm would be to use Mojo and Max as a software platform to drive AI inference on ARMv9 chips such as Snapdragon either at the edge (your smartphone) or in the cloud.
The competition to CUDA and proprietary 3D APIs always overlooks developer productivity.
For some strange reason there is this expectation, maybe due to UNIX background of those folks, that portable APIs have to exist without good IDE tooling, no graphical debuggers, no high level programming models, no libraries ecosystem.
Then for some "strange" reason, GPU developers mostly pick proprietary and the cycle repeats itself.
> After so long and so much investment in AI, the best cross-platorm API we've got for high performance Kernels is vulcan, a graphics API. That is sad.
Vulkan is mighty fine, but Julia just works for me.
The reason to move away from arm has nothing to do with performance, but rather avoiding licensing snafus like happened with their laptop chips. So far no one has delivered a risc-v core with class leading performance outside of the really low end. Not saying it can’t be done, but it will likely be a step back at first.
I'm not a hardware specialist. Qualcomm already has their custom CPU core. Can't they just switch out the frontend (fetch/decode) with RISCV and the rest shouldn't be a be big problem?
Whats peoples thoughts on Tenstorrent - they were looking for funding on Hiive recently but that deal got pulled when Qualcomm rumours surface a week or so ago.
It's kind of funny that Modular is getting acquired by a hardware company considering what it's founder has said repeatedly in interviews and articles about how those companies fail to make AI stacks.
Wired said ~$4B as well and linked the 8-k with the stock amount involved in the deal - based on some simple math of price at market open for the announcement + number of shares, it's directionally accurate.
Qualcomm has acquired excellent engineering talent here, the infrastructure I've seen Modular build in the 3 years I've followed the company is insane.
It's interesting that acquire.fyi data shows tech M&A deal volume is down 11% year to date, but total deal value is up 40%. So, fewer deals are closing in tech, but the deals that are closing are much larger. I wish we had the deal value for this one.
> I don't get it.
>
> Qualcomm has almost no products in the high-end inference/training market. The industry standard is the NVIDIA Hopper H100/H200.
>
> What could they possibly get from acquiring Modular?
Don't ask what they will gain from owning it, ask what they will gain from others not owning it...
It's now focusing on inferencing, both for data centers and edge. They already have an older AI100 NPU card and have other products in the pipeline including server class CPU that they are targeting for "Agentic" applications.
Mojo seemed like a passion project. The fundamental problem was never the lack of a great programming language, and inventing a python bastard child of a language is not a solution. But, respect and congrats to the Modular folks. HW companies have notoriously bad software teams and culture and hopefully this injects some good sw dna into the acquirer.
I honestly think Mojo would be better served if it is just a high-level language for GPU programming that compiles down to PTX with clear Python/Rust interop boundaries instead of trying for the "one language, multiple computational model" thing that they seem to be going for. The programming model between CPU and GPU programming is very different: code that runs best on CPU with heavy branching behaviors should not be written the same way as massively parallel matrix multiplication oriented GPU code, which I think they will be forced to do in the MLIR level anyway.
So, you end up with a language that looks like Python, but doesn't behave like Python, and companies that adopt Mojo early with the promise of Python compatibility may find themselves running into edge cases with difficult to trace compiler error messages that would be nearly impossible to debug, especially with the addition of Zig style `comptime` as their metaprogramming model.
Yesterday, LineShine a supercomputer in China emerges as #1 in the Top500 using ARM v9 based chips and no GPUs. Today, Qualcomm a premier designer of ARMv9 licensed chips in the United States acquires Modular, who has been creating a compiler stack that provides an alternative to NVIDIA's CUDA stack.
Are you ready for Qualcomm ARMv9 powered inference running Mojo/MAX written kernels doing low-cost inference at scale for AI?
I tried, also all a little while ago, really found the puzzles fun to do and then tried to implement some basic radar pipeline things and found lots of just basic 'building blocks' for signal processing (i/o things, fft) were missing to the point I went back to JAX.
I'm still not manage memory on GPU the way I would like, but mojo (or, my ignorant first stab at it) did not let me exploit direct DMA type things anyway.
Nvidia wasn't going to buy them. Unless Mojo intended to compete toe-to-toe in the hardware space, they were destined to get bought out by a hardware underdog at some point or another.
This is where an industry-spanning consortium would have helped out, but Mojo never really built those inroads with the hardware space. They just expected everyone else to opt-in to their mercurial middleware, which is a fundamental misunderstanding of how and why CUDA is successful.
Yes, ARM sued Qualcomm, Qualcomm won, and separately Nuvia has shipped, 2, 3? times now? I don't know how it's a failure or if the delay were "huge" and "dragged out". It's not like it launched an old product or took years and years and years. 39 months between acquisition and Snapdragon X Elite being available for purchase.
> You’re equivalent of saying the Intel delays were a success too.
If Trump nuked TSMC's production lines the day before M1 went to production, and the production lines came back 3 years later, would Apple ship the M1 on it? Or, the M3?
As you point out, it makes 0 sense to ship the M1.
If it makes 0 sense, why project that idea onto me?
When faced with a contradiction, first, check your premises. (and read your interlocutor's, "It's not like it launched an old product" obviates your claim that I'd also applaud Intel's delays)
You switched your claim from "they released the same chip they would have released 3 years earlier and you're stupid for thinking that was a good idea" to "I thought it was slow [because I'm hyperfocused on Apple competition and forgot the perf vs. Intel/AMD]".
Nothing got switched. Go check the facts. The chip was made. It was delayed due to the lawsuits and drama. The first release was an old chip. Hence slow. All the same. You can slice it how you like.
AMD barely has laptop designs (the point here) and Intel is long dead in this space.
Wtf? What a joke, but I mean the best way to become a billionaire is convince someone with a billion dollars to give it to you. This is actually insane, wow. I guess Qualcomm is desperate? Nobody was bidding for this, but congrats to the team at modular?! I’m actually salty about this because like I don’t feel like mojo was even good after trying it out.
Tbh, Modular getting acquired happened sooner than I would have expected, if ever. Don't know how to feel about this one.
Also so many mixed feelings about Mojo, the programming language powering Modular. Of course Chris Lattner is free to pursue whatever he wants, his many contributions to tech will always be highly regarded, but to me it feels as if he "wasted" lots of his precious mental capacity on making Mojo a python-like language instead of trying to come up with something better from first principles. I know, the promise of Mojo eventually being a Python superset has been taken back, which I think is the right move, and I understand why Mojo's initial motivation for being close to Python was to attract ML folks, but I'm getting counterfactual regret just by thinking about what Chris Lattner could have achieved by making a new programming language truly from scratch and not letting some undesireable pythonisms muddy the language.
Anyway, sorry for rambling. Congrats to the team at Modular!
I'm actually mostly worried about the future of Mojo at this time.
Though hopefully it will be fully released open source still, but I feel there are question marks around whether it will be a priority to continue to develop by Qualcomm, or if they are mainly interested in the AI compute stack?
Time will tell I guess, but a lot feels to be up in the air.
Maybe Chris was a little unhappy about where Mojo ended up, and sees this as an opportunity to start anew on a properly designed language from scratch :D
[flagged]
No, this was pure speculation based on what seems like a popular view on where Mojo ended up, where the initial Python-focus don't seem to help it that much anymore.
But they changed their goal from being a python superset to pythonish language with great python interoperability. The only other thing they could've done differently is making the language not look like python superficially. I think chris achieved his goal of creating a language which takes full advantage of MLIR and also not repeating some of the mistakes made with swift's development.
I'm sorry, I read your message slightly wrong. Okay, makes sense to me.
Which is interesting given the Mojo blogs where they shit on the other pythonic eDSLs like Triton saying that it's a dead end
indeed, open sourcing is only half (or even less) of the picture: who is driving the open source community and how it is driven (i.e. governing structure) are probably more important IMHO. There are countless of cases where an open source project is either killed by slow death, or dictated by a single entity. Chris's previous projects like LLVM and MLIR are fortunate enough to grow and thrive organically, and that takes years if not decades to cultivate
They've said that Mojo is still on track to be open-sourced this year, post-acquisition.
According to their website, yes it will be opensourced soon
> sorry for rambling.
You're right to ramble. I also believe that the world need a high level language fitting for accelerators that is not Python.
However developing something like that is by all means not a trivial task and many failed there.
Though, Modular should have been the team to do it. My theory is that they raised too much money too soon. With that kind of money, you get anxious investors waiting to see some magic on quarterly timelines. So Modular was forced to be compatible with Python as there's no other way to win quick developer mindshare. (Though I don't think they managed to do that either).
A closest counter path I would have expected Modular to follow was Zig or Oxide computers (I know not apples to apples comparision). Start actually attacking the problem with hindsight and lessons of 30 years of Python, build something fresh, and try to patiently win the market.
Rust is not going to win this market. The language has too much syntax friction to win over data science/AI folks and doesn't offer too much in parallel programming world. Julia, although beautiful attempt, couldn't gather enough support outside academia.
In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment. It is likely to be in the similar position that C/C++ have been in embedded and firmware world.
Julia and the Python JITs from GPU vendors will.
Mojo already lost the moment AMD, NVIDIA and Intel decided to fully support Python and Julia.
Additionally all of the parallel programming improvements in ISO C++ are coming from them as well, Modular did not have much moat when being a follower and not a driver.
How did Mojo already lose when Qualcomm just made a $4B bet on it? You're forgetting that the language is still pre-1.0. The way I think of this... if Modular is able to remain an open platform, being part of an established corporation with existing customers is a better way to drive penetration compared to acquiring new customers.
I'm not really sure if Mojo has lost or not, but the community has felt quite different than other language communities I have encountered. The development feels less organic and more driven by venture capital. This is most acutely felt in the current closed source development of mojo itself, which seems like it will continue into the near future.
I look forward to seeing open source mojo and the community that will bring.
> The development feels less organic and more driven by venture capital
The development has been driven by the needs of Modular.
> This is most acutely felt in the current closed source development of mojo itself
Mojo compiler is closed, the language development is quite open. Some of the proposed changes have been shelved or tweaked based on community feedback. However, you should understand that the compiler is closed to avoid design by committee and bike-shedding, Modular will and does veto decisions on core language semantics, see: https://forum.modular.com/t/canonicalize-apis-around-int/253...
> which seems like it will continue into the near future.
The compiler is getting opened this August. I must admit, a lot of people who would be normally interested in the language are hesitant to poke at it with a stick with the current license (myself included).
The language has really great set of features and functionalities wrapped in a familiar syntax, I have zero doubt it'll reach mainstream adoption.
> I have zero doubt it'll reach mainstream adoption
Be careful. I said this 10 years ago about OpenCL, and I've ate crow ever since.
> I have zero doubt it'll reach mainstream adoption.
I'll gladly put $1000 in escrow as a bet that it never reaches more than 1% on literally any index of your choosing (TIOBE or whatever)
The founders won the lottery, the language most likely will never make mainstream.
Ha! I think whether Mojo will make mainstream or not is already a forgone conclusion. It solves too much of a technical problem to be niche. To me, it is a matter of when... not if.
It is not the only solution to that technical problem though. Past attempts at this have shown a clear preference for solutions that actually are extensions of CPython rather than distinct tool chains.
Past attempts at what exactly, I'm not sure I follow. Are you talking about two-language problem, heterogenous compute, or cross-platform accerelated compute stack?
With Qualcomm doubtful, but good news for the founders.
> How did Mojo already lose when Qualcomm just made a $4B bet on it?
NVDA market cap is $4.7T.
The difference between a billion and a trillion is roughly a trillion.
> My theory is that they raised too much money too soon.
That's also my feeling. And that's the curse of many VC funded companies. And they are not even in the classical state of enshitification yet.
> Rust is not going to win this market.
Agree. Rust will never win this market. Nor Zig, which has the same genetical flaws as C++ for accelerators (excessive usage of pointer semantics among others).
> Julia, although beautiful attempt, couldn't gather enough support outside academia.
I will look mean, but for me, Julia is a language that never went to the design board. It sticked to a "Let's put Python on top of LLVM and add a proper GC" with one single objective: "let's make a clone of Python but fast".
My feeling is also that it is an academia niche and will remain one.
> In fact, if Nvidia cuTile, Triton, Jax keep delivering, Python seems unmatched at the moment.
It is, and it is honestly pretty depressing.
Triton solves most of the performance issues of Python for accelerators but also introduces one (several on fact) more DSL, one more tooling ecosystem and solves none of the (long list of) issues related to Python/Numpy programming model.
I think this is unfair to Julia. It has a strong lisp lineage, the just ahead of time compilation model is interesting and I think they were the first to make it work.
I agree that it's lacking in many ways, but it's not just Python on LLVM.
I do not think Julia ever intended to be a Python clone. Julia was created in 2009 when Python was not as popular as today.
I think the statement is a strange one to make about a language that emerged from a PhD thesis. While one could say the objectives of Julia's design were academic (e.g. multiple dispatch) and more attention could have been paid to the practical application of the approach (e.g. where and how do we cache all this machine code we are generating), I find it incredulous to say a six year long PhD dissertation process was not a design phase.
The thesis in question can be found here: https://github.com/JeffBezanson/phdthesis/blob/master/main.p...
Lisp, see Connection Machine and Star Lisp.
Several decades of their time.
Best of all, it is actually compiled without JIT drama.
This is the reasoning behind the guys that have created a whole new Common Lisp frontend to LLVM for biochemistry research at MIT.
What is the drama with JIT? Vs AoT?
The JIT adoption drama in Python versus other programming languages ecosystems, equally dynamic.
He already did that, Swift for Tensorflow, the project hardly survived one year after the public announcement.
> Swift for Tensorflow, the project hardly survived one year after the public announcement.
This was doom to fail from the beginning.
Swift will always have the image of an Apple product binded and controlled by the Apple ecosystem. This is very unlikely to change.
Nobody sane of mind would bind there entire technology stack on something half proprietary with a support was from the beginning secondary outside of Apple platforms.
I think that was the motivation to make Mojo a superset of python.
Yes, but apparently even that ended up being a pivot, with just enough Python, and now lets see what Qualcom makes out of it.
To say nothing of "Swift for TensorFlow" when Julialang was an option.
To each their own!
Looked up Mojo
"Mojo aims to combine the usability of a high-level programming language, specifically Python, with the performance of a system programming language such as C++, Rust, and Zig
Mojo builds on the Multi-Level Intermediate Representation (MLIR) compiler software framework, instead of directly on the lower level LLVM compiler framework like many languages such as Julia, Swift, C++, and Rust.[16][17]
MLIR is a newer compiler framework that allows Mojo to exploit higher level compiler passes unavailable in LLVM alone, and allows Mojo to compile down and target more than only central processing units (CPUs), including producing code that can run on graphics processing units (GPUs), Tensor Processing Units (TPUs), application-specific integrated circuits (ASICs) and other accelerators.
It can also often more effectively use certain types of CPU optimizations directly, like single instruction, multiple data (SIMD) with minor intervention by a developer, as occurs in many other languages"
https://en.wikipedia.org/wiki/Mojo_(programming_language)
Disclaimer: I work for Modular.
Just wanted to confirm that we're still open sourcing Mojo this year!
And appreciate the nuanced feedback.
"first principles" and "from scratch" are predictable failure modes... he had very good reason to pursue a Python-like language given the circumstances and objectives
I think I get what you mean and I should have been more precise in my wording. I didn't mean that an alien language that looks nothing like we have ever seen but for the sake of doing it "right" from scratch would have been a good idea. A new programming language definitely should steal the ideas of other languages that turned out to be good. But Mojo also adopted some of the arguably bad ideas from Python just because there was too much design pressure to appeal to Python programmers. I wonder what Mojo could have looked like without this particular pressure. Basically, with what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
> what kind of programming language would a person with as much experience and good taste as Chris Lattner come up with if there were no such external pressures?
Swift
That's what the Chris Lattner from back then came up with. I doubt that early Swift is what he would repeat exactly as it was when he would get the chance to do it these days. And current Swift definitely is far away from what he would do, I think he has been quite outspoken about that. So maybe I should make my question more precise and ask what kind of programming language Chris Lattner would come up with in 2026, having learned from all the mistakes that C++, Swift, Mojo (and many others) did?
> But Mojo also adopted some of the arguably bad ideas from Python
Like what?
The "else" after a for-loop that executes only when the loop completely finished without a "break" or "return". While maybe a nice concept in general, using "else" for this is only to look familiar to Python programmers. The "else" word itself is really counter intuitive here in my opinion. For more, see https://mojolang.org/docs/manual/control-flow/#for-loop-cont...
Then there's "foo if cond else bar" which is Python's kind of ternary operator and it's at least slightly contentious. One could argue if a language even needs such a construct, but at least for me, I have an easier time reading the control flow when I look at "cond ? foo : bar". It gets even worse when you nest that stuff, although that's something you shouldn't do anyway. For more, see https://mojolang.org/docs/manual/control-flow/#conditional-e...
Also, indentation based syntax... well, it's a choice. I don't know if Lattner would have chose that in a language that he would have designed to his liking from scratch. For more, see https://mojolang.org/docs/reference/compound-statements/
Then there is some scoping related badness from Python that I think is really awful. In Python and Mojo (with a caveat) you can do this:
So the scope of a variable is function-level and Mojo adopted this and called it implicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-decla...) as opposed to the concept of explicitly-declared variables (https://mojolang.org/docs/manual/variables/#implicitly-decla...) they added on top which uses the "var" keyword and forces block-level scoping which I'd argue is the sane default. But no, to appease Python programmers, they have this awful function-level scoping by default and you have to opt into block-level scoping by adding a "var" in front of your variable declaration.But earlier, I was talking about a caveat in Mojo, so it's slightly less awful, because the compiler would complain in the code example above that "foo" might be uninitialized when getting to the print statement, so that's at least something nice, where the static type system prevents stupid mistakes that function-level scoping makes possible. To be fair, all the serious type checkers for Python would catch this as well.
But I hope you get the idea. Those are things I highly doubt would have made it into the language if Lattner could have designed it to his liking from scratch.
Else on for loops is truly terrible yea. I don't understand why Python STILL hasn't come up with alternate syntax and a deprecation path.
I think the trinary op in Python is way superior to Cs, and I came to Python from C.
The variable that was never declared when you hit is bad too yea, but I don't think block level scoping is any good. Pythons rule of having just two scopes (mostly) is imo the sane thing to do. Every single block adding a scope is just chaos, and C++ really screws this up with implicit this.
Modular now joins SYCL, OpenCL, and One API on the list of cross platform languages which never really became cross platform.
After so long and so much investment in AI, the best cross-platorm API we've got for high performance Kernels is vulcan, a graphics API. That is sad.
Still, this is pretty good for Modular's employees, probably good for Qualcomm. It's just terribly disappointing for anyone who invested time learning mojo in the hope it might actually become cross platform.
I might be reading this differently, but isn't the acquisition a bet that Modular will become a manufacturer-agnostic software stack?
> "We believe the future belongs to developer-friendly, horizontal platforms that can run across diverse compute environments and give customers real choice in how and where they deploy AI," Qualcomm CEO Cristiano Amon said.
I also believe this. And I think very few people can pull it off, and Chris Latt ner is precisely one of them. I hope that the agreement includes open sourcing Mojo at some point. Chris mentioned fall 2026, iirc.
Mojo compiler will be open in August.
TODO: license-wash via LLM
I'm not sure I follow. Modular open source uses Apache 2 with LLVM Exceptions: https://github.com/modular/modular?tab=License-1-ov-file
one of the reasons I rarely read press releases is that I don't believe in promises -- I believe in _incentives_. In this case, what will Qualcomm be incentivized to do? What are in their interests?
Ok, what will be Qualcomm incentive? Selling few hundred Mojo license for few thousand dollars each. Or making it open source hoping it may make big in AI / data science community and may help sell more Qualcomm hardware?
Qualcomm has an enormous incentive in breaking Nvidia's CUDA grip on GPU programming.
Having Mojo support multiple platforms creates incentive to adopt Mojo and therefore write code in a language which can compile and run on Qualcomm hardware. This is good for Qualcomm.
However the danger is that the language sees wide adoption but nobody uses it with Qualcomm hardware. Instead it might encourage people to buy AMD. This is a terrible outcome for Qualcomm. They paid to boost someone else's sales.
So the incentive is to make sure it runs best on Qualcomm and to at least slightly hobble other hardware. But the safest thing overall is to support Nvidia, Qualcomm, and that's it.
I think a strategy for Qualcomm would be to use Mojo and Max as a software platform to drive AI inference on ARMv9 chips such as Snapdragon either at the edge (your smartphone) or in the cloud.
The competition to CUDA and proprietary 3D APIs always overlooks developer productivity.
For some strange reason there is this expectation, maybe due to UNIX background of those folks, that portable APIs have to exist without good IDE tooling, no graphical debuggers, no high level programming models, no libraries ecosystem.
Then for some "strange" reason, GPU developers mostly pick proprietary and the cycle repeats itself.
But the Modular stack is focused on developer productivity. It is still early but there has been substantial work on all these
I am yet to see the same Windows love as CUDA.
Same to IDE integration and graphical debugging experience for GPU code.
Until now, it was been the usual UNIX cli, and text mode lldb like debugging for CPU side.
At least it what I have been made aware of.
It doesn't have a lot of Windows support yet because nobody deploys datacenter-scale AI serving on Windows OS.
Plenty of people do learn CUDA on Windows laptops....
But I get we don't want to get them on board, only complain how NVIDIA takes over everything.
> After so long and so much investment in AI, the best cross-platorm API we've got for high performance Kernels is vulcan, a graphics API. That is sad.
Vulkan is mighty fine, but Julia just works for me.
The best cross-platform API is CUDA, because we have ROCm.
Only superficially, given what CUDA provides and what ROCm supports.
Qualcomm seems to be assembling a whole portfolio of technologies/products aimed at
1. Moving beyond ARM to RISC-V
2. Being competitive for AI/could needs instai of just chips for phones and other edge devices.
Interesting to see bold and high-conviction moves in this direction. Tenstorrent, Modular, Ventana, Alphawave, etc.
> Moving beyond ARM to RISC-V
The reason to move away from arm has nothing to do with performance, but rather avoiding licensing snafus like happened with their laptop chips. So far no one has delivered a risc-v core with class leading performance outside of the really low end. Not saying it can’t be done, but it will likely be a step back at first.
I'm not a hardware specialist. Qualcomm already has their custom CPU core. Can't they just switch out the frontend (fetch/decode) with RISCV and the rest shouldn't be a be big problem?
Whats peoples thoughts on Tenstorrent - they were looking for funding on Hiive recently but that deal got pulled when Qualcomm rumours surface a week or so ago.
It's kind of funny that Modular is getting acquired by a hardware company considering what it's founder has said repeatedly in interviews and articles about how those companies fail to make AI stacks.
* https://www.modular.com/blog/democratizing-ai-compute-part-9...
Could be the reason that Qualcomm decided to buy them out. Hire someone who knows how to fix the problem.
Still the result could be that the software performance much better on their hardware than others. Priorities, competition, etc.
Patents, and tooling portfolio.
Related, Reuters reported the deal a few days ago, valued at $4b: https://www.reuters.com/legal/transactional/qualcomm-nearing...
I call BS, zero chance this traded at $4B. The fact they describe it as a "chip company" shouldn't give confidence
Wired said ~$4B as well and linked the 8-k with the stock amount involved in the deal - based on some simple math of price at market open for the announcement + number of shares, it's directionally accurate.
Qualcomm has acquired excellent engineering talent here, the infrastructure I've seen Modular build in the 3 years I've followed the company is insane.
It's interesting that acquire.fyi data shows tech M&A deal volume is down 11% year to date, but total deal value is up 40%. So, fewer deals are closing in tech, but the deals that are closing are much larger. I wish we had the deal value for this one.
It's the first sentence of the article? "an all-stock deal valued at nearly $4 billion"
I don't get it.
Qualcomm has almost no products in the high-end inference/training market. The industry standard is the NVIDIA Hopper H100/H200.
What could they possibly get from acquiring Modular?
> I don't get it. > > Qualcomm has almost no products in the high-end inference/training market. The industry standard is the NVIDIA Hopper H100/H200. > > What could they possibly get from acquiring Modular?
Don't ask what they will gain from owning it, ask what they will gain from others not owning it...
> Qualcomm has almost no products in the high-end inference/training market.
There's actually a lot of ML deployed on phones. Both Google's and Apple's photo software uses it heavily for example.
> The industry standard is the NVIDIA Hopper H100/H200.
B200/B300/GB300 actually...
Nah, the vast majority of popular deployed models are still on Hopper.
Qualcomm is pivoting.
It's now focusing on inferencing, both for data centers and edge. They already have an older AI100 NPU card and have other products in the pipeline including server class CPU that they are targeting for "Agentic" applications.
> I don't get it. Qualcomm has almost no products in the high-end inference/training market
You're allowed to get a new job. Qualcomm is allowed to enter new markets.
Are the Qualcomm Dragonfly chips not considered high end?
You've never heard of an acquihire?
I don't think $4B is reasonable for an acquihire. They must see value in the technology.
It's an all stock deal. No cash. With undoubtedly a very healthy earn out.
> They must see value in the technology.
What value? Mojo doesn't currently support any of Qualcomm's GPUs.
Exactly. If they can buy this talent to make their GPUs more valuable, then this deal makes sense.
I'm actually a little happier about this deal than expected as it means the language may actually become open source.
I have a friend who works at Modular. FWIU, the employees got shafted by the acquisition financially.
Yes I know multiple people there as well and heard the same thing.
Either this was the plan all along (cashing in on the bubble) or it’s an admission of failure.
Mojo seemed like a passion project. The fundamental problem was never the lack of a great programming language, and inventing a python bastard child of a language is not a solution. But, respect and congrats to the Modular folks. HW companies have notoriously bad software teams and culture and hopefully this injects some good sw dna into the acquirer.
I honestly think Mojo would be better served if it is just a high-level language for GPU programming that compiles down to PTX with clear Python/Rust interop boundaries instead of trying for the "one language, multiple computational model" thing that they seem to be going for. The programming model between CPU and GPU programming is very different: code that runs best on CPU with heavy branching behaviors should not be written the same way as massively parallel matrix multiplication oriented GPU code, which I think they will be forced to do in the MLIR level anyway.
So, you end up with a language that looks like Python, but doesn't behave like Python, and companies that adopt Mojo early with the promise of Python compatibility may find themselves running into edge cases with difficult to trace compiler error messages that would be nearly impossible to debug, especially with the addition of Zig style `comptime` as their metaprogramming model.
Per modular Twitter, the plan is still to open source the mojo compiler this year: https://x.com/Modular/status/2069787078032834635
Yesterday, LineShine a supercomputer in China emerges as #1 in the Top500 using ARM v9 based chips and no GPUs. Today, Qualcomm a premier designer of ARMv9 licensed chips in the United States acquires Modular, who has been creating a compiler stack that provides an alternative to NVIDIA's CUDA stack.
Are you ready for Qualcomm ARMv9 powered inference running Mojo/MAX written kernels doing low-cost inference at scale for AI?
Are you a bot?
No, of course not. I am totally not a bot. I just like to connect together unrelated events to see trends at scale.
Mark (=the person you replied to) has appeared in conferences.
Has anyone used mojo/modular extensively in their work? I installed it as soon as it was available but never went past the toy examples.
I have a friend who is doing stuff with it, and he's incredibly excited about it, which is definitely a good sign.
I was really excited about it at launch, but its proprietary nature put me off.
I tried, also all a little while ago, really found the puzzles fun to do and then tried to implement some basic radar pipeline things and found lots of just basic 'building blocks' for signal processing (i/o things, fft) were missing to the point I went back to JAX.
I'm still not manage memory on GPU the way I would like, but mojo (or, my ignorant first stab at it) did not let me exploit direct DMA type things anyway.
What radar pipelines are you working on (out of pure curiosity here)
Re-writing pretty straightforward weather processing from FPGA to GPU just to kick the tires on mojo
Of all possible acquirers, Qualcomm is the worst outcome for Mojo, rip
Nvidia wasn't going to buy them. Unless Mojo intended to compete toe-to-toe in the hardware space, they were destined to get bought out by a hardware underdog at some point or another.
This is where an industry-spanning consortium would have helped out, but Mojo never really built those inroads with the hardware space. They just expected everyone else to opt-in to their mercurial middleware, which is a fundamental misunderstanding of how and why CUDA is successful.
Why you say that? Nuvia made a massively great success with Oryon CPUs which are now all over the place.
> Nuvia made a massively great success
Not true. Nuvia has had huge delays as part of the acquisition. It resulted in ARM licensing lawsuits and many more and things dragged out.
Yes, ARM sued Qualcomm, Qualcomm won, and separately Nuvia has shipped, 2, 3? times now? I don't know how it's a failure or if the delay were "huge" and "dragged out". It's not like it launched an old product or took years and years and years. 39 months between acquisition and Snapdragon X Elite being available for purchase.
> 39 months between acquisition and Snapdragon X Elite being available for purchase.
Yes a world of a difference. That’s competing against an Apple M2 vs M4. You’ve given yourself 2 generations of disadvantage.
You’re equivalent of saying the Intel delays were a success too.
> You’re equivalent of saying the Intel delays were a success too.
If Trump nuked TSMC's production lines the day before M1 went to production, and the production lines came back 3 years later, would Apple ship the M1 on it? Or, the M3?
As you point out, it makes 0 sense to ship the M1.
If it makes 0 sense, why project that idea onto me?
When faced with a contradiction, first, check your premises. (and read your interlocutor's, "It's not like it launched an old product" obviates your claim that I'd also applaud Intel's delays)
> As you point out, it makes 0 sense to ship the M1.
But that's what happened. Go check the benchmarks. Clearly you haven't. That Snapdragon X that got released (1st gen) was way off the mark.
> When faced with a contradiction
When faced with a hallucination...
You switched your claim from "they released the same chip they would have released 3 years earlier and you're stupid for thinking that was a good idea" to "I thought it was slow [because I'm hyperfocused on Apple competition and forgot the perf vs. Intel/AMD]".
Nothing got switched. Go check the facts. The chip was made. It was delayed due to the lawsuits and drama. The first release was an old chip. Hence slow. All the same. You can slice it how you like.
AMD barely has laptop designs (the point here) and Intel is long dead in this space.
Hasn't pretty much everyone from Nuvia left QC at this point?
Yes, the principal designer engineer Williams just left. He made an announcement a month or two ago?
so the most notoriously patent oriented tech firm is buying this up. lol ;)
good for the founders. also explains why my resume got dropped on the floor as a desk reject :p
That patent orientation is why it probably won’t go anywhere.
Oh, that is unexpected... I tried applying for a position at Modular a few days ago.
latty gotta get his baggy
Welp, I think I can give up on my hope for Mojo.
Wtf? What a joke, but I mean the best way to become a billionaire is convince someone with a billion dollars to give it to you. This is actually insane, wow. I guess Qualcomm is desperate? Nobody was bidding for this, but congrats to the team at modular?! I’m actually salty about this because like I don’t feel like mojo was even good after trying it out.
RIP Modular
[flagged]
[dead]
[flagged]
As a meta comment, I'm surprised such a news is not reaching the frontpage already.
It's on the front page now.
There are multiple HN submissions on this topic and none of them gets traction. Weird...