The article title is misleading. It is not that Rust compiler was not able to optimize some low-level operations. Rather the author came up with encoding schema that fit most things the interpreter dealt with into 64 bit. This replaced the previous schema that used 128 bit for everything but that can be directly mapped into Rust enums. The catch was that it was necessary to allocate some things on the heap and use pointer indirection but that was used for rare values so on average the new schema provided nice win.
One cannot expect a compiler to come up with such encoding.
> One cannot expect a compiler to come up with such encoding.
One could, however, imagine a sufficiently expressive language that allows the developer to specify the encoding schema without resorting to raw 64-bit words.
This breaks the language. Do you want safety or do you want expression?
What is misleading about the title? A custom encoding scheme is exactly what it suggests. Maybe it has been edited since your comment was posted?
It wasn’t replacing one rust enum, it was replacing what are effectively multiple enums
How so? It's replacing multiple enum variants, but just one enum, "enum Value".
(also; if anything, the title is implying the exact opposite of "Rust compiler was able to optimize ...", "Replacing a Rust [...] with [...]" is clearly moving away from Rust-magic to something else)
Probably in the sense that you can remove the word rust and nothing changes. It's not about some failure of rust to be efficient at enums, but the title says it is.
OP here: I think you're reading too much into the title. It's not about the failure of Rust. It's about where I stepped in with some custom optimizations for better performance. If you read the blog post, the solution implemented is very Rust-y as well. It uses a newtype with custom methods to try and make the code as nice and readable as possible.
FWIW this post was very well received on the Rust subreddit. They loved it and it got over 350 upvotes, so that community definitely didn't receive it as some sort of attack on Rust.
I think you're reading too much into the title.
I don't think it's fair to write a misleading title then tell people "they're reading too much into it".
Implying one thing then walking it back in the article or having the article be about something totally different, then saying people should read the article and not pay attention to the title is just manipulative to your audience.
The problem is that there isn't anything misleading about the title. It is well understood that creative packing of data can provide optimizations under certain circumstances. Nobody should have reason to think otherwise. The title quite accurately captures what the rest of the article is about as well as any title possible can.
What appears to be happening as we see in several comments is that some users cannot find any technical reason to use Rust so they rely on a belief that it is somehow magically perfect to justify using it and and the idea that it hasn't perfectly found some creative packing solution, despite the rest of us wondering why one would expect any compiler to – it not really being its job, is felt as an attack on their use of Rust. Someone developing irrational feelings towards an inanimate tool isn't on the article's author.
What's misleading about the title is that the title implies something about rust, while the content does not.
Like I said in the first place, you can remove the word rust, and nothing changes. That's how you know what's wrong.
It's like a news report saying "black man caught embezzeling". It might be a fact, but it's an irrelevant fact, and it begs the question why it was pointed out. He was probably also a vegetarian, Jewish, a bird watcher, an uncle...
And it's not that there is some weird rule that you have to avoid saying black or rust or whatever. It's simply that if you say something, then the _only_ reasonable way to interpret it is that there was some reason to say it.
You state an equation or give a list of items, it is irrational to assume anything other than that all of the terms or items are relevant.
In this case, rust is just the language being used, which is happenstance. It doesn't matter what language was used. You don't have to go out of your way to hide the language or any silly suggestion like that, but reading the title alone says that there is something about rust and enums. There only 3 items in the title, rust, enum, 64bit word. You can't fault anyone for defaulting to the conclusion that rust, enum, and 64bit word are the essential concepts that will be discussed.
The article isn't bad, and frankly the title isn't even so bad as to be a moral failing or anything. They ARE happening to be working in rust while developing this optimization.
It's simply that it's also entirely correct and reasonable to read the title as saying the words that it says. And the title says something that the content does not.
Right, Rust tells us something important: How the data was packed pre-optimization. This is useful information as, at least those with some familiarity with Rust, will have an understanding of what is being replaced.
You wouldn't be able to reasonably use something like "Replacing an Enum with ..." because, especially where enum in Rust means what other languages call sum types, the data representation can be anything. But even the more traditional use of enum isn't defined by any particular data representation. The whole point of an enum is that any value used in implementation is treated as being opaque! Whereas in this case the value is significant.
I mean, you wouldn't be able to no more than you could replace the title with "Hey you, yes you, read this". Which obviously you could do. But it would be a poor title as you wouldn't be able to figure out what the article is about. This title is great because you can predict exactly what the article is about before reading it. I'd even go as far as to say that this is one of the better titles I've seen on HN in a long time.
Granted, it does require technical familiarity to be able to grok it. I can appreciate those who have developed irrational feelings for an inanimate tool aren't coming with a very strong technical background, but who cares about them? The intended audience is clearly technical folk.
For whatever it's worth, I read zero negativity about Rust in the title or content.
I have no idea what you are trying to comment on. Nothing I said.
Changing the title to "hey you" is a ridiculous meaningless idea that does not relate in any way to "you can remove the word rust and nothing changes". I can only assume you simply don't know how to read, and so there can be no possibility of communication. It was not an obscure indecipherable construction, and your inability to understand it is yours alone.
You fabricate this idea that I have some feeling about rust, and then base a bunch of weird arguments on that invented idea. I neither like nor dislike rust. It's a piece of tech that seems to be functional enough for some tasks. The entire point was that it has no bearing at all, positive or negative. But that is somehow defending a sacred cow?
You're arguing about things no one is saying.
> Changing the title to "hey you" is a ridiculous meaningless idea that does not relate in any way to "you can remove the word rust and nothing changes".
It totally relates. If you remove 'Rust' then you cannot decipher the title. Rust has a known packing scheme when using enums, which is significant when replacing that packing scheme with a creative alternative. 'Enum' alone does not. Again, the whole idea behind an enum construct is to make any implementation values opaque! Any values used in a particular implementation are implementation dependent. As explained before, if you keep the implementation you are talking about a secret then the words become no more useful than "hey you...". The starting point is central to the story about a performance optimization being gained. One must be able to understand what the starting point is in order to extract anything useful from learning about the destination.
> You fabricate this idea that I have some feeling about rust
Whatever do you mean? The bit about feelings was clearly in reference to the earlier comment that spoke to even earlier comments that had nothing to do with you. It's a big world out there. What makes you so sure it revolves around you?
If you replaced it with Zig, the situation changes.
'Enum' is ill-defined so the addition of Rust is significant as it indicates what one can expect with how data is structured. There is nothing in that speaks to the Rust compiler or Rust being inefficient or anything of the sort. It remains unclear where this idea is coming from. There is nothing in title that would send you there.
Unless, again, the title was edited at some point?
I'd actually point at the other half of the title than the existing comment when being pedantic "Replacing [...] with a 64-Bit Word" isn't quite right, it was replaced with a manually packed 64-Bit Word and the occasional heap allocation.
I'm not sure being this pedantic is particularly useful in titles though...
It's worth calling out either way. It's not just an encoding scheme, it's a reasonably significant change in architecture.
When I think of how a "compiler" could make these optimizations, I think the right place is an optimizing LLM (so, just a regular coding agent that you prompted to find optimizations like this one), making the changes in source at the request of the developer. That provides the dev with adequate input on whether they would like to opt-in to an unsafe optimization like this one. The compiler can continue to do deterministically-safe optimizations.
That seems like a horrible idea:
1. Do you really want the rust compiler to run at the speed of an llm?
2. Compiler optimisations are already extremely unpredictable with deterministic compilers[1], I hate to think how unpredictable your compiler would be.
3. What if someone else wants to build the software, do they have to decide on optimisations now? What if the optimisation depends on your features not available on old generations of CPU? (There is a reason we don’t compile with -march=native)
4. Compilers already have “unsafe” optimisations, but people rarely enable them (-ffast-math)
[1]: https://faultlore.com/blah/oops-that-was-important/
> Do you really want the rust compiler to run at the speed of an llm?
That... might actually be an improvement?
What do you mean "might"? I can crank Fable or Sol up to max intelligence and they'll spend an hour reviewing my rust SDK for working with our ADLSgen2's, and it'll still be done before the rust compiler has compiled the same project.
You misunderstand me. I'm saying that the developers can make these optimizations with LLMs, at the source level, and thus they don't need to be added to compilers.
Like just open Claude Code and ask it to find optimizations. That's the right place for this kind of optimization.
What I'd like to enable this use of LLMs more recklessly is a compiler with formal methods that lets me guarantee equivalence between the opaque optimized code and something actually understandable.
Equivalence on what metrics? In theory what you are asking for makes sense, but I think it is very hard to actually specify what equivalent means in the context of an optimization process that needs to emit code with observably different behavior. Sometimes (although admittedly rarely) speeding up sections of code can even be undesirable for example branchless code for constant time algorithms that avoid timing or energy side channel leaks, or the much more mundane elimination of signed overflow checks or other undefined behavior quirks.
We'll get there eventually whether we like it or not. Just as soon as the current crop of AI/ML engineers retire, or .. get replaced with bots.