4 ms·

Weird that there has been no significant adoption of Mojo. It has been quite some time since it got released and everyone is still using PyTorch. Maybe the lice

Weird that there has been no significant adoption of Mojo. It has been quite some time since it got released and everyone is still using PyTorch. Maybe the license issue is a much bigger deal than people realize.

singularity2001 1y ago
Is it really released? Last time I checked it was not open sourced I don't want to rely on some proprietary vaporware stack.
- melodyogonna 1y ago
  It is released but not open-source. Modular was aiming to open-source the compiler by Q4 2026; however, Chris now says they could be able to do that considerably faster, perhaps early 2026[1]. If you're interested, they think the language will be ready for open source after completing phase 1 of the roadmap[2]. 1.https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 2. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap
melodyogonna 1y ago
It is not ready for general-purpose programming. Modular itself tried offering a Mojo api for their MAX engine, but had to give up because the language still evolved too rapidly for such an investment. As per the roadmap[1], I expect to start seeing more adoption once phase 1 is completed. 1. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap
raggi 1y ago
I'm on the systems side, and I find some of what Chris and team are doing with Mojo pretty interesting and could be useful to eradicate a bunch of polyglot ffi mess across the board. I can't invest in it or even start discussions around using it until it's actually open.
- bobajeff 1y ago
  Yeah I'm in the same boat. I plan to prototype in python and then speed up the slow bits in a low level language. I've narrowed my options to C++ and Mojo. C++ just seems like a safer bet but I'd love something better and more ergonomic.
ModernMech 1y ago
They’re not going to see serious adoption before they open source. It’s just a rule of programming languages at this point if you don’t have the clout to force it, and Modular does not. People have been burned too many times by closed source languages.
poly2it 1y ago
I definitely think the license is a major holdback for the language. Very few individuals or organisation for that matter would like to invest in a new closed stack. CUDA is accepted simply because it has been along for such a long time. GPGPU needs a Linux moment.
- deleted 1y ago
  [deleted]
subharmonicon 1y ago
The market tends to be pretty efficient for things like these. We’ve seen significant rapid adoption of several different ML solutions over the last decade, yet Mojo languishes. I think that’s a clear sign they aren’t solving the real-world pain points that users are hitting, and are building a rather niche solution that only appeals to a small number of people, no matter how good their execution may be.
jb1991 1y ago
It says at the top: > write state of the art kernels Mojo seems to be competing with C++ for writing kernels. PyTorch and Julia are high-level languages where you don't write the kernels.
- Alexander-Barth 1y ago
  Actually in julia you can write kernels with a subset of the julia language: https://cuda.juliagpu.org/stable/tutorials/introduction/#Writing-your-first-GPU-kernel https://cuda.juliagpu.org/stable/tutorials/introduction/#Wri... With KernelAbstractions.jl you can actually target CUDA and ROCm: https://juliagpu.github.io/KernelAbstractions.jl/stable/kernels/ https://juliagpu.github.io/KernelAbstractions.jl/stable/kern... For python (or rather python-like), there is also triton (and probably others): https://pytorch.org/blog/triton-kernel-compilation-stages/ https://pytorch.org/blog/triton-kernel-compilation-stages/
  - davidatbu 1y ago
    Chris's claim (at least with regards to Triton) is that it avails 80% of the performance, and they're aiming for closer to 100%.
- jakobnissen 1y ago
  I think Julia aspires to be performant enough that you can write the kernels in Julia, so Julia is more like Mojo + Python together. Although I have my doubts that Julia is actually willing to make the compromises which would allow Julia to go that low level. I.e. semantic guarantees about allocations and inference, guarantees about certain optimizations, and more.
- pjmlp 1y ago
  You can write kernels with Python using CUDA and Open API SDKs in 2025, that is one of the adoption problems regarding Mojo.
