> 1. Mojo hasn’t actually achieved these things, and the snazzy demo hides disappointing real-life performance, or
> Neither of these things are true.
> The demo, in fact, was created in just a few days
Not to detract from this, I'd trust anything Chris does, but anyone who follows similar projects (Truffle Ruby comes to mind) knows that it's very easy to implement a tiny subset of a highly dynamic language and make it fast, it's insanely hard to scale it all the way up to the most dynamic of behaviors.
The lines above read to me as a bad sign that the author of the article isn't being very honest. It definitely is a snazzy demo hiding real life performance because one way to hide performance is to implement a very small subset and make it fast.
Indeed, you're totally right about that. That's the trick with Mojo, our goal is not to make dynamic python magically fast. Yes, we are quite a bit faster at dynamic code (because we have compiler instead of an interpreter) but that isn't by relying on a 'sufficiently smart' compiler to remove the dynamism, it is just because "compilers" instead of "interpreters".
The reason Mojo is way way faster than Python is because it give programmers control over static behavior and makes it super easy to adopt incrementally where it makes sense. The key payoff of this is that the compilation process is quite simple, there are no JITs required, you get predictable and controllable performance, and you still get dynamism where you ask for it.
Mojo doesn't aim to magically make Python code faster with no work (though it does accidentally do that a little bit), Mojo gives you control so you can care about performance where you want to. 80/20 rule and all that.
Mojo also has a more advanced ownership system than Rust or Swift, which is also pretty cool if you're into such things. Check out the programmer's manual here for more info:
https://docs.modular.com/mojo/
Since it's important to get important things right in the beginning:
Please make Optional[T] as ergonomic as Swift and Kotlin with a simple '?'.
Please use a general Vector pipeline instead of manual SIMD yuckness. Autotune was neat for the demo but should be hidden inside the compiler as quickly as possible.
Please use 'import' to import python (and mojo dependencies with uppercase if necessary)
I'm a fan of optional and other algebraic datatypes, you don't need to convince me. It's in our roadmap doc! :-) OTOH, Swift has way too much special purpose sugar which I'd prefer to reduce this time around, there are ways to have the best of both worlds - ergonomic and extensible.
Remaining faithful to Python's syntax should certainly help avoid too much special purpose sugar. Most Python enthusiasts seem to be on low sugar diets.
Although that's true, TruffleRuby and GraalPy show that you can actually make highly dynamic languages extremely fast with a powerful enough JITC, which Graal/Truffle actually are. The hard part those projects are wrestling with is being 100% compatible with the entire ecosystem, warty native modules that abuse interpreter internals and all the rest. But they have the tech and manpower to do it.
So one of the key questions for Mojo is going to be this: how does it or will it compare to GraalPy as it matures, which should be able to run untyped Python at high speed, potentially even multi-threaded, with existing native extensions.
It can be that maybe the advantage is predictability, lack of warmup, that people in the AI space just prefer stuff made by a startup, that Mojo solves other pain points like packaging, all sorts of things. But it can also be that Python took off in ML exactly because it's untyped and people don't want to deal with the hassle of a type system if they don't need to.
The alternatives section of the blog post doesn't mention Graal/Truffle at all, suggesting that this is a bit of a blind spot for them. But these are well funded projects that have already yielded many-orders-of-magnitude speedups for existing code. It's not necessarily a good idea to write them off.
> Neither of these things are true.
> The demo, in fact, was created in just a few days
Not to detract from this, I'd trust anything Chris does, but anyone who follows similar projects (Truffle Ruby comes to mind) knows that it's very easy to implement a tiny subset of a highly dynamic language and make it fast, it's insanely hard to scale it all the way up to the most dynamic of behaviors.
The lines above read to me as a bad sign that the author of the article isn't being very honest. It definitely is a snazzy demo hiding real life performance because one way to hide performance is to implement a very small subset and make it fast.