Earlier quoted context omitted.
To weed out programmers who don't indent.
identation should be something the compiler does not care about
We write for humans, not for compilers.
Mojo 1.0
221–230 of 233 posts
Re: Mojo 1.0
#222Earlier quoted context omitted.
I believe Mojo has been primarily using AI-generated imagery of its mascot for several years now, which politically aligns with its pivot to being a language for AI development.
I wouldn't say there was a pivot, AI development has explicitly been the goal since launch.
Oh, gotcha. I thought I recalled reading early material that emphasized the flexibility of Mojo emitting MLIR for many tasks, but it's possible that that was either pre-launch, or that I got confused when reading about MLIR itself.
Re: Mojo 1.0
#223Earlier quoted context omitted.
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…
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.
> its culture is not very collaborative.
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.
Re: Mojo 1.0
#224AI 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.
I know right? Would be better to have a banner with the language logo than some totally out of place aislop image, almost makes you think this is a random person's blog and not the official Mojo site
Almost? That's exactly what it did! At first I thought this was some bozo's toylang mysteriously on the front page of HN garnished with a wall of LLM technobabble.
Re: Mojo 1.0
#225What in the world would posses the modular team to attach those horrendous AI generated thumbnails to each blog post? It makes it feel cheap, even though I know the project has some really serious technical expertise behind it.
Ssssh, don't tell them.
"AI slop image below the headline" is an unmistakable mark of low-quality content written by a sophomoric AI evangelist. Let them keep watermarking their own content.
Re: Mojo 1.0
#226Earlier quoted context omitted.
lol no
it's legitimately among the best languages for writing GPU kernels
As someone who writes GPU kernels in Julia, yes it is. But Mojo is one of the few alternatives based on technical merit alone. Each language is better in different metrics, and it could be argued either way.
License-wise, Mojo reminds me of paid Borland compilers that were in vogue before I was born. Even if it's open-sourced, what incentive does Qualcomm have to maintain a happy path for Metal deployment? Mojo might actually be the best way to program Apple GPUs (on a technical level) and it would still lose due to politics.
Re: Mojo 1.0
#227Earlier quoted context omitted.
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.
> its culture is not very collaborative. 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…
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?
Re: Mojo 1.0
#228Earlier quoted context omitted.
Yeah, feels kind of odd to phrase it like that when he's already created more than one world famous compiler before this one.
TBF, he has done more than his fair share of time working in BigTech.
Sure, but that doesn't mean he made billions before!
Re: Mojo 1.0
#229AI 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.
"Normal" keeps getting more and more depressing. Did they think that image would make them look fun or interesting? Because it's exactly the opposite.
These AI illustrations are the nee "corporate Memphis." Images of flat, minimalist people in bold colors used to be the sign that whatever text accompanied them was low-value drivel. Nowadays, I associate the same with AI generated imagery. I'm not sure why the folks doing the writing (if, indeed, any of the writing was done by a human) don't seem to clock this when the audience seems to be able to catch on almost immediately.
Re: Mojo 1.0
#230AI 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.
> I guess that's the new normal. Yes, so basing confidence on it is totally bogus. Such comments are cheap and add nothing to the discussion of Mojo reaching 1.0 status.
Well, not really; people have long ignored overly corporate or low-effort news releases because. The presence of certain language or stock images is a signal (and I would argue a valid one) that the rest of the content is equally low-effort and not worthy of attention. AI images are just the newest version of that signal. I think it behooves the writers of these blog posts/news releases/community updates/etc. to reflect on why they continue to include these signals that their content is low-effort or low-value if they actually want their audience to read it.
Unless the idea is that, in 2026, you assume your audience is an LLM that is ingesting and summarizing your content for the end user and that no human will actually read what you wrote so you don't actually need to care about signals of quality or trustworthiness. The AI generated illustration seems kind of superfluous if that's the case, though.