Live data from Hacker News

Mojo 1.0

modular.com

181–190 of 197 posts

Re: Mojo 1.0

#181

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

I think they wrote an internal memo and by mistake they share with the public. I read because one person I know works there, now I don't know what my friend does there either. Sounds like another VC eating company.

Re: Mojo 1.0

#182
post #74

Mojo 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/

Thanks, it's so boring and disappointing.

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

#183

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

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 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

#184

Earlier 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?

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.

Re: Mojo 1.0

#185

Earlier 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…

I am already using agentic orchestration tools where the language is irrelevant, e.g. Opal, Workato, Boomi.

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

#186

AI 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.

A lot of software engineers don't have a good feel for this kind of aesthetics or social outcomes. They're playing with their new toy (which is very exciting, let's not ignore that), they're happy it does stuff, but ignore that it can be perceived as ugly and cheap by others. As well as totally bland - every other cheap company is using it too.

Re: Mojo 1.0

#187

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

This page really helped me to put it into perspective against Python:

https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...

Re: Mojo 1.0

#188

Earlier 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.

That is hardly novel, here is the thesis for the Oberon multithreaded compiler from 2003.

https://www.research-collection.ethz.ch/entities/publication...

C# compiler is also fully multithreaded since the Roslyn rewrite in 2016.

Re: Mojo 1.0

#190
post #170

From 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.

The design and intellectual heritage of Julia and Mojo couldn't be more different though. Mojo is a Swift/Rust style language from industry veterans, Julia is a Lisp built to make academics write faster code.
Post reply on HN