Palm has entered the chat: https://www.palminfocenter.com/news/6823/palm-webos-mojo-sdk...
Mojo – a new programming language for AI developers
131–140 of 272 posts
Re: Mojo – a new programming language for AI developers
#132There are a bunch of questions about Julia, so I'll do my best to give a short answer to a very long and complicated topic. Up front, Julia is a wonderful language and a wonderful community, I am a super fan. That said, Mojo is a completely different thing. It is aligned with the Python community to solve specific problems outlined here: https://docs.modular.com/mojo/why-mojo.html Mojo also has a bunch of technical a…
>Python has amazing strengths as a glue layer, and low-level bindings to C and C++ allow building libraries in C, C++ and many other languages with better performance characteristics. This is what has enabled things like numpy, TensorFlow and PyTorch and a vast number of other libraries in the ecosystem. Unfortunately, while this approach is an effective way to building high performance Python libraries, its approach…
I believe they are thinking about the cost of building the next NumPy/PyTorch/TensorFlow.
Re: Mojo – a new programming language for AI developers
#133This looks exciting, and I'm looking forward to its progress. I have questions about GPU infrastructure in particular. It seems like the GPU backend is primarily through MLIR. Does that target CUDA? Vulkan compute shaders? WebGPU? Metal shaders? I note that IREE has the first three of those listed as targets, but am not clear on exactly where that fits in to the rest of the ecosystem.
I have an idea of a dream GPU infrastructure based on compute shaders, where you compile your problem into GPU IR suitable for your operating system (SPIR-V, Metal, DXIL) and have a very lightweight runtime that just runs those. For the ahead of time compilation case, you wouldn't need to ship GPU compilers in a deployed application, though you would want that for more rapid iteration when doing research and exploratory programming.
From what I can see so far, this seems basically orthogonal to what Modular and Mojo are trying to do, but it's entirely possible I'm missing something. I'm wondering if anyone is actually building this (IREE and MediaPipe are the closest things in the space I'm aware of), and if not, why not.
Re: Mojo – a new programming language for AI developers
#134Earlier quoted context omitted.
>> If this succeeds, it will allow you to use Python for the entire AI stack [...] If this succeeds, the terminal endpoint will be the Python Software Foundation adopting Modular as the defacto and eventually official implementation since, as Modular noted in their docs, they effectively need Mojo to be absolutely amazing on generalized host CPUs as the key enabler allowing for the unified Python-superset experience…
No it won't. The language is not a super-set of Python, its another language that somewhat resembles Python. You can't drop in some Python code and run it with Mojo and expect it to work.
I think this discussion is a bit better if you read the docs:
>We utilize CPython to run all existing Python3 code “out of the box” without modification
Re: Mojo – a new programming language for AI developers
#135Earlier quoted context omitted.
The goal is for the language to be a superset of Python > Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (i.e. be compatible with existing programs) and to embrace the CPython immediately for long-tail ecosystem enablement. https://docs.modular.com/mojo/why-mojo.html
But see the section "Intentional differences from Python", which is after your quote, https://docs.modular.com/mojo/why-mojo.html#intentional-diff... > our approach to compatibility is two fold: > 1. We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem. > 2. We will provide a mechanical migrator that…
Isn't
>We utilize CPython to run all existing Python3 code “out of the box” without modification
from the docs the direct opposite of what the commentator claimed?
Re: Mojo – a new programming language for AI developers
#136Why would I use this over Nim?
From what I can tell:
1. They have a REPL and Jupyter integration
2. They're planning to do C and C++ interop. This is achievable in Nim but it is a pain, i.e. there is not easy way to import/include a C header in Nim, e.g. nothing as straight-forward as @cImport("cheader.h") in Zig or #include "cheader.h" in C++; one must go through c2nim or a third-party library
(1) cannot be achieved without a custom linker or using a JIT such as LLVM or compiling to WASM and embedding a WASM runtime into the binary
I really hope Nim gets some language/compiler upgrades due to this.
Re: Mojo – a new programming language for AI developers
#137Earlier quoted context omitted.
The source code is Python (well, a superset of Python), but it's not interpreted and run by the official Python interpreter. Judging by what I've seen so far, it seems Modular has been able to "Rustify+Tritonify" Python code in a way that to me feels... very Pythonic.
Maybe someone can correct me, but I don't think it's a superset of Python--I don't think it will accept existing Python programs and I'm pretty sure you can't do all of the dynamic Python stuff (otherwise you would have to essentially compile/link an interpreter into your binaries giving you these super slow paths that aren't necessarily obvious when reading source code). > Judging by what I've seen so far, it seems…
>We utilize CPython to run all existing Python3 code “out of the box” without modification
>Further, we decided that the right long-term goal for Mojo is to provide a superset of Python
Re: Mojo – a new programming language for AI developers
#138I wish new languages would move away from python syntax and semantics and just do their own thing more.
I wish more would take inspiration from Python syntax.
Re: Mojo – a new programming language for AI developers
#139Earlier quoted context omitted.
>Python has amazing strengths as a glue layer, and low-level bindings to C and C++ allow building libraries in C, C++ and many other languages with better performance characteristics. This is what has enabled things like numpy, TensorFlow and PyTorch and a vast number of other libraries in the ecosystem. Unfortunately, while this approach is an effective way to building high performance Python libraries, its approach…
I believe they are thinking about the cost of building the next NumPy/PyTorch/TensorFlow.
PyTorch supports fusion and CPU/GPU codegen, https://towardsdatascience.com/how-pytorch-2-0-accelerates-d...
Taichi already allows for amazing speedups and supports all the backends (including Metal) https://www.taichi-lang.org/ the fact that they didn't mention Taichi is a glaring omission.
JAX is that next version of TensorFlow, https://jax.readthedocs.io/en/latest/notebooks/quickstart.ht...
This looks like a reboot of Numba with more resources devoted to it. Or a juiced up Shedskin. https://shedskin.github.io/
I think Mojo is a minor mistake, I would caution adoption, it is a superset fork of Python instead of a being a performance subset. Subsets always decay back to the host language. Supersets fork the base language. I would rather see Mojo integrated into Python rather than adopting the language and extending.
I have a theory why Mojo exists. The team was reading a lot of PyTorch and Tensorflow, getting frustrated with what a PIA working with C++ and MLIR is for their model-backend retargeting codegen, so they created their perfect C++/Python mashup rather than use TVM. They nerd sniped themselves and rather than just use Python3.12+mypy, they made a whole new language based off of Python.
Re: Mojo – a new programming language for AI developers
#140Earlier quoted context omitted.
Matlab existed for a reason, and has since become irrelevant, in particular in the face of python being used as a more flexible open source scientific computing scripting language. If this is closed source, it's already as irrelevant as matlab so no reason to fight it. If there are useful bits there will be python versions of them.
> Matlab existed for a reason, and has since become irrelevant My man I wish this was true. I am not exaggerating the 10+ year thing, there are very important industries being run today on MATLAB. You remember the moment when you learned that a lot of wall street runs on excel? This is the moment you learn a lot of silicon manufacturing runs on MATLAB. An obscene amount.
Silicon manufacturing, aerospace, automotive, robotics, the list goes on. It’s a well-entrenched ecosystem that makes a decent chunk of cash and has a lot of staying power. Simulink seems like a major factor in this staying power.