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.
It was highly aspirational goal, and practically speaking it's better right now to take inspiration from Python and have stronger integration hooks into the language (full disclosure, I work at Modular). We've specifically stopped using the "superset of Python" language to be more accurate about what the language is meant for right now.
There's pretty broad support for server-grade and consumer GPUs. It's a bit buried, but one of the most reliable lists of supported GPUs is in the Mojo info documentation.https://docs.modular.com/mojo/stdlib/gpu/host/info/
The comic is a fun bit of side marketing we put together (full disclosure, I work for Modular leading the DA/community team). On the "showing our work" side of things, there have been a few recent posts we've published. We recently open sourced about 450k+ lines of Mojo high performance kernel code.
We're pretty committed to doing this work in the open, and we've taken a bunch of direct feedback and contributions from the community that have improved the standard library (also open source) and core language.
We're also putting in a lot of work to make Mojo more accessible for users. For example, our GPU Puzzles series is turning into a cornerstone of demonstrating how Mojo is meant to improve the GPU programming experience (that's work my team is directly responsible for, and I'm really proud of the experience people have had with it).
For production workloads, I can say that we're using it in production, but as you said yourself, adoption takes time. I believe we're on the path to get there, and hopefully the work we're doing in public speaks for itself. It's really important to me that we back up our claims with evidence and real-world use cases.
You're right that a good graph compiler will do this for you. There still may be times, like if you're interfacing with another library, where you'll need to switch a matrix between row major or column major layouts.
This was the first time we ran an event in the office with this wireless mic setup. We're definitely aware of the problems, and will have them fixed for the next event.
Something to think about. This isn't the first time a show disappeared. Remember when Geek Friday was good and Dan was co-hosting it with Faith? One wonders what happened, any why Dan was made angry enough to suggest a truly dismal co-host for Faith. Blame Gruber if you want, but I'm almost certain that Dan had a part in this too.
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.