Seems like it could be interesting ... Initial impression is that the animation of Mojo code vs. Python code has a bad UX. Why not just show the code side-by-side instead of animating it and making me click? Another obvious question is how is it different than Numba and so forth? https://docs.modular.com/mojo/why-mojo.html The Mojo language has lofty goals - we want full compatibility with the Python ecosystem, we wo…
Is it though? For Mojo to be a compatible replacement for Python, it would need to match the Python C ABI and the greater set of the standard library in a bug-for-bug compatible way.
The real question is whether it's bug-for-bug compatible or whether it's not. Numerical functions have a lot of nuances that effect that performance quite a bit. Are they constrained so that Python numpy log(x) gives the same as Mojo log(x)? Will C bindings act the same way as in CPython? Whole list of related questions. If there is a no to any of these questions, then code acts subtly differently in a way that is sometimes hard to detect. These differences are of course what have held back "standard code" from being numba/pypy/etc. compatible in many instances.
That said, if the answer isn't yes to anything, then it is very difficult to make optimizations. Not allowing hard to optimize Python behavior is precisely what has allowed Numba, Julia, etc. to achieve accelerations. There were some attempts at that kind of thing with R, which Jan Vitek gives some very interesting talks about (https://www.youtube.com/watch?v=VdD0nHbcyk4).
What I would find worrisome too is that this approach sounds like compile time city. A lot of the recent advancements in Julia have been by sending less to LLVM: optimizations are done in Julia and dead code is eliminated, calls are found to be the same and check caches, and then with v1.9 those caches use precompiled binaries to avoid having to call LLVM again. And the timeline of improvements shows that making LLVM be in the picture as little as possible has lead to some dramatic improvements in Julia's latency (https://viralinstruction.com/posts/latency/). Given what was seen from that, I'm weary of an approach that does everything in LLVM (via MLIR) on an even more dynamic representation (i.e. Python). My guess is that only things with explicit types will compile, and the rest is probably hitting some Python interpreter to avoid this issue.
[If part is using Python/GC through an interpreter though, wouldn't that part be harder to target to accelerators since it wouldn't compile through LLVM? That would mean only the code that is explicitly typed gets the nice new features, but not the Python parts?]
But hey, if this gets Chris Lattner and crew a reason to start taking LLVM compile times more seriously, then it's a win for Julia as well. I'm excited to see how the communities can benefit from one another, especially if Mojo is open source then it can be a win for all (which was definitely not clear in the presentation). And I do think that some of the ideas of lower level memory control are cool and should be added similarly to languages like Julia and Numba.