Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
141–150 of 252 posts
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
Earlier quoted context omitted.
> As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.
I'm really not sure that's true.. I can't think of a single Python dev I've worked with who cared about opensource. All they cared about is the language being easy and free to use.
Earlier quoted context omitted.
This is a bit ironic, given that people seem to have no problem using CUDA all over the place... Plus they promise to open source with the 1.0 release. We'll see...
CUDA won because AMD and Intel made a mess out of OpenCL, and Khronos had no vision to support anything beyond C99 dialect until it was too late. Doesn't matter if it was closed, when the alternatives were much worse.
Earlier quoted context omitted.
> As someone in ML who's interested in performance, I'm keen for Mojo to succeed - especially the prospect of mixing GPU and CPU code in the same language. But I do wonder if the changes they're making will dissuade Python devs. Unless it's open sourced, it's a moot point, as most Python devs wont come anyway.
https://mojolang.org/docs/roadmap/#contributing-to-mojo > We're committed to open-sourcing all of Mojo, but the language is still very young and we believe a tight-knit group of engineers with a common vision moves faster than a community-driven effort. So we will continue to plan and prioritize the Mojo roadmap within Modular until more of its internal architecture is fleshed out. I hope they stick to their original…
Python is basically the master glue language at this point. If more than a few percent of execution time is spent in Python you are probably doing it wrong. Personally I don't even understand why Cython is a thing, just write performance critical functions in other languages: https://pypi.org/project/rustimport/ > https://pypi.org/project/import-zig/ > Note that you can even start threads in those languages and use f…
I know Mojo is aimed at ML, but I'm actually really interested in trying it for game development :)
When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.
That's because Mojo told you that. https://web.archive.org/web/20231221132631/https://docs.modu... > Our long-term goal is to make Mojo a superset of Python (that is, to make Mojo compatible with existing Python programs). Python programmers should be able to use Mojo immediately, and be able to access the huge ecosystem of Python packages that are available today.
It's possible the language evolves to that in the longterm, but it's not the short term goal.
We published a Mojo roadmap on Mojolang.org that helps contextualize this: https://mojolang.org/docs/roadmap/
Note: I work at Modular
When I first heard about Mojo I somehow got the impression that they intended to make it compatible with existing Python code. But it seems like they are very far away from that for the foreseeable future. I guess you can call back and forth between Python and Mojo but Mojo itself can't run existing Python code.
They also advertised a 36,000x speedup over equivalent Python if I remember correctly, without at any point clarifying that this could only be true in extreme edge cases. Feels more like a pump-dump cryptography scheme than an honest attempt to improve the Python ecosystem.
Earlier quoted context omitted.
CUDA is closed source (and will never be open sourced) and everyone is fine with it. Modular is giving you at least a public promise that they will open source Mojo it this year but some how here it is a problem. Unbelievable.
CUDA is not a programming language. It's a package with adapters for lots of languages. IMO, it's not relevant here at all. Sure proprietary packages exist for just about every language, but most modern languages are open source. You can use them, distribute them, patch them, or whatever else. For instance, you can write Python without using CUDA. CUDA's existence doesn't make Python less useful. But what do you do w…
But somehow it is a problem when Modular gives a single promise to open-source their Mojo compiler?
> For instance, you can write Python without using CUDA. CUDA's existence doesn't make Python less useful. But what do you do when you bump into a bug in Mojo? You have no ability to fix it yourself.
You don't use AI training / inference with bare Python at all.
PyTorch (which almost all AI researchers use) primarily uses CUDA as the default and it is less useful without it (all other backends are slower). If there is a bug in anywhere from PyTorch to the silicon, you need to investigate if it is a PyTorch problem, C++ or Python issue or both, or a CUDA driver issue.
So a bug in one place (Mojo) vs a bug in 4 different places and one of them (CUDA) will never be open source. The latter is worse.
> At best, you can report it to the authors and hope they care enough about it to put in the work and release an update. If you run into a Python problem, you, or someone in your org, or a paid consultant, can fix it even if the Python core team doesn't care about it.
You are assuming Modular will never open source the Mojo compiler, when it is clear that Nvidia has been completely hostile to opening anything related to CUDA and its compiler.