ohr

(Author here) thanks! Even as an experienced Rust developer, this is a lot of syntax which is part of what makes it archaic I think.

As usual with Rust most of it is due to inherent complexity: for example, when you deal with raw pointers, you need to specify if they are const or mut, and you must have a syntax that’s not &, and not too wordy: so * is a good choice (might be changed to &raw in the future!). And if you want to say that something is generic and the generic parameter is a pointer… you just end up with a lot of syntax.

But if you let it run the tests, it’ll just do that on its own (or delete the tests, but usually it won’t), which is very useful and seems to match the article’s sentiment.

Used the Save Page WE Chrome extension to capture the html (after cleaning up with inspect element + delete), and added a bit of custom JavaScript to scroll everything to the right place. Needed the extension for the styling to be captured correctly.

(Author here) I'm a huge fan of the "How to speed up the Rust compiler" series! I was hoping to capture the same feeling :)

I think that since the 1.5% one is only for aarch64 it's a bit unfair to claim the full number, more like 1/2 if you consider arm/x86 to be the majority of the (future) deployments

Thanks! Would be interesting to see if Rust/LLVM folks can get the compiler to apply this optimization whenever possible, as Rust can be much more accurate w.r.t memory initialization.

(Author here) Thanks! That's useful feedback.

I also agree - the final article isn't skim-friendly enough, which drives away some readers.

> don't you have to get your version's struct data member type correct

No, since Serde will happyly fill a `u64` field with any other `u{8,16,32}` value, and even with signed types (as long as the actual value is non-negative) - this is sort of what happens when you deserialize a JSON `[1, 2, 3]` into `[u64]`.

That's understandable, but I think it depends on how many different structs like this you have and how many fields you need to work with (for our usecase, we had tens of structs with tens of fields each).

There's also an Alternatives section in the article about other approaches that can achieve similar results, but of course 'do nothing' is also a valid option.

Edit: > If actually concerned about the need to know UI8 ..

Just a small note: even if you don't care about the fact that it's a UI8, you still have to use the correct type. For example, if the field happens to be returned as UI4, this code won't work!