I recently wrote about Max and Mojo being bundled together, and I wanted to ask a follow-up question here since the thread has been locked.
I’m very happy about the license change; it makes things much clearer. Thanks, @clattner and the Mojo team!
Now that the license question is out of the way, I’m still wondering about the bundling of Mojo and Max.
Max is ~1GB in size and it’s only gonna get bigger as more hardware is supported, it includes code and libraries that in many cases, might not be relevant or wanted, such as mojo-jupyter, max-core etc…
Lets take one example. I want to develop a library for a robotics project where performance is key, so instead of creating that lib in Python, I decide to do it in Mojo and expose its API so that the users of my lib can call it both from Mojo and Python (as I understand it, upcoming Mojo releases will allow it). Now, this lib doesn’t need max-pipeline, or the jupyter extension or the whole “inference engine” basically (the user of my lib might want to use it with Python and Pytorch, no Modular tools involved, for example).
If I want to ship my lib as a compiled conda package for example, that is accessible to Python projects and keep the lib as lightweight as possible, how am I supposed to do that, considering that Mojo is bundled with Max?
Thanks!
Maybe when the compiler is open source the community can provide a different packaging and distribution, similar to what you have in the Vs Code and Java communities.
I suspect Modular will always package their entire suite together
Hi there,
We’ll continue to evaluate packaging over time (and have a new pip-based installer coming soon btw) but we’d like to keep things simple and consistent for the immediate future to make sure everything lines up and is easy to manage.
That said, let me challenge some of your assumptions :-). You’re right that MAX is about 1G in size, but not right about the direction: we’re actively working on shrinking that further. It has a bunch of dependencies in the package that increase its size unnecessarily, and we’ll grind away on those. I don’t have a clear sense of what the size will end up being, but it will be quite a bit smaller.
Also, adding support for new hardware will not significantly increase the size of the package due to the way that Mojo works and the way that we’ve built the framework.
-Chris
5 Likes
Got it, I can’t wait to see the pip installer.
Thanks @clattner !
I also wanted to jump on the occasion to share my feedback: I keep coming back to Mojo because I really want to use it for my next project, but every time I try, there is still a “little something” that prevents me from going all-in.
I keep comparing it to Zig, for instance. Returning to the lib example I gave above, if I do it in Zig, I can easily publish it with an interface in C/C++ and Python, while embedding everything in a single file. Doing the same thing with the Modular suite doesn’t seem as obvious, also because a few basic things are not yet available in the Modular suite, like Networking (it has to be borrowed from Python). My dream is for Mojo to become my go-to language to “do it all”, not just GPU programming (otherwise it essentially just becomes a replacement for CUDA programming that works on more hardware and nothing else).
Totally, I’m with you there. We’re building into this one step at a time - building a full self-sufficient language and community takes time. In the meantime, it’s super pragmatic to lean on Python and C and other languages for their existing ecosystem.
1 Like
Depending on what level you want Networking at, and whether you’re willing to use Linux, GitHub - dmitry-salin/io_uring: The io_uring library for Mojo might be a good option for you. It jumps the API you’re using directly to the state of the art for kernel networking (kernel bypass has some extra tricks that can make it much faster). The interface isn’t horrible, but it is an adjustment from BSD sockets.
It might need some updates since a lot of the people interested in networking are waiting for the async model to materialize and for some more type system work before we get going on trying to make a “nice to use” networking library, and as a result some of the bindings have a bit of bit rot since their authors are waiting for language features to be able to express newer features properly.
2 Likes