I don't quite understand Mojo's decision to use Python-like syntax—honestly, I really dislike it. Aligning code through indentation feels like a strain on my eyes.
Initially (before Mojo's release), I assumed the syntax choice was for better interoperability. Since Mojo is a superset of Python, I thought it could directly call any Python code. But after reviewing some interoperability examples—both Mojo calling Python and vice versa—it doesn’t seem all that seamless or straightforward.
For example, calling Python code from Mojo requires going through a proxy to the Python interpreter, which feels no better than what pyo3 already offers. Plus, Mojo has plenty of compatibility issues when running regular Python code.
So if better interoperability isn't the main reason for sticking with Python-like syntax, the only other explanation I can think of is to attract existing Python programmers. But is syntax really the reason people shy away from GPU programming? There are far more intimidating aspects to it—C++ syntax is probably the least of anyone’s concerns.
Mojo gets pushed really hard on this site and elsewhere, but I'm still not really seeing it in production. Are there success stories that I'm just not coming to grips with yet? Am I missing out on anything in particular using C++ instead? The marketing feels reminiscent of Rust's early and patronizing "programming is hard, isn't it?" language, without any hard data that nerds actually want. Rust eventually transcended its reputation by actually putting up impressive numbers and eating its veg, but where is this effort on Mojo's behalf? The open source transition is taking its sweet time, and hearing all this superfluous corporate hoo-ha is not going to make me put chips on the table for Mojo. I don't want a comic, I want a whitepaper. I want to be treated like a member of the team, not a middle-manager with attention span issues.
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.
I don't quite understand Mojo's decision to use Python-like syntax—honestly, I really dislike it. Aligning code through indentation feels like a strain on my eyes.
Initially (before Mojo's release), I assumed the syntax choice was for better interoperability. Since Mojo is a superset of Python, I thought it could directly call any Python code. But after reviewing some interoperability examples—both Mojo calling Python and vice versa—it doesn’t seem all that seamless or straightforward.
For example, calling Python code from Mojo requires going through a proxy to the Python interpreter, which feels no better than what pyo3 already offers. Plus, Mojo has plenty of compatibility issues when running regular Python code.
So if better interoperability isn't the main reason for sticking with Python-like syntax, the only other explanation I can think of is to attract existing Python programmers. But is syntax really the reason people shy away from GPU programming? There are far more intimidating aspects to it—C++ syntax is probably the least of anyone’s concerns.
Mojo gets pushed really hard on this site and elsewhere, but I'm still not really seeing it in production. Are there success stories that I'm just not coming to grips with yet? Am I missing out on anything in particular using C++ instead? The marketing feels reminiscent of Rust's early and patronizing "programming is hard, isn't it?" language, without any hard data that nerds actually want. Rust eventually transcended its reputation by actually putting up impressive numbers and eating its veg, but where is this effort on Mojo's behalf? The open source transition is taking its sweet time, and hearing all this superfluous corporate hoo-ha is not going to make me put chips on the table for Mojo. I don't want a comic, I want a whitepaper. I want to be treated like a member of the team, not a middle-manager with attention span issues.
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.
https://www.modular.com/blog/modular-platform-25-3-450k-line...
That's been the foundation for a lot of the performance work we've demonstrated publicly, most recently with our AMD partnership announcement.
https://www.modular.com/blog/modular-x-amd-unleashing-ai-per...
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).
https://builds.modular.com/puzzles/introduction.html
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.