If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/
I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me.
Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
Funny you should say that... there was recently a very interesting announcement for a Julia-to-WASM compiler and a full-stack signals-based web framework:
WOW. Thanks for the comment I don't need to waste my time. So many choices for programming languages why would I go with something that isn't fully open source?
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 when you bump into a bug in Mojo? You have no ability to fix it yourself. 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.
It's not just CUDA and it's runtime. I am talking about its compiler, nvcc and that is closed source. [0]
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.
If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/
I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me.
Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
> mostly for the web assembly target
Funny you should say that... there was recently a very interesting announcement for a Julia-to-WASM compiler and a full-stack signals-based web framework:
https://discourse.julialang.org/t/ann-experimental-wasmtarge...
1 reply →
WOW. Thanks for the comment I don't need to waste my time. So many choices for programming languages why would I go with something that isn't fully open source?
from what I understand the goal for now is not to get the people to use it, but for enthusiasts to try it
What enthusiast worth getting feedback from is going to tinker with a locked up language?
You'd be surprised. Anyway, the compiler will be opened with 1.0 release, that's why reaching beta is exciting.
They've said they'll open source the compiler alongside the 1.0 release.
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 when you bump into a bug in Mojo? You have no ability to fix it yourself. 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.
It's not just CUDA and it's runtime. I am talking about its compiler, nvcc and that is closed source. [0]
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.
[0] https://en.wikipedia.org/wiki/Nvidia_CUDA_Compiler