Zero Cost Abstractions
https://doc.rust-lang.org/beta/embedded-book/static-guarantees/zero-cost-abstractions.html
The terminology comes from C++. According to Bjarne Stroustrup:
In general, C++ implementations obey the zero-overhead principle: What you don’t use, you don’t pay for. And further: What you do use, you couldn’t hand code any better.
Zero Cost Abstractions - the ability to move certain behaviors to compile time execution or analysis.
Type states contain no actual data, and are instead used as markers. Since they contain no data, they have no actual representation in memory at runtime
Zero cost means - there is no way to get the same feature with less overhead. The feature can still use resources. It just means that handwritten code has equal performance / memory usage then the autogenerated code -> using the abstraction comes at zero cost.
A small example
For example in Python sum(range(1000)) actually does 1000 iterations and 1000 additions, so there’s a cost to writing it that way.
OTOH in Rust (0..1000).sum() compiles down to the constant 499500, so it costs nothing to execute.
Details
In general, “zero cost abstractions” means the abstractions are just as performant as if you had written the underlying code by hand (e.g. iterators just as fast as manual loops, generics just as fast as if you had hand-written specialized types, closures just as fast as if you had written a manual function, wrapping 2 i32s in a struct is no more expensive than using those 2 i32s individually, etc). A lot of the “zero cost” comes from and relies on sophisticated compilers, but language semantics/features play a role too.
“Zero cost abstraction” isn’t really a feature a language either has or doesn’t. In general, abstractions do or don’t have runtime costs. Rust has examples of both, but strives to minimize the runtime cost. Most systems languages will have similar goals.
Zero Cost Abstractions don’t make anything faster. Rather they make the runtime exactly the same as if you wrote the lower level unabstracted version (usually at the expense of compile time). The idea is generally adding a convenience abstraction layer, but without incurring any runtime penalties.
Zero Cost Abstractions means adding higher-level programming concepts, like generics, collections and so on do not come with a run-time cost, only compile time cost (the code will be slower to compile). Any operation on zero-cost abstractions is as fast as you would write out matching functionality by hand using lower-level programming concepts like for loops, counters, ifs and using raw pointers.
Or another way to view this is that using zero-cost abstraction tools, functions, templates, classes and such come with “zero cost” for the performance of your code.
Zero cost abstractions are ones that bear no runtime costs in execution speed or memory usage.
By contrast, virtual methods are a good example of a costly abstraction: in many OO languages the type of the method’s caller is determined at runtime which requires maintaining a lookup table (runtime memory usage) and then actually performing the lookup (runtime overhead per method call, likely at least an extra pointer dereference) with the runtime type to determine which version of the method to call. Another good example would be garbage collection: in return for being able to not worry about the details of memory allocation you pay with GC pauses.
Rust though mostly tries to have zero cost abstractions: ones that let you have your cake and eat it too. Ones that compiler can safely and correctly convert to forms that bear no extra indirection/memory usage. In fact, the only thing that I’m aware of (somebody more knowledgeable correct me if I’m wrong) that you really pay for at runtime in Rust is bounds checking and dyn (see the bit about virtual methods above).
Zero-cost abstractions would be indistinguishable from most other compiler optimizations. The implication here is that there are countless other languages that let you do the same things as Rust or C++, but with a nonzero and often runtime-specific cost.