In Soviet Union times in eighties in Belarus it was considered ok that a child could stay alone at home from age of 7 when they started a school. Some parents opted for after-school programs and some relied on grandmothers like it was for me but some of my schoolmates stayed at home alone for few hours until their mothers would be back from work (fathers typically worked longer and further away from home).
And from the age of 9 there was no after-school options at least in my school.
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.
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 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.
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?
> 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?
'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...
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.
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)
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.
Arbitrary subranges of int types were available in Ada for over 40 years via static enforcement via Spark and compilers were able to optimize them nicely.
For a system language I wish Rust would support such things rather than coming with NonZero hacks.
This is called "pattern types" in Rust land, as your parent mentioned, and is exactly the kind of work being talked about.
NonZero isn't a hack: it's an example of a common pattern. If pattern types were available today, you'd still want NonZero, as an example of a pretty standard pattern.
The idea is, as always: prove out the specific version, then generalize.
In London in many apartment blocks one can only get wired internet via an old copper cable with speeds like 80mbit/s download in theory but in practice it can be below 30 with ping in 50ms range and much slower upload. And 5g does not help either as the signal can be very weak.
Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!
A phone line from before WWII works fine to make a call but absolutely sucks for DSL.
And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.
It's not that, it's the building owners (freeholders) refusing permission, or not replying. It's a massive issue.
You'll notice buildings in central London that are listed _but_ have housing association ownership nearly all have fibre to each apartment, as they did portfolio wide deals with hyperoptic etc.
And pipes don't help. Openreach (who owns the copper network) are not allowed in 99% of cases to "fix" copper with fibre under the agreements they have with building owners, they can only make like for like repairs.
The worst affected apartment buildings are 90s and pre 2015ish. Everything after that got fibre installed at build time.
Btw it is worth checking if you have an altnet like hyperoptic, community fibre or g network available. The majority do and if you are just checking for openreach or VM broadband it won't show up.
Objectively no. For example carbon taxes or other environmental taxes have been proposed by free market advocates since the 70s and never been implemented (from the left you see advocacy for environmentalism but not related to taxation)
Also if we had enough taxes, the wealth inequality would not be ramping up to great depression levels and basic necessities like healthcare and housing would not be catastrophically related to bankruptcies in america.
If you are a worker, specially one in the upper middle class range of salaries, then yes. You are being over taxed. But that is simply because those below you have nothing to contribute and the system refuses to tax those above you appropriately. You are a local maximum in a system that is not globally efficient, so you have too much tax, the country doesnt
Vague assertions with no evidence don't really help the discussion. If someone is going to assert such a strong claim like "We have more than enough taxes on working people and not enough on the wealthiest classes.", they really need to at least define what they mean by "working people" and "wealthiest classes" and then give some evidence to show that "taxes are disproportionately applied" between these groups. (You say it was a "truthful comment" but how can you even be sure you are interpeting the comment the way the original poster meant?)
(In general, whether people agree or disagree with an assertion I would hope they wouldn't downvote something as long as the person contributes enough to the discussion that the reader can understand what they are asserting and can check for themselves if the evidence they give supports or doesn't support the assertion.)
Wealth inequality in the US is so bad that the statement is true with pretty much any reasonable interpretation.
The top quantiles of the population (10%, 1%, 0.1%, billionaires) are paying less taxes than they should in a fair system; and that statement becomes increasingly illustrative of the situation the smaller and richer the quantile you choose is.
The fact that wealth inequality is _accellerating_ should be enough to tell you that the taxation system is unfair towards the poorer end.
Neither book stores nor app stores pay for quality, beyond some minimum low bar. Markets are optimized for getting product out quickly, sales and marketing, and follow on effects of succeeding with a hit. If you made a better app, game, book, or song you need to get through the noise of millions of competitors and for the most part, it's never going to happen.
In short, the expected effect of AI will be more stuff, faster, not better. Are we seeing that? I think so.
Unfortunately the answer is no. Reading or just owning a book by a certain author can be a matter of fashion or prestige. That allows for really bad work still be published.
EV only this year became comparable in prices to gasoline cars thanks to massive efforts by Chinese companies to reduce battery prices and improve drivetrain.
With that further changes can be very quick as forcing EV no longer requires reallocating money from other things.
If 100% of new cars were EVs then there might be feedback loops that accelerate the long tail. Like gas stations becoming leas profitable, less prolific, and more expensive.
You might also see battery prices push the price of new cars well below that of second hand ICE vehicles.
Even if the replacement window for existing vehicles doesn’t change, the environmental impact would run ahead of the adoption curve. High volume use cases like delivery and Ubers would be the first to switch to EVs.
And from the age of 9 there was no after-school options at least in my school.
reply