fnands 1y ago
It's still very much in a beta stage, so a little bit hard to use yet. Mojo is effectively an internal tool that Modular have released publicly. I'd be surprised to see any serious adoption until a 1.0 state is reached. But as the other commented said, it's not really competing with PyTorch, it's competing with CUDA.
pjmlp 1y ago
I personally think they overshot themselves. First of all some people really like Julia, regardless of how it gets discussed on HN, its commercial use has been steadily growing, and has GPGPU support. On the other hand, regardless of the sore state of JIT compilers on CPU side for Python, at least MVidia and Intel are quite serious on Python DSLs for GPGPU programming on CUDA and One API, so one gets close enough to C++ performance while staying in Python. So Mojo isn't that appealing in the end.
- nickpsecurity 1y ago
  Here's some benefits it might try to offer as differentiators: 1. Easy packaging into one executable. Then, making sure that can be reproducible across versions. Getting code from prior, AI papers to rub can be hard. 2. Predictability vs Python runtime. Think concurrent, low-latency GC's or low/zero-overhead abstractions. 3. Metaprogramming. There have been macro proposals for Python. Mojo could borrow from D or Rust here. 4. Extensibility in a way where extensions don't get too tied into the internal state of Mojo like they do Python. I've considered Python to C++, Rust, or parallelized Python schemes many times. The extension interplay is harder to deal with than either Python or C++ itself. 5. Write once, run anywhere, to effortlessly move code across different accelerators. Several frameworks are doing this. 6. Heterogenous, hot-swappable, vendor-neutral acceleration. That's what I'm calling it when you can use the same code in a cluster with a combination of Nvidia GPU', AMD GPU's, Gaudi3's, NPU's, SIMD chips, etc.
  - pjmlp 1y ago
    Agree in most points, however I still can't use it today on Windows, and it needs that unavoidable framework. Languages on their own is very hard to gain adoption.
- dsharlet 1y ago
  The problem I've seen is this: in order to get good performance, no matter what language you use, you need to understand the hardware and how to use the instructions you want to use. It's not enough to know that you want to use tensor cores or whatever, you also need to understand the myriad low level requirements they have. Most people that know this kind of thing don't get much value out of using a high level language to do it, and it's a huge risk because if the language fails to generate something that you want, you're stuck until a compiler team fixes and ships a patch which could take weeks or months. Even extremely fast bug fixes are still extremely slow on the timescales people want to work on. I've spent a lot of my career trying to make high level languages for performance work well, and I've basically decided that the sweet spot for me is C++ templates: I can get the compiler to generate a lot of good code concisely, and when it fails the escape hatch of just writing some architecture specific intrinsics is right there whenever it is needed.
pansa2 1y ago
Sounds to me like it's very incomplete: > maybe a year, 18 months from now [...] we’ll add classes

singularity2001 1y ago

Is it really released? Last time I checked it was not open sourced I don't want to rely on some proprietary vaporware stack.

melodyogonna 1y ago
It is released but not open-source. Modular was aiming to open-source the compiler by Q4 2026; however, Chris now says they could be able to do that considerably faster, perhaps early 2026[1]. If you're interested, they think the language will be ready for open source after completing phase 1 of the roadmap[2]. 1.https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 https://youtu.be/I0_XvXXlG5w?si=KlHAGsFl5y1yhXnm&t=943 2. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap

melodyogonna 1y ago

It is not ready for general-purpose programming. Modular itself tried offering a Mojo api for their MAX engine, but had to give up because the language still evolved too rapidly for such an investment. As per the roadmap[1], I expect to start seeing more adoption once phase 1 is completed. 1. https://docs.modular.com/mojo/roadmap https://docs.modular.com/mojo/roadmap

raggi 1y ago

I'm on the systems side, and I find some of what Chris and team are doing with Mojo pretty interesting and could be useful to eradicate a bunch of polyglot ffi mess across the board. I can't invest in it or even start discussions around using it until it's actually open.

bobajeff 1y ago
Yeah I'm in the same boat. I plan to prototype in python and then speed up the slow bits in a low level language. I've narrowed my options to C++ and Mojo. C++ just seems like a safer bet but I'd love something better and more ergonomic.

ModernMech 1y ago

They’re not going to see serious adoption before they open source. It’s just a rule of programming languages at this point if you don’t have the clout to force it, and Modular does not. People have been burned too many times by closed source languages.

poly2it 1y ago

I definitely think the license is a major holdback for the language. Very few individuals or organisation for that matter would like to invest in a new closed stack. CUDA is accepted simply because it has been along for such a long time. GPGPU needs a Linux moment.

deleted 1y ago
[deleted]

subharmonicon 1y ago

The market tends to be pretty efficient for things like these. We’ve seen significant rapid adoption of several different ML solutions over the last decade, yet Mojo languishes. I think that’s a clear sign they aren’t solving the real-world pain points that users are hitting, and are building a rather niche solution that only appeals to a small number of people, no matter how good their execution may be.

