Mojo: The usability of Python with the performance of C
stackoverflow.blog
Mojo: The usability of Python with the performance of C
1–10 of 59 posts
Re: Mojo: The usability of Python with the performance of C
#2Both C and Python are open source. I can't take Mojo seriously until it does the same.
Re: Mojo: The usability of Python with the performance of C
#3The thing about Mojo is that the part they spend most of their time promoting in their online material (Python but faster and good for AI) doesn't seem to require a new language at all, but rather a new hardware-aware Python compiler and some extra library modules.
It sure looks like they only turned it into a new language because they wanted to add static typing and immutable references, which maybe you care about and maybe you don't.
In that light it's hard for me to appreciate the development direction they've gone in.
Re: Mojo: The usability of Python with the performance of C
#4Both C and Python are open source. I can't take Mojo seriously until it does the same.
They've also claimed both on the page and in the podcast that certain testing reveals a 68,000x speed up vs Python. That's probably true in a select case, but this is why you use libraries in Python - to make use of all the hard work that already exists in C/C++ in those libraries, with Python serving as a high level and far easier to write functional wrapper. Ie anyone serious about performance isn't going to be looking at that metric seriously, rather they're going to be asking what the real performance gains are vs standard practice. In that case the answer seems to be rather roughly a 1.5x speed up based on what's on the performance page of their site when comparing to PyTorch and CUDA, which is a more realistic scenario.
I am curious about how much work the compiler does to automatically identify available hardware and distribute the load on its own vs how much you need to specify as a developer.
Re: Mojo: The usability of Python with the performance of C
#5Most bottlenecks are IO. "speed" is rarely as important as it's marketed to be. Also rust shared libraries are already there for pretty much every language that you actually need speed
Re: Mojo: The usability of Python with the performance of C
#6Most bottlenecks are IO. "speed" is rarely as important as it's marketed to be. Also rust shared libraries are already there for pretty much every language that you actually need speed
Rust libs aren’t really there for ML, I’ve been down that road and tried them all.
Also reasoning about the borrow checker while doing hard math is a non starter for most people in the field.
Re: Mojo: The usability of Python with the performance of C
#7closed source is a no go hombre.
Re: Mojo: The usability of Python with the performance of C
#8[dead]
Re: Mojo: The usability of Python with the performance of C
#9The thing about Mojo is that the part they spend most of their time promoting in their online material (Python but faster and good for AI) doesn't seem to require a new language at all, but rather a new hardware-aware Python compiler and some extra library modules. It sure looks like they only turned it into a new language because they wanted to add static typing and immutable references, which maybe you care about a…
Indeed.
It feels like it’s a nice language and, building on LLVM makes it stand on a solid foundation, but, still, it feels like a series of PEPs, some of which I can easily get behind.
If they make mojo modules callable from Python code, it all becomes a whole lot more palatable.
Re: Mojo: The usability of Python with the performance of C
#10Most bottlenecks are IO. "speed" is rarely as important as it's marketed to be. Also rust shared libraries are already there for pretty much every language that you actually need speed
>Most bottlenecks are IO. "speed" is rarely as important as it's marketed to be.
in "your world", which aint the same for other ppl.