My biggest problem with Jupyter is hidden state. You have no idea what order the cells executed in and how many times to get to the current state. Pluto.jl and Marimo solve that by using reactivity to make state transparent. WYSIWYG.
I have also been thoroughly impressed how Marimo has engaged with AI agents. marimo-pair is fantastic.
Nitpicking - I'd argue the title is spot on! It's a new source of energy. Not a new type. But yeah, I clicked expecting a research article. Not a deep hole.
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.
> 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?
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.
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?
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.
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?
> If your organization uses Gemini CLI or our IDE extensions via a Gemini Code Assist Standard or Enterprise license, or if your organization uses Gemini Code Assist for GitHub through Google Cloud, your access remains unchanged.
I have also been thoroughly impressed how Marimo has engaged with AI agents. marimo-pair is fantastic.