Python can run Mojo now

Mojo (and Modular's whole stack) is pretty much completely focused at people who are interested in inference, not training nor research so much at this moment.

So going after people who need to build low latency high-throughput inference systems.

Also as someone else pointed out, they also target all kinds of hardware, not just NVidia.

Mojo is marketed as a way to get maximum hardware performance on any hardware, not just nvidia.

This may appeal to people wanting to run their code on different hardware brands fro various reasons.

The limitations of DSLs and the pull of Python make it a practical sweet spot I think if they manage to get the Python compatibility up to par.

I love Julia and want to see it break through. It suffers from the lack of a big corporate patron.

Mojo runs on nVidia and AMD.

The competitor is Triton, not CUDA or Julia...

He popped up on r/programminglanguages last week to say a bit about that as well: https://www.reddit.com/r/ProgrammingLanguages/comments/1lfz9...

That video is restricted, do you have a public link?

From Chris Lattner on Modular discord few days ago:

Yep, that's right. Int behaving like a machine integer is very important for systems performance. Leaving the "int" namespace untouched allows us to have a object-based bigint in the future for compatibility with python. As others have mentioned above, it is still a goal to be compatible with python in time, just not a short term priority

I guess they abandoned the python superset idea? I followed them for a bit when they first publicly launched and they said "don't worry, we'll be a real python superset soon" and the biggest omission was no support for classes. A few years later, it looks to be missing the same set of python features but added a lot of their own custom language features.

Taking unchanged Python and making it fast is basically impossible.

They explicitly casted it to an 'Int' on the mojo side, but the modular website claims that isnt a specific bit-width so i am surprised

The Python superset concept was always a gimmick. The goal was always to juxtapose Python with a language that superficially looks like Python in order for you to completely migrate from Python to Mojo. It is just providing a smooth ramp for you to do so in the same Apple migrated folks from Objective-C to Swift.

Embrace. Extend. Extinguish.

[flagged]

I'm glad the blazing-fast tech is finally making it to python. Those guys were pretty busy with Rust for like the past 10 years. I'm glad they are finally starting to making a blazing-fast python stuff.

If they can manage to make good on their plans to open-source it, I'll breathe a tentative sigh of relief. I'm also rooting for them, but until they're open-source, I'm not willing to invest my own time into their ecosystem.

One of the big differences here is that the Mojo/Python interop package is doing a lot of the heavy lifting of compiling and loading the code. The goal here is to have a language that's close to Python that gives you hardware acceleration as you need it, without having to configure and build C++ code for every platform.

We've run a few events this year (disclosing again that I work for Modular, to put my comments into context), and we've had some great feedback from people who have never done GPU programming about how easy it was to get started using Mojo.

C++ is a powerful and mature language, but it also has a steep learning curve. There's a lot of space for making GPU (and other high performance computing) easier, and platforms/languages like Triton and Julia are also exploring the space alongside Mojo. There's a huge opportunity to make GPU programming easier, and a bit part of that opportunity is in abstracting away as much of the device-specific coding as you can.

I was a HPC C++ programmer for a long time, and I always found recompiling for new devices to be one of the most painful things about working in C++ (for example, the often necessary nightmare of cmake). Mojo offers a lot of affordances that improve on the programming experience at the language, compiler, and runtime levels.

The example in the article seemed a lot easier to build and use than a C++ extension.

It's unclear to me from this comment, what exactly your pushback is.

> C++ is easier.

I expect that opinion will not be universally agreed upon.

I would rather image CPython being like Common Lisp, Scheme, Raket, Smalltalk, Self compilation model.

Sadly the contenders on the corner get largely ignored, so we need to contend with special cased JIT DSLs, or writing native extensions, as in many cases CPython is only implementation that is available.

Doesn't Mojo already support this in its parameter system? https://docs.modular.com/mojo/manual/parameters/

Jitting like you mentioned is supported by the MAX graph API: https://docs.modular.com/max/tutorials/build-custom-ops. It could have a nicer syntax though to be more like Numba, I think you have an interesting idea there.

> I am not that intrigued that Python that can call some pre-compiled functions, this is already possible with any language that produces a dynamic library.

> The space that I am interested in is execution time compiled programs. A usecase of this is to generate a perfect hash data structure. Say you have a config file that lists out the keywords that you want to find, and then dynamically generate the perfect hash data structure compiled as if those keywords are compile time values (because they are).

I'm not sure I understand you correctly, but these two seem connected. If I were to do what you want to do here in Python I'd create a zig build-lib and use it with ctypes.

AFAIK, there is a zero-copy interface for objects like numpy array and torch tensors where you can do in-place manipulation in mojo.

> its big sell is changing as little as possible from an existing language.

This is not really true. Even though Mojo is adopting Python's syntax, it is a drastically different language under the hood. Mojo is innovating in many directions (eg: mlir integration, ownership model, comptime, etc). The creators didn't feel the need to innovate on syntax in addition to all that.

The real point of Mojo is not the language, it's the deep roots into MLIR which is an attempt to do what LLVM did for compilers, and do it on GPUs / ML hardware. Chris Lattner is leading the project and he created LLVM and MLIR.

I think it was pretty clear immediately that running python code was a far away goal. There was a lot more talk about lifetimes and ownership semantics than details about Python interop. Mojo is more like: Can we take the learnings of Swift and Rust and solve the usability and compile time issues, while building on MLIR to target arbitrary architectures efficiently (and call it a Python superset to raise VC money).

That said, the upside is huge. If they can get to a point where Python programmers that need to add speed learn Mojo, because it feels more familiar and interops more easily, rather than C/CPP that would be huge. And it's a much lower bar than superset of python.

The real unique selling point of Mojo is "CPU+GPU execution without CUDA", specifically, you write code that looks like code without worrying about distinctions like kernels and device functions and different ways of writing code that runs on GPU vs. code that runs on CPU, and mojo compiles it to those things.

> For a language that announced itself (and raised a lot of money on the premise of) claiming to be "a Python superset", this does not sound like a huge achievement

I feel like that depends quite a lot on what exactly is in the non-subset part of the language. Being able to use a library from the superset in the subset requires being able to translate the features into something that can run in the subset, so if the superset is doing a lot of interesting things at runtime, that isn't necessarily going to be trivial.

(I have no idea exactly what features Mojo provides beyond what's already in Python, so maybe it's not much of an achievement in this case, but my point is that this has less to do with just being a superset but about what exactly the extra stuff is, so I'm not sure I buy the argument that the marketing you mention of enough to conclude that this isn't much of an achievement.)

I've written this somewhere else before, Modular did not raise $130m to build a programming language, nobody does that. They raised that much money to revolutionize AI infrastructure, of which a language is just a subset. You should definitely check some of the things they've put together, they're amazing

It was never going to have Python semantics and be fast. Python isn't slow because of a lack of effort or money, it's slow because of all the things happening in the interpreter.

Fwiw the website still claims this:

> Further, we decided that the right long-term goal for Mojo is to adopt the syntax of Python (that is, to make Mojo compatible with existing Python programs) and to embrace the CPython implementation for long-tail ecosystem support

Which I don't think has changed.

I believe they're still working towards making the syntax and semantics more python-like.