Comment by coldtea
1 day 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.
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.
> 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.
This is a false dichotomy.
For years Golang was developed in the open but strictly moved on the vision of its creators rather than being "community-driven". Many other venerable open source projects don't involve the community in serious strategy discussions. The community mainly acts as a bug finder/fixer. Mojo could do the same: be open source but choose its own priorities internally.
I'm guessing that Mojo is still looking for a monetization strategy. Keeping important things proprietary in Mojo at this stage helps I'm sure (nothing wrong with that).
But I feel the era of proprietary programming language play is over. Unless you create some hardware (which the Mojo guys don't) it's going to be tough.
Indeed, this fall 100%
Why didn't you just do this the sqlite way, and open source this, some time ago?
Release the source, but don't take code from external contributors. Take issues and discussion instead
open source does not mean open community. you can just throw tarballs over the wall
This is exactly how the open sourcing of Swift went so I imagine it will be the same.
> We're committed to open-sourcing all of Mojo
Translated from corporatese it means "it will never happen".
With Chris Lattners track record, there is little reason to doubt they actually will open source this.
3 replies →
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...
I 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.
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.
Plus 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
SYCL is the de facto successor to OpenCL that supports higher level languages. So the vision was and is there.
1 reply →
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.
The people that write the libraries care, why do you think Python is where we’re writing ML code and not MATLAB?
Mojo 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.
Because MATLAB isn't free to use...
(Among other reasons, but that's easily the main one.)
1 reply →
I 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.