91–100 of 108 posts
"Qualcomm to Acquire Modular 06/24/2026" https://investor.qualcomm.com/news-events/press-releases/new... Can acqui-death be far away...?
Prediction: Chris Lattner will be off chasing some other shiny thing within a year. Without a strong champion, the company will be subsumed into Qualcomm and stop publishing meaningful updates.
I used Mojo a while back before LLM laziness kicked in and agents started writing all the code. I didn't know anything about GPU programming and it almost felt dirty how easy it was to get some performant kernels running (5070). Even I could do it. I'm in financial engineering and I feel like mojo is definitely the language for that field in the future, especially with the relatively easy python interop for legacy st…
I wonder how much chance of broader adoption Mojo has now when seemingly everyone has succumbed to that LLM laziness.
Earlier quoted context omitted.
I wish they never abandoned the goal of being a true Python superset. That would have been something.
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 multiplicatio…
"Qualcomm to Acquire Modular 06/24/2026" https://investor.qualcomm.com/news-events/press-releases/new... Can acqui-death be far away...?
Prediction: Chris Lattner will be off chasing some other shiny thing within a year. Without a strong champion, the company will be subsumed into Qualcomm and stop publishing meaningful updates.
One of my favourite features of Mojo is linear types and how deeply they have been integrated into manual memory management - see: https://x.com/melodyogonna/status/2085089269484343725?s=20 . When I first learned about linear types, my first thought of the use case was making manual allocations and deallocations safer without sacrificing usability, but I didn't know what that could look like; now I do. This is great…
Earlier quoted context omitted.
I wish they never abandoned the goal of being a true Python superset. That would have been something.
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 multiplicatio…
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.
One of my favourite features of Mojo is linear types and how deeply they have been integrated into manual memory management - see: https://x.com/melodyogonna/status/2085089269484343725?s=20 . When I first learned about linear types, my first thought of the use case was making manual allocations and deallocations safer without sacrificing usability, but I didn't know what that could look like; now I do. This is great…
How does mojos linear types work in a concurrent environment?
Earlier quoted context omitted.
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 multiplicatio…
It was in their roadmap: https://forum.modular.com/t/mojo-as-a-python-superset/2490
From the roadmap:
>Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't.