Mojo can actually create fully standalone binaries, so you don't even need a Mojo install to run them! Also the binaries are really small compared to languages that need a big runtime (e.g. a binary containing the matmul implementation is ~100kb). I'm not sure how long it will take before there's enough ML/DL functionality to write something like fastai in Mojo. I think there will be at least one more major version o…
How does that work given that the binary needs to lug around a CPython binary (unless you want to depend on the OS python)? Also, how does this deal with python libraries?
The binary doesn't need to lug around a CPython binary. Mojo is a compiler that uses MLIR to compile standalone binaries.
(Unless you use `python.import`, which uses the CPython interpreter.)
How does that work given that the binary needs to lug around a CPython binary (unless you want to depend on the OS python)? Also, how does this deal with python libraries?
The binary doesn't need to lug around a CPython binary. Mojo is a compiler that uses MLIR to compile standalone binaries. (Unless you use `python.import`, which uses the CPython interpreter.)
but won't that include most applications for the foreseeable future? I assume no one is going to be rewriting the entire data processing/web stack from python to mojo in the near future, right?
> Julia is far more mature and advanced in many ways. Many folks have and will continue to push Julia forward and we wish them the best, it is a lovely ecosystem and language. There is room for more than one thing! :) In general this tends to be true. However, in this case I'm not so sure. Modular seems to have garnered a lot of investment - probably orders of magnitude more than the Julia community has been able to…
This is too real and any of the great investment of manpower (e.g. Tensorflow for Swift) if happened to Julia would probably be 10x or 100x in terms of ROI -- just look at how few devs and line of code Julia's alternative to pandas/numpy/ML/autodidf/plotting has. If Julia ecosystem can be somewhat competitive while only having part time and researchers' side project contributors, it WILL thrive if properly invested.
Just a thought, but perhaps it's the small community and independent culture of Julia that has led to the high quality of its software. Small groups of highly passionate people can accomplish a lot! If I recall the history correctly, scientific Python (numpy, scipy, etc) developed similarly at first and has mostly supplanted Matlab, Fortran, and other tools. There was a point in time when Python was considered niche and not for "serious" work :).
Hi is there any plan to have high level model training tools (one example is things like Pytorch dataset loaders), or is the focus more on inference/deployment use cases?
If I have anything to do with it, there will be high level model training tools. Perhaps something a little like fastai, for instance?...
This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.
After the 1st JIT-compilation (which here we treat as C++ static compilation), there is no compilation cost. As long as you avoid doing dynamic things (e.g. GC), there's a great case to be made for real time Julia.
Of course, but other than in C++ you need to use ways and means to achieve this - never hitting u compiled code - that are not very natural to Julia. Yes it may be possible to compile Julia code to binaries, but it obviously is neither straightforward nor widely used.
Are you afraid that you're going to "inherit" the issues the python ecosystem has through your goal of full compatibility? Or is Mojo more like Numba, in that only parts of python will actually be supported for full acceleration? At least your docs[1] seem to say so.. -- [1]: https://docs.modular.com/mojo/why-mojo.html#intentional-diff...
Agreed. I think this effort is completely missing the real pain points that ML suffers from. While python the language is easy, and in many ways great for its original purpose as a teaching language, I'll take note of the few ways that Python ML suffers: - pip hell. Really, having globally installed dependencies was great for the 90s and is terrible now that disk space is more or less a non-issue relative to dependen…
I guess their argument is the reason those things suck is because they are hooking in some c++ monstrosity (tensorflow) or making rpcs to an external daemon (redis, horovod).
So rather than writing another Python wrapper over c++ they are making a new performant language that can call Python.
To me it makes sense as torch is great and hard to compete with, but everything feeding into it is a mess today (Data loading, distribution logic).
Nvidia has a ton of lock-in with CUDA. Seems like it could shake up the GPU industry if this takes hold as a standard tool in ML. Also, I'd imagine AMD, Intel, Apple, and others will be lining up at the door to sponsor this project.
What's the question? They are sharp and pointy and Mojo has an unsafe `Pointer` struct vended by the standard library for folks who know what the they are doing.