I feel like this language would really benefit from some sort of 1-pager overview. I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
Mojo 1.0
181–190 of 197 posts
Re: Mojo 1.0
#182Mojo may be interesting to me, but they should really split it from Max, which is some closed stuff I'm not interested in. They should show some performance comparisions between PyTorch and Mojo, PyTorch+kernel compilation + Triton vs Mojo, ThunderKittens vs Mojo.
They kind of did. It has a separate website now [1] . All the docs, announcements, roadmap, some comparisons as you asked are there. So they do seem to be working towards separation. 1. https://mojolang.org/
LLVM has such a cool tutorial, eventhough I haven't written a programming language myself, it was excitung to go through it to see how static programming languages are lowered to SSA form.
Mojo should have something showing how to write a super fast matmul and especially what's interesting for me is a fast linear attention kernel, as that's where PyTorch is getting much harder to use.
Re: Mojo 1.0
#183I feel like this language would really benefit from some sort of 1-pager overview. I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
Their communication definitely needs work. I listened to the interview with Chris on the Lex Friedman podcast a few years ago. Back when the pitch still was "minimal python superset that allows us to make it go voom". It wasn't a bad pitch. But it's gotten a lot murkier since then apparently. And obviously pitching a new language just before world plus dog was about to switch to delegating programming work to AI agen…
And the main use of the language (and justification for the VC money) was always the engine built with it, which I have absolutely no opinion on.
Honestly, the promise of the language is immense. Ownership semantics that have much better ergonomics and are much more teachable than Rusts, and eventually a relatively smooth teaching path from Python to Mojo would make Mojo a default first modern low level language for many people coming in. Whether this will be relevant in the LLM world we live in now, where you can just take your Python prototype and have it be rewritten in Rust, who knows...
Re: Mojo 1.0
#184Earlier quoted context omitted.
Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig. Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other language…
> Modular found ways to parralize LLVM code generation by introducing novel techniques What techniques?
Re: Mojo 1.0
#185Earlier quoted context omitted.
Their communication definitely needs work. I listened to the interview with Chris on the Lex Friedman podcast a few years ago. Back when the pitch still was "minimal python superset that allows us to make it go voom". It wasn't a bad pitch. But it's gotten a lot murkier since then apparently. And obviously pitching a new language just before world plus dog was about to switch to delegating programming work to AI agen…
The Python tie in was always a sales pitch. The technical pitch was "a language built around MLIR taking all the lessons learned by Rust and Swift on board, with an eye towards Python interop". There were MLIR intrinsics and extensive discussions of the ownership model from the start, but never even an attempt to have classes. And the main use of the language (and justification for the VC money) was always the engine…
The evolution of iPaaS low coding tools.
Just like you can take some high level code in a dynamic language and expect the JIT compiler to do the best every time, under completly different execution patterns, so will LLM based development eventually become like that.
COBOL is already laughing at the efforts to write so much English text to keep AI on track.
Re: Mojo 1.0
#186AI generated first image does not give me much confidence. Lastest OpenCV 5 release notes also had a lot of LLMisms. I guess that's the new normal. Still, I am very hopeful for Mojo.
Re: Mojo 1.0
#187I feel like this language would really benefit from some sort of 1-pager overview. I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages
https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...
Re: Mojo 1.0
#188Earlier quoted context omitted.
> Modular found ways to parralize LLVM code generation by introducing novel techniques What techniques?
I think they had a good dive here https://www.youtube.com/watch?v=SEwTjZvy8vw The gist is that MLIR (unlike LLVM) was designed to be multithreaded so the whole stack above LLVM IR is parallel, and then LLVM is used as a per-function codegen tool in parallel, so although LLVM itself is single threaded there are multiple seperate contexts of it. also I think they wrote their own linker.
https://www.research-collection.ethz.ch/entities/publication...
C# compiler is also fully multithreaded since the Roslyn rewrite in 2016.
Re: Mojo 1.0
#189Re: Mojo 1.0
#190From Mojo Wikipedia article: ``` The intention behind Mojo is to bridge the gap between Python’s ease of use and the fast performance required for cutting-edge AI applications. ``` Basically, same raison d'etre as that of Julia.