Qualcomm to Acquire Modular
reuters.com
reuters.com
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!
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.
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.
To each their own!
Like what?
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)
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.
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.
Swift
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.
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.
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 agree that it's lacking in many ways, but it's not just Python on LLVM.
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...
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.
I look forward to seeing open source mojo and the community that will bring.
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.
Be careful. I said this 10 years ago about OpenCL, and I've ate crow ever since.
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)
NVDA market cap is $4.7T.
The difference between a billion and a trillion is roughly a trillion.
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.
"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"
Providing usability without GC is an oxymoron.
The best attempt so far for Pythonic compiled language is D, that's probably why it's not mentioned in the Wikipedia entry along side other languages comparison. D has GC by default but manual memory management is supported as well.
Probably compiler researchers need to come with truly determinstic GC like the automotive industry invented the automatic gear. So that other existing compiled programming languages with GC like Go and D can thrive.
Just wanted to confirm that we're still open sourcing Mojo this year!
And appreciate the nuanced feedback.
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.
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.
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.
But I get we don't want to get them on board, only complain how NVIDIA takes over everything.
> "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.
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.
Vulkan is mighty fine, but Julia just works for me.
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.
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.
* https://www.modular.com/blog/democratizing-ai-compute-part-9...
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?
> They must see value in the technology.
What value? Mojo doesn't currently support any of Qualcomm's GPUs.
I'm actually a little happier about this deal than expected as it means the language may actually become open source.
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.
Don't ask what they will gain from owning it, ask what they will gain from others not owning it...
You're allowed to get a new job. Qualcomm is allowed to enter new markets.
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...
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.
Are you ready for Qualcomm ARMv9 powered inference running Mojo/MAX written kernels doing low-cost inference at scale for AI?
I was really excited about it at launch, but its proprietary nature put me off.
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.
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 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.
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)
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...
AMD barely has laptop designs (the point here) and Intel is long dead in this space.
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.
good for the founders. also explains why my resume got dropped on the floor as a desk reject :p