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 agents wasn't great timing.
> "Qualcomm to Acquire Modular"
That's linked from their news section. If I read between the lines here what happened is the VC money ran out and they arranged some kind of acquihire. That obviously raises a lot of questions about what will happen to Mojo and the intentions around it. The merger was completed a few weeks ago so apparently this is a done deal. Them wrapping a ribbon around the 1.0 a few weeks later is a bit suggestive.
The modular front page reads like it was trying to pitch the whole thing as a competitor to other inference platforms like open router, replicate, bedrock, etc.
I'm sure there's more to it and that the tech was amazing. But the acquisition raises a lot of questions about the future of the whole thing. An OSS move at least would allow people to continue working on Mojo independently from Qualcomm. I assume some people in the team might be moving on post acquisition.
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...
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.
I felt the same way, even after browsing around on the website, and somehow I got to https://mojolang.org/docs/manual/quickstart/, which brings you to mojolang.org instead, which is the real website of the language it seems, instead of "Modular" which I guess is the business.
https://mojolang.org is a lot better as a introduction to the language for a programmer, at least for me, compared to whatever I could find on the modular.com website.
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime in the realm of Zig, rich type system, first class SIMD support, etc.
Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig.
Very excited for Mojo once it's open sourced later this year.
> LLVM is still involved, but they are using it differently than say, Rust or Zig.
Chris Lattner said in a Developer Voices podcast interview:
"Swift in a way was syntactic sugar for LLVM, at the very bottom of the stack it could talk directly to LLVM primitives. Mojo does basically that same trick, but it supercharges it by moving to this MLIR world."
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 languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving.
Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
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.
Well, LLVM itself is still single-threaded; they just designed Mojo's compiler in such a way that the code generation part can be parallelised, which is something you can do if you understand LLVM from top to bottom. As far as I can see, no other production-grade LLVM consumer has been able to make it parallel; the single-threaded nature remains a major performance bottleneck.
> Modular found ways to parralize LLVM code generation by introducing novel techniques
> The novelty is in parrelizing LLVM, which is traditionally a single-thread code generator.
You said they parallelized LLVM with novel techniques, but then claimed the novelty is the very act of parallelizing it. That's circular, you still haven't explained what are the novel techniques?
Here is a presentation talking about the parallelization techniques, I skipped to the relevant part but the entire presentation is helpful in understanding how Mojo's compiler works: https://youtu.be/yuSBEXkjfEA?t=813&si=MlB7IsBDsj3o-PTX
From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.
Mojo compiles with O2 by default, it is similar to Go here. Release build is the default, debug is something you opt into. It is still very fast nonetheless
It's supposed to be (currently) a fully native, Python-like language, but for GPUs primarily. Though I am seeing it as having a future as a fully native Python alternative that might get interesting.
I hope with 1.0 (havent fully read the article yet) they stop breaking language features / syntax because they did quite a few different changes over time, their overall goal is to be a fully native superset of Python.
I do see this one overtaking Nim over time, which kind of saddens me, because I like Nim for what it is, but Mojo trying to be a superset of Python is a no-brainer for most Python developers. Reminds me of how a lot of Go devs were former Python devs not C++.
> their overall goal is to be a fully native superset of Python
Not any more. That was the initial announcement, but I think then somebody actually looked at Python and realised what a complex language it is - so they refocused on being a Python-like language. Python has a reputation for being a simple language, but in reality it isn’t at all.
Honestly that doesn't really feel like a glowing endorsement of the language. "They announced a crazy goal, then rolled it back because they grossly underestimated how hard it was" doesn't give me confidence in either the long-term design or the people making it, and I feel like "a Python-like language" is both a lot less interesting and a lot more subjective. If the discussions in this thread around significant whitespace aren't already an indication, which parts of Python people think are good and which aren't will vary by person, so without saying more it's hard to tell whether it's a a language someone will love or hate.
To preempt all of the inevitable responses: yes, I'm aware that this was started by the same guy who started LLVM and Swift. That doesn't automatically mean anything he comes up with will be great, especially when it's specifically trying to be "like" a language that doesn't really have much on common with either of those; there are plenty of instances of very smart people having an overabundance of confidence when jumping into something they assume they'll excel at and getting humbled. I'd also argue both Swift and LLVM have some common criticisms that very much are in line with the same concern I've expressed here (i.e. long term design suffering due to expanded or pivoted scope; even the name LLVM alludes to some of that history of having a somewhat different goal originally). His name is enough that I'll probably always click to take a first look at anything he comes up with, but I'm not going to ignore things that seem like issues because of that either. Smart people don't need to held to a lower standard because their work should be able to speak for itself.
That is a mistake. Being fully compatible with Python was a big selling point. Now they are just another knock off that wont get enough traction to make a dent. Unless this GPU programming thing is so amazing it takes over the industry with one small niche feature, guess that is the hope.
Language-feature-wise it seems like Nim will be competitive. Ecosystem-wise… yeah it's kind of a nonstarter over in Nim land. There are not many go-to libraries and its culture is not very collaborative. People seem more enamored at what they can hack together than what they can contribute to.
Second this. Their BDFL's personality is not suited for the job IMHO.
Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:
- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible
- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.
I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.
What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.
Andreas is simultaneously brilliant and myopic to needs outside of his own (compiler dev).
It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.
Has OrderedTable been ported to Nimony? Does it still have this bug?
OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an item from a single-threaded sorted list: most painful to remove the 1st element, least painful to remove the last element, but then you still have to rehash the entire table.
Part of that is because there isn’t yet a package format and a central repository. I have a few libraries I would like to contribute or merge with similar projects.
For sure, those things would go a distance towards making it a more competitive language.
Why haven't they happened yet though...? Nim is not a young language. Leadership [Andreas] doesn't think they are more important than spending time adding another memory management option.
I don't know what @winding means, exactly, but at best this seems highly misleading. Nim had babel packages by around 2010 (when it was called Nimrod and there was a Tower of Babel name scheme) and then nimble packages since 2014 or so. Also, literally 30 seconds on https://nim-lang.org (click on Documentation) and you get to https://nimble.directory/ , search for index and get to adix which has all sorts of efficient Table variants.
There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say). The benefit is more "software distribution" for the dependency allergic, but the Nim culture is much less micro-deps than seems in vogue lately. All that said, I think having a more batteries core distribution is valuable - just less than you might guess - and practically that needs delegation.
And knowing the magic keyword search `adix` to arrive at a prerelease library that you yourself wrote. That not's exactly an endorsement for discoverability. Unless I'm missing something, Nimble is essentially stateless. You have no sense of how many times or how recently a library has been downloaded. These are important proxies.
> There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say) … more batteries core distribution is valuable - just less than you might guess
Yeah, I don't think this is the community's strong suit. It strikes me that Araq is tired of explaining himself (but doesn't care to consolidate discussion into ADRs), so when a well-meaning, would be contributor like the parent-poster comes along they get shot down and we lose them.
I only said anything at all because the implication was not "missing minor nits about whatever your favorite proxy for 'will rely' is" but rather "nothing at all". FWIW, the keyword was "index" and the result was adix, and I only meant the package system & "a" directory were discoverable. Exact keyword search systems indeed make discovery harder, but that is some whole other complaint. There are always many complaints.
There are a million ways to define both "top 10 language" and "weak std lib", but the C stdlib is not great and C++'s was bad enough to spawn Boost. And I'm sure many firms all but say "do not use" parts of many top10 stdlibs. In any event, we don't disagree that Nim's stdlib being stronger would be better or that poor delegation or unconsolidated discussion are problems. We disagree on very little, including I'm sure that there is more to a PLang than its stdlib.
What is present/missing in any stdlib (or really in almost anything period) is also often much more subtle and subjective than simple sales pitches one hears. To be concrete, there are "useful" (to someone) things in the Nim stdlib not in either Python's or Go's like std/critbits, std/pegs, ropes, packedsets, intsets, editdistance, etc. Nim stdlib substring search behind "xyz".find() is layered to let you, if you want, pre-build a `SkipTable` (the way regex engines let you pre-"compile" regexes). Subtle in diversity of both kind and granularity and subjective as in "who cares?"
Yes, all that and more is all available in all the ecosystems of anything "popular", but that brings you back to "trust proxies", like "prerelease" numbers, a very weak one, IMO. E.g., I have never used a neovim with a version >0.13, but it's been a trooper; one man's 0.7 is another's 7.0. TRUST IS TRICKY! A count of distinct reliers for some values of "distinct" and "rely" or various update patterns would be better (have their own issues, of course, but at least measures "company" as in "what misery loves", LOL).
Whoever behind the company communication have done an incredibly terrible job. They start with an extremely unnecessary polished Steve-Jobs-alike debut video when they have zero stuff to offer, while the founder name is already immensely trustworthy. Then follow with a very ugly AI-image-heavy website and blog posts, only to be reverted back to plain website later.
I'd love the language and platform be succesful, nevertheless.
Ok, yes, this is a substantially better entry point to the language than anything I found by clicking around - maybe link it prominently from the main page?
I was on both. I honestly don't think mojo.lang.org is much clearer - the front page says "GPU kernels + Python + metaprogramming", and the last of those is something Python already has out of the box. The QuickStart doesn't seem to introduce any novel features of the language either.
To be fair, a good bit of the apps/programs/projects posted on hacker news could use a good '1-pager overview'. Like has nobody every explained the 'elevator pitch'. A little marketing doesn't mean you are selling out. Obfuscating your product doesn't make you hip.
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.
For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).
Whenever people stop creating new language with significant indentation. I don't complain about it in Python but I hate when this bad idea is introduced in more places.
I like significant invitation, but I still wouldn’t choose it if I was designing a language today.
Functional-style programming has become much more popular since Python was designed in the 1990s, and there doesn’t seem to be a good way to have Python-like significant indentation and also support true anonymous functions.
Haskell's significant indentation is, in my experience, much worse than Python's at fading into the background by matching what you would have done anyway.
As I understand it, Mojo’s goal is to be able to match state of the art performance for parallel algorithms and be able to use the exotic GPU hardware. A functional style is not necessarily productive in that context.
Like with array base indexes, there are plenty of languages that start with something other than zero, and many that use indentation, including a few well known in hacker circles, Python isn't alone.
Every python developer I know uses an auto formatter today, and never needs to think about it (ruff, black). It's not ambiguous and is immediately visible if something has the wrong indent.
(On other projects, I often wish other languages had formatters as good and standard as the Python ecosystem. I have many complaints about Python but whitespace is just not a problem I've seen)
You missed the point. I’m well aware python has formatters, I use them and implemented my own. The point was that when generating/manipulating python code you cannot just generate in whatever format then run a formatter. you need to carefully keep track of the exact indentation at place where the code in written
Fair. That is a very slight friction on what is quite a small niche, though (compared to the wider ecosystem of developers). And most that need similar will use AST or runtime construction.
The trivial kind of raw source generation is still trivial, but I'm guessing you're doing embedding/templates or something?
If I were doing this, and the code generator was itself in Python, I'd probably use ast and/or tokenize to avoid having to manipulate literal whitespace.
Python's significant indentation does have real costs, but they mostly don't affect experienced programmers working on real codebases in real editors or IDEs. Rather, they are things like, it makes the REPL more cumbersome, and newbies sometimes find that code they copy-paste from the Web mysteriously fails to work.
Have you never tried to paste python code from the internet into an editor? At least half the time the indentation is screwed up and I have to go in and figure out manually where to put the spaces in. Indentation gets screwed up by pasting in other languages too, but with those I can generally tell the editor to reindent and it can because the information is included in the source code.
I've tried them all - vim, emacs, vscode, etc. They all fail in this regard not because of themselves but because significant whitespace is a terrible idea which nearly every programming language avoids.
I mean, it feels like "Python, but aiming at a completely different vertical that values native compilation and a borrow checker"? Which is not quite the same thing
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