[pjmlp]

Julia is more mature for the same purposes, and since last year NVidia is having feature parity between Python and C++ tooling on CUDA.

Python cuTile JIT compiler allows writing CUDA kernels in straight Python.

AMD and Intel are following up with similar approaches.

If Mojo will still arrive on time to gain wider adoption remains to be seen.

[adev_]

> Python cuTile JIT compiler allows writing CUDA kernels in straight Python.

It is currently not straight Python and will never be.

All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.

They are DSL with a python-looking syntax but made to be optimized, typed and inferred properly. And it feels like it when you use it: in each of them, there is many (most?) python features you simply can not use while you still suffer of inherent python issues.

Lets not lie to ourself: Python is inherently bad for efficiency and performance.

And that goes way beyond the GIL: dynamic typing, reference semantics, monkey patching, ultra-dynamic object model, CPython ABI, BigInt by default, runtime module system, ... are all technical choices that makes sense for a small scripting language but terribly sucks for HPC and efficiency.

The entire Numpy/scipy ecosystem itself is already just a hack around Python limitations for simple CPU bound tensor arithmetics. Mainly because builtin python performance sucks so much that a simple for loop would make Excel looks like a race horse.

Mojo is different.

Mojo tries to start from a clean sheet instead of hacking the existing crap.

And tries to provide a "Python like experience" but on top of a well designed language constructed over past language design experience (Python is >30y old)

And just for that, I wish them success.

[jdiaz97]

> Mojo tries to start from a clean sheet instead of hacking the existing crap.

Their whole original pitch was to be a superset of Python btw.

[adev_]

> Their whole original pitch was to be a superset of Python btw.

To my understanding, they offer a full python compatibility but guide the user to something else.

For instance, Mojo itself is statically typed.

[kstrauser]

> All these "Performance friendly" python dialects (Tryton, Pythran, CuTile, Numba, Pycell, cuPy, ...) appears like Python but are nothing like Python as soon as you scratch the surface.

Which is the whole point. Python has properties that make it bad for massive, fast number twiddling. However, it’s exceptionally nice for doing all the command line parsing and file loading and setup and other wrapping tasks required to run those pipelines.

Fortran’s fantastic at math stuff. I’d sure hate to have to write all the related non-math stuff in it.

And yes, Python’s slower than other languages. But in production, most Python code spends a huge chunk of its time waiting for other code to execute. It takes more CPU for Python to parse an HTTP request or load data files than an AOT language would take, but it’s as efficient sitting there twiddling its thumbs waiting for a DB query or numeric library to finish.

[IshKebab]

I wouldn't call it "exceptionally nice". Decentish if you use uv & strict Pyright... sure.

> most Python code spends a huge chunk of its time waiting for other code to execute.

Highly dependent on what you are doing. That hasn't been my experience most of the time.

[jz391]

> I wouldn't call it "exceptionally nice"

I guess depends on your reference point :-) I recall in the beginning, python offering an easier/more readable alternative to Perl, which itself was a step up from awk/sed/sh script (for the tasks/uses GP mentions)

[loglog]

> on top of a well designed language constructed over past language design experience

While I believe that Chris Lattner is a great compiler designer, his language design record has been less stellar. Swift bidirectional type inference for instance feels like it was implemented because they had a compiler algorithm that they wanted to use, rather than a genuine need, and is just a completely avoidable problem. Trying to make a HPC language that is also Python compatible was doomed from the start. Hopefully the damage from going into this direction will remain limited.

[pjmlp]

I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves, but anyone else that does the same, it is no longer the same language.

As for Python not being the ideal, there we agree, but the solutions with proper performance already exist, Lisp, Scheme, Julia, Futhark,...

Heck maybe someone could dig out StarLisp.

[adev_]

> I love when dialects for C and C++ count as being proper C and C++, are even argued as being more relevant than ISO standards by themselves

I did not argue about CUDA being proper C++ :)

I honestly believe that the best days of C++ as an accelerator language are behind.

That is the main problem currently: We do miss a modern language for system programming that play well with accelerators. C++ is not (really) one of them (Hello aliasing).

I do not know if Mojo will succeed there, but I wish them good luck.

[pjmlp]

I would argue Chapel or Futhark could be such languages, but they aren't cool.

[vovavili]

I just checked out Chapel because of this comment and it is very high up there among the coolest things I've seen this whole entire year.

[adev_]

Chapel maybe, but it is too low level to attract a large public outside of the HPC community.