[ElectronCharge]

> 35Kx speed up is not scaled speed up.

Right. However, this is a comparison versus Python and the GIL, which can’t do that at all.

> While i think there are tons of optimizations to be done for python (looking at you GIL) giving access to low level cpu primitives is not one I think that will be broadly adopted by the python community.

It doesn’t need to be, any more than writing Numba or Pyrex is done on a large scale.

> That's one of the joys of python: system agnostic, looks pretty close to pseudocode, coding. If you want speed, glue together a bunch of compiled code calls, and hope the call overhead isn't too large. Or write cpu intensive operations in numba, or pyrex. At the end of the day, mojo's pay to play programming language harkens back to the early 90's Borland days.

The appeal is having a high level language that compiles to efficient machine (and GPU!) code. One can “drop down” to Python for non performance intensive parts.

I think this will be much more of a draw for people coming from C++, Fortran and other older, jankier languages. It looks to hit a sweet spot for real time embedded development VERY well, especially given Rust-like memory safety!

Mojo will also be a worthy competitor to Julia in the HPC scientific arena I think…we’ll see!

[catgary]

Have you played with Mojo? It really doesn’t feel high level.

I feel like JAX has been eating Julia’s lunch lately, making me think that there’s a real market for a small functional differentiable programming language with good Python interop - like a more polished Dex or Futhark.

[ElectronCharge]

> Have you played with Mojo?

Yes.

> It really doesn’t feel high level.

Does Python “feel high level”?

Mojo is a proper superset of Python.

Particular functions may deal with low-level machine features, that is unavoidable when extracting maximum performance from hardware. Mojo is pursuing some innovative ideas there, such as autotuning and adaptive compilation.

As I said in a different post, I don’t think Mojo’s main audience is the general Python community, it’s the AI, real time, embedded, safety critical, HPC, and yes, gaming, communities that’ll likely benefit the most.

[williamstein]

> Mojo is a proper superset of Python.

Isn't it more that the plan is someday Mojo may be a proper superset of Python, but right now it is far from it? I just tried opening up the Mojo playground, copy/pasted the very first little example function from the official Python tutorial (see https://docs.python.org/3/tutorial/controlflow.html#defining...) and Mojo outputs a bunch of errors.

With Cython, our goal was to make it a proper superset of Python, and it was really difficult, but we got close.

[leecarraher]

> Right. However, this is a comparison versus Python and the GIL, which can’t do that at all.

Single process python does not take advantage of a multicore architecture but neither would single process mojo. Embarrassingly parallel operations like mandlebrot can trivially be written with multiprocessing (https://github.com/DipanshuSehjal/Mandelbrot-set/blob/master...), or joblib to run in parallel in otherwise vanilla python. It would be trivial to implement this in jax and run on a gpu or tpu, but i wouldn't say that jax is the reason for the speed up.

[ElectronCharge]

> Single process python does not take advantage of a multicore architecture but neither would single process mojo.

That is exactly not the case. The Mandelbrot demo IS a single process, multi-threaded, SIMD-enabled Mojo program that uses 88 processor cores.