Comment by qwertyuiop924 | Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

Parent Full thread

Because most idiomatic rust operates at a higher level of abstraction than C. Sometimes that matters.

The standard argument is that most of Rust's abstractions are, as much as possible, "zero cost".

However, while Rust's abstractions are very cheap, there is no such thing as a zero-cost abstraction. Why? Because abstractions hide information, and usually provide nicer interfaces than the underlying one. That changes the way you think. If, for example, your stdlib has a standard growable/shrinkable list type that's implemented as an LL under the hood, you'll likely use that structure whenever you need a list, even if you think it's a bad idea to use an LL in that context: it might not even occur to you to check how it's implemented.

Obviously, Rust doesn't do anything this braindead, but it still has abstractions, and those abstractions change the way you think, and may result in suboptimal programs as a result.

This isn't necessarily bad: I don't want to program in raw machine code all the time,and I doubt any of you do, either. But it is something to be aware of.

There is no such thing as a zero-cost abstraction.

While it would probably be incorrect to claim zero cost across the board, there are abstractions that can be optimized to zero cost. For example, in Rust you don't use pointers that can be NULL, but the Option type which can be None. In the usual case, the optimizer translates this to the same assembly as using a raw pointer with NULL instead of None. So in the usual case, there is such a thing as zero-cost abstraction.

But the way that you use Option might differ from the way you use NULL, resulting in costs in the implementation that may not exist otherwise. This is unlikely for that exact case, but very common with other abstractions.

This is exactly why I was careful enough to include the phrase "in the usual case", because it would not be too hard to doctor a situation where the compiler will not optimize the Option away, either because the compiler is not perfect, or because of some clever juggling, or for some other reason. But in the usual case, you get zero-cost abstraction.

This is a misapplication of "zero cost abstractions." The slogan, taken from C++, means:

> C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for [Stroustrup, 1994]. And further: What you do use, you couldn’t hand code any better. - Stroustrup

Everything has costs; that's engineering. But "I chose the wrong data-structure for my task" is not what the slogan is addressing.

Indeed. But my point is that the idea that immidiately presents itself when you think "zero-cost abstraction" is wrong.

>What you do use, you couldn’t hand code any better.

And that will never be true: if you know exactly as much about your usecase as the abstraction, than that might be possible, but that is almost never the case (which was my second point).

> And that will never be true

It is often true. Higher-level Rust code can and often does compile into the same assembly (or sometimes better!) than a lower-level construct. That's the entire premise of optimizing compilers. They're not perfect, but they do achieve this goal more often than "never".

See the Option comments above for one trivial example.

Reply on news.ycombinator.com