4 ms·
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
by ainch 5mo ago
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. The last time I booted it up, I tried to do some basic string manipulation just to test stuff out, but spent an hour puzzling out why `var x = 'hello'; print(x[3])` didn't work, and neither did `len(x)` (turns out they'd opted for more specific byte-vs-codepoint representations, but the docs contradicted the actual implementation).
Hopefully they get Mojo to a good place for more general ML, but at the moment it still feels quite limited - they've actually deprecated some of the nice builtins they had for Tensors etc... For now I'll stick with JAX and check in periodically, fingers crossed.
- coldtea 5mo ago>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.
- Certhas 5mo agoThis 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...
- _aavaa_ 5mo agoI don’t see irony there. We’re locked into CUDA due to past decisions. And in new decisions we don’t want to repeat that mistake.
- pjmlp 5mo agoCUDA 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.
- zozbot234 5mo agoSYCL is the de facto successor to OpenCL that supports higher level languages. So the vision was and is there.
- pjmlp 5mo agoAs mentioned, Khronos only changed their mind when it was too late. I can also recite the whole story, the missteps in OpenCL 2. , OpenCL C++, the OpenCL 3.0 reboot, how SYCL came to, CodePlay only proper available implementation, Intel acquisition of CodePlay and everything else.
- physicsguy 5mo agoPlus NVIDIA clocked that it was also the developer library ecosystem and even now there just aren’t equivalents. The AMD rocFFT library wasn’t even complete compared to FFTW until very recently and cuFFT did that more than a decade ago
- MohamedMabrouk 5mo agoI think that plan is to open source the compiler with 1.0 which is expected to be this summer. so in ~3-4 months time.
- ktm5j 5mo agoI'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.
- physicsguy 5mo agoThe people that write the libraries care, why do you think Python is where we’re writing ML code and not MATLAB?
- zbentley 5mo agoMojo is free, though. MATLAB costing money is a bigger issue than it being closed source. R was too late to the game and catered too much to professional math/stats/datascience people rather than programming generalists. Python (with native code interop) hit the sweet spot for breadth/accessibility to the market and capability.
- IshKebab 5mo agoBecause MATLAB isn't free to use... (Among other reasons, but that's easily the main one.)
- physicsguy 5mo agoMost of the scientific libraries of note originate in academia where MATLAB is effectively free to users. The cross over to Python was well under way by ~2014
- deleted 5mo ago[deleted]
- flakiness 5mo agohttps://mojolang.org/docs/roadmap/#contributing-to-mojo 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 promise. And the 1.0 release would be a great time to deliver this.
- adamnemecek 5mo agoThis is exactly how the open sourcing of Swift went so I imagine it will be the same.
- otabdeveloper4 5mo ago> We're committed to open-sourcing all of Mojo Translated from corporatese it means "it will never happen".
- jlundberg 5mo agoWith Chris Lattners track record, there is little reason to doubt they actually will open source this.
- ModernMech 5mo agoIt’s not Chris Lattner who gets to make the call though. He has investors to the tune of $300 million, and making them happy is the reason it hasn’t been done yet. A lot of people, very reasonably, relieve it’s not possible to satisfy them and also the development community, and when when push comes to shove it’ll be the investors who win because they have the money. So it’s not Chris Lattner’s track record that makes people worried — it’s the track record of investors choosing control over openness, which is a pretty solid record.
- MohamedMabrouk 5mo ago
- sureglymop 5mo agoMojo is cool but I just don't understand the python backwards compat thing. They're holding themselves back with that. All the flaws I can think of in Kotlin are due to the Java compatibility. They could've made it work here by being more explicit but the way it currently works seems doomed.
- tasuki 5mo agoThey coulda made it Scala!
- pjmlp 5mo agoSame story with C and Objective-C, C and C++, JavaScript and TypeScript, Java and Scala, Java and Clojure,..... Yes the underlying platform they based their compatibility on, is the reason they got some design flaws, some more than other. However that compatibility is the reason they won wide adoption in first place.
- geodel 5mo ago> All the flaws I can think of in Kotlin are due to the Java compatibility. All the use of Kotlin in industry are due to Java compatibility. Else there would be ~0% marketshare of Kotlin.
- loglog 5mo agoMojo is NOT Python compatible (although they initially wanted it to be). So they got all downsides without the upsides.
- fiedzia 5mo agoThey claim you can easily mix them so there is some degree of compatibility.
- Conscat 5mo agoEvery reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.
- digdugdirk 5mo agoIt does almost seem like they're trying to recreate the Nim programming language in this regard.
- rao-v 5mo agoI still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we can make such a language … but it’s not caught the fancy of someone who could do it
- JBits 5mo agoIf you're happy with NumPy's API, then surely JAX is exactly what you're looking for.
- rao-v 5mo agoJAX can’t do what Numba can do for example. I just want one way to write simple math-y code like you normally would and automagically convert to run on one of the above approaches. That’s what compilers and high level languages are supposed to be for!
- oldmanhorton 5mo agoBoth ahead of time compilers and JIT compilers often perform autovectorization of tight loops. The problem is that lots of hot loops are not necessarily simple loops, and in particular a lot of source code is written in a way which uses sequential dependencies that can’t be modeled in SIMD code. Aside from undefined behavior in C/C++, most compilers will fail to autovectorize because doing so would very slightly change the behavior of your code in a very hard to understand way.
- rao-v 5mo agoSurely a high level language can own the contract of making sane choices of when to auto vectorize and when not to (or just inefficiently auto vectorize - that is fine too!)
- 5mo ago