Hacker News Reader

Comment by pdimitar | Hacker News Reader

What does that post prove except that "allocating memory that must be zeroed on use but is never used" is million times faster than "allocate memory and zero it right away"?

Sure, I can see how the code doesn't immediately tell you the difference but after you understood it, isn't it completely logical?

The title seems clickbaity and not accurate when you dig into the article.

View on HN

Users who write Rust code don’t necessarily know the underlying optimization (nor should anyone expect that they do).

Do you think the title is still inaccurate even from that point of view?

The entire article could basically be boiled down to your first sentence + the two code examples.

And IMO the title is still inaccurate because it attacks a general promised/desired property of Rust (and other languages) and I honestly don't see the connection. Looks like the observed behaviour is an unfortunate side effect of the `newtype` thing and is very prone to fixing and optimization in future versions. It's not a failure of the "zero-cost abstraction" ideal which is being chased after every day and is still in flux.

> nor should anyone expect that they do I'm not a systems programmer, so I might be wildly off base in what I'm about to say. However, isn't it in fact expected of systems programmers that they do understand in detail what the compiler will do with their code?

As a Rust beginner, I would never assume code I write to not be executed, or cut out by the compiler. I know this sometimes happens, but I wouldn't count on it for lack of understanding. I don't think that's anyone's expectation who doesn't know the inner workings well, really.

Yeah, that was obviously not an optimization. You can't allocate 16 gigs in 5 micros. It might be problematic if you were relying on the lazy allocation of course.

The second example doesn't seem compelling to me either...is a newtype of a reference type a common application?

Reply on news.ycombinator.com