jb1991 1y ago

It says at the top: > write state of the art kernels Mojo seems to be competing with C++ for writing kernels. PyTorch and Julia are high-level languages where you don't write the kernels.

Alexander-Barth 1y ago
Actually in julia you can write kernels with a subset of the julia language: https://cuda.juliagpu.org/stable/tutorials/introduction/#Writing-your-first-GPU-kernel https://cuda.juliagpu.org/stable/tutorials/introduction/#Wri... With KernelAbstractions.jl you can actually target CUDA and ROCm: https://juliagpu.github.io/KernelAbstractions.jl/stable/kernels/ https://juliagpu.github.io/KernelAbstractions.jl/stable/kern... For python (or rather python-like), there is also triton (and probably others): https://pytorch.org/blog/triton-kernel-compilation-stages/ https://pytorch.org/blog/triton-kernel-compilation-stages/
- davidatbu 1y ago
  Chris's claim (at least with regards to Triton) is that it avails 80% of the performance, and they're aiming for closer to 100%.
jakobnissen 1y ago
I think Julia aspires to be performant enough that you can write the kernels in Julia, so Julia is more like Mojo + Python together. Although I have my doubts that Julia is actually willing to make the compromises which would allow Julia to go that low level. I.e. semantic guarantees about allocations and inference, guarantees about certain optimizations, and more.
pjmlp 1y ago
You can write kernels with Python using CUDA and Open API SDKs in 2025, that is one of the adoption problems regarding Mojo.

fnands 1y ago

It's still very much in a beta stage, so a little bit hard to use yet. Mojo is effectively an internal tool that Modular have released publicly. I'd be surprised to see any serious adoption until a 1.0 state is reached. But as the other commented said, it's not really competing with PyTorch, it's competing with CUDA.

pjmlp 1y ago

I personally think they overshot themselves. First of all some people really like Julia, regardless of how it gets discussed on HN, its commercial use has been steadily growing, and has GPGPU support. On the other hand, regardless of the sore state of JIT compilers on CPU side for Python, at least MVidia and Intel are quite serious on Python DSLs for GPGPU programming on CUDA and One API, so one gets close enough to C++ performance while staying in Python. So Mojo isn't that appealing in the end.

nickpsecurity 1y ago
Here's some benefits it might try to offer as differentiators: 1. Easy packaging into one executable. Then, making sure that can be reproducible across versions. Getting code from prior, AI papers to rub can be hard. 2. Predictability vs Python runtime. Think concurrent, low-latency GC's or low/zero-overhead abstractions. 3. Metaprogramming. There have been macro proposals for Python. Mojo could borrow from D or Rust here. 4. Extensibility in a way where extensions don't get too tied into the internal state of Mojo like they do Python. I've considered Python to C++, Rust, or parallelized Python schemes many times. The extension interplay is harder to deal with than either Python or C++ itself. 5. Write once, run anywhere, to effortlessly move code across different accelerators. Several frameworks are doing this. 6. Heterogenous, hot-swappable, vendor-neutral acceleration. That's what I'm calling it when you can use the same code in a cluster with a combination of Nvidia GPU', AMD GPU's, Gaudi3's, NPU's, SIMD chips, etc.
- pjmlp 1y ago
  Agree in most points, however I still can't use it today on Windows, and it needs that unavoidable framework. Languages on their own is very hard to gain adoption.
dsharlet 1y ago
The problem I've seen is this: in order to get good performance, no matter what language you use, you need to understand the hardware and how to use the instructions you want to use. It's not enough to know that you want to use tensor cores or whatever, you also need to understand the myriad low level requirements they have. Most people that know this kind of thing don't get much value out of using a high level language to do it, and it's a huge risk because if the language fails to generate something that you want, you're stuck until a compiler team fixes and ships a patch which could take weeks or months. Even extremely fast bug fixes are still extremely slow on the timescales people want to work on. I've spent a lot of my career trying to make high level languages for performance work well, and I've basically decided that the sweet spot for me is C++ templates: I can get the compiler to generate a lot of good code concisely, and when it fails the escape hatch of just writing some architecture specific intrinsics is right there whenever it is needed.

pansa2 1y ago

Sounds to me like it's very incomplete: > maybe a year, 18 months from now [...] we’ll add classes