The 'zero cost' attitude is one of C++ problems. Zero cost abstractions are never really entirely zero cost. You still pay, often in something that you didn't bother to measure, which (in C++) is usually compile time or programmer productivity or programmer cognitive cost or compiler complexity.
There's a reason a lot of the complaints about C++ mention bloat or the difficulty of practically choosing a safe subset (you could use a subset, but you're very likely dependent on coworkers, existing codebases and library authors which may not share your subset). A lot of people added 'zero cost' stuff, and all of that has a cost.
For example, lets say Rust's newtype pattern worked perfectly everywhere, and all of the author's examples run fine as u8 with no runtime cost. There would likely still be a small cognitive cost to learn this, a small cost to unwrap the types (for other programmers reading the code), and a tiny cost in compile time. Typedefs are worth it, and it's all very reasonable to pay this!
But there's still a cost, and when people never believe there's a cost a language ends up like C++.
'Zero cost' is generally meant to mean 'zero runtime cost'. For most workloads, an increase in compile times is okay for an optimized production build. In the rare cases where that's not enough, I find that using precompiled headers and splitting code into translation units helps significantly.
Yet many people never look at other costs, so de facto they're assuming 'insignificant costs for everything' which isn't true.
For example, C++'s template language as originally implemented was technically 'zero cost', but C++ programmers paid for it a lot for a long time, in inscrutable error messages and slow compile times (this was fixed to a large degree with modern implementations and standards).
People didn't understand that they were paying in programmer / compile time / bad error messages? I don't believe that for a second. Those costs are extremely visible. As visible as it is possible to be. They wouldn't get more visible if you dressed them in reflective jackets, slapped a police light bar on top, and turned on a siren to make sure everyone was looking in the right direction. Who undergoes that kind of suffering and doesn't even notice? Nobody.
In contrast, the benefits of Zero Cost Abstraction are quite subtle. "Why would I want that? Ever heard of Moore's law? Caring about perf is so 1990s!" goes the immediate thinking. If you never have to write high-perf code, that reasoning is even correct! Of course, there are still many places where performance does matter, and being able to use high level language features on the very innermost loops, the places that halve or quarter the throughput of your $6000 graphics card(s) if you carelessly toss in even a single call of overhead, is quite something to those in a position to take advantage.
Since the caveats of ZCA are obvious and the benefits are subtle, I think it's perfectly fair to use the term as a way to draw attention to the latter.
The problem with this viewpoint is that the baseline is pretty arbitrary. Using a newtype carries a conceptual cost of wrapping and unwrapping... but using u8 directly carries the conceptual cost of remembering what any given u8 means! What makes that the baseline and newtype wrapping a cost over that as opposed to using domain concepts in types as the baseline and using native types the cost?
Well, imagine that your code is serializing and deserializing someone else's type. You probably care more in that context about the underlying type and not the newtype, and the newtype doesn't help you.
Now, I did say this option was worth it. And there are cases of being too conservative (Golang?). But when designing and programming, one should look at the tradeoff. Abstraction is not always worth its costs [EDIT: and sometimes you can have less costs by a better abstraction, but being aware of the costs helps to think about the better abstraction].
that's exactly what should keep you awake at night. Because the conceptual cost is arbitrary and not meaningfully measurable in a quantitative sense, people tend to elide over it, but though it's not measurable that cost is no less real and might bubble up in the form of someone losing money, or in some cases, causing physical harm.
Zero cost refers to runtime cost, as in the compiled code.
> You still pay, often in something that you didn't bother to measure, which (in C++) is usually compile time or programmer productivity or programmer cognitive cost or compiler complexity.
Obviously everything is about tradeoffs. If an abstraction is making everything worse for you, then don’t use it. I don’t think it’s fair to try to list every possible downside of an abstraction, as there are obviously also downsides to not using abstractions otherwise we wouldn’t have these options.
Zero cost refers to the compiled code and runtime performance.
'zero cost' is what makes some things possible. If your perspective is one where CPU and memory is effectively infinite then yes, who cares about zero cost. The last C++ project I worked on I had like 32k of storage and some kilobyte sized amount of RAM. If C++'s abstractions weren't zero cost it would have been impossible to use in this environment. Java, C#, Go -- none of these are even close to possible.
Why wouldn't I just use C? Because of improved programmer productivity and readability of the code.
The reason C++ exists as a language today (and why Rust is it's direct competitor) is because of zero-cost abstractions. Because in many situations programmer productivity and compiler complexity is second to performance.
My takeaway wasn't 'never abstract'. That's obviously absurd. Even C itself has abstractions which it tries to make zero cost. Only that it's sometimes not worth it in the language, and C++ neglected to look at the other costs in the past.
No, that's the point of C++. If you want a language that doesn't do zero cost abstractions, there are plenty to chose from. If you want a language a step above C that gives you fine-grained control over exactly what code is generated and memory allocated than you have very few choices.
You're basically just arguing that C++ shouldn't be C++ (and Rust shouldn't be Rust). We already have plenty of languages that provide high-level "costly" abstractions. The reason we need C/C++/Rust is for that zero-cost aspect.
Historically, there were much fewer choices for languages and arguably C++ has been used for building applications that didn't need zero-cost features. But now we have plenty of alternatives and C++ still exists for that valuable niche that it provides. This is the reason Rust was created -- to provide this level of control without the baggage of C++.
Bjarne and the C++ community are very clear on what the zero overhead principle is. If it isn’t holistic enough for you, that’s no fault of the principle. Your objection is either off-topic to what ‘zero cost’ means, or equivocation.
Why did a Rust defect become such a diatribe on C++ ? As far as I am aware, using a typedef/using type does not slow down zero-based initialisation of primitive types in C++. (last time I checked a few years ago - will apologise if this has changed).
Sorry, got bit a bit too much by C++ templates and a few other things. Rust views itself as a successor language, and I wouldn't like it to make the same mistakes.
There's a reason a lot of the complaints about C++ mention bloat or the difficulty of practically choosing a safe subset (you could use a subset, but you're very likely dependent on coworkers, existing codebases and library authors which may not share your subset). A lot of people added 'zero cost' stuff, and all of that has a cost.
For example, lets say Rust's newtype pattern worked perfectly everywhere, and all of the author's examples run fine as u8 with no runtime cost. There would likely still be a small cognitive cost to learn this, a small cost to unwrap the types (for other programmers reading the code), and a tiny cost in compile time. Typedefs are worth it, and it's all very reasonable to pay this!
But there's still a cost, and when people never believe there's a cost a language ends up like C++.