Love this intentionality: ” Our open source approach has been deliberate: we’ve found that small and tight-knit design teams (not committees) are the best for finding the “soul” of a language, but that feedback from a broader community is essential to escape an echo chamber. As such, we first open-sourced the Mojo standard library, then released hundreds of thousands of lines of kernel code written in Mojo, tools, and support. We built together with community feedback and public design proposals, and are now open sourcing the compiler. We will continue to open our processes further as Mojo keeps maturing.”
I don't think the goal of being a true Python superset ever existed.
Given that there are so many failed attempts to optimise arbitrary Python code, it was dubious from the start. Furthermore, the documentation completely ignored these challenges and made it clear that Mojo's goal was to compile to MLIR in order to write kernels for machine learning. The first example of Mojo code was a low level matrix multiplication kernel taking advantage of fancy compilation features and the documentation advertised pointers inspired by Rust's move semantics, neither of which are typically considered friendly or relevant to high level programmers.
That's a bold claim, I would be surprised if that were why they made the decision, there's other Python-like languages that don't need to pretend to be a superset to be successful.
Being a superset of Python may not be necessary to be successful, but perhaps non-committally proposing it was necessary for Modular to win the funding they wanted. While lots of people indirectly run GPU kernels with PyTorch, I think the number of people wanting to write their own kernels is considerably smaller and that this niche already has established players (plenty of whom even already build on top of MLIR), making Mojo's most obvious use case difficult to sell.
it definetely existed and was one of the major things why I was interested in it. I wished I could have used this to slowly migrate away from Python codes in Physics.
But alas they dropped the goal and for me the ball with the decision to stop following this. I will probably not write mojo code when I could use Rust or Julia instead, which are more aligned with my necessities.
It is still a goal. Mojo's semantics are still driven by Pythons, and can only deviate where safety or performance is an issue. Eventually it'll get the dynamic parts of Python
