[havercosine]

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.

[pjmlp]

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.

[melodyogonna]

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.

[markkitti]

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.

[melodyogonna]

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

[bigyabai]

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

[Archit3ch]

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

[pjmlp]

The founders won the lottery, the language most likely will never make mainstream.

[melodyogonna]

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.

[markkitti]

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.

[melodyogonna]

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?

[adev_]

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

[markkitti]

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

[Certhas]

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.