make specific, edit

src/SUMMARY.md

@@ -7,7 +7,7 @@
         - [Consider all cases](./how_rust_empowers/reliable/consider_all_cases.md)
     - [🐎 Performant](./how_rust_empowers/performant.md)
         - [Zero-cost abstractions](./how_rust_empowers/performant/zca.md)
-        - [Specify only what's necessary](./how_rust_empowers/performant/specify_what_is_necessary.md)
+        - [Specify only what's necessary](./how_rust_empowers/performant/specify_only_what_is_necessary.md)
     - [🥰 Supportive](./how_rust_empowers/supportive.md)
         - [Polished developer experience](./how_rust_empowers/supportive/polished.md)
     - [🧩 Productive](./how_rust_empowers/productive.md)

src/how_rust_empowers/performant.md

@@ -21,10 +21,12 @@ Rust iterators are a good example of something which meets our goal of being *pe
 
 What are some of the ways that we make Rust feel **performant**?
 
-### Zero-cost abstractions
+### [Zero-cost abstractions](./performant/zca.md)
 
-Rust borrowed the idea of zero-cost abstractions from the C++ community. Bjarne Stroustroup defined zero-cost abstractions as, "What you don't use, you don't pay for. And further: What you do use, you couldn't hand code any better." We design our abstractions with these goals in mind as well.
+> "What you don't use, you don't pay for. And further: What you do use, you couldn't hand code any better." -- Bjarne Stroustroup
 
-### Specify only what's necessary
+### [Specify only what's necessary](./specify_only_what_is_necessary.md)
+
+> Specify the details that are needed to capture the programmer's intent, but not more.
 
 Many details of Rust are left deliberately unspecified. For example, unless users manually add a `repr` attribute, Rust structs and enums can be laid out in memory however the compiler sees fit. This allows us make optimizations like reordering struct fields to eliminate padding and reduce size, or representing `Option<&T>` as a single, nullable pointer. (Of course, reserving this freedom works against [transparency] and [versatility], which is why we have the option to specify the `repr`.)

src/how_rust_empowers/performant/specify_only_what_is_necessary.md

@@ -0,0 +1 @@
+# Specify only what's necessary

src/how_rust_empowers/performant/specify_what_is_necessary.md

@@ -1 +1,5 @@
 # Specify only what's necessary
+
+> Specify the details that are needed to capture the programmer's intent, but not more.
+
+Many details of Rust are left deliberately unspecified. For example, unless users manually add a `repr` attribute, Rust structs and enums can be laid out in memory however the compiler sees fit. This allows us make optimizations like reordering struct fields to eliminate padding and reduce size, or representing `Option<&T>` as a single, nullable pointer. (Of course, reserving this freedom works against [transparency] and [versatility], which is why we have the option to specify the `repr`.)

src/how_rust_empowers/reliable.md

@@ -27,4 +27,4 @@ Rust programmers never have to worry about notorious, hard-to-diagnose, harder-t
 
 > Rust doesn't hide error conditions and encourages listing all possibilities explicitly (or acknowledging that something is elided).
 
-Rust uses a number of mechanisms to encourage code authors to list all possibilities. This thoroughness frequently helps identify bugs because it ca highlight things that the programmer has forgotten about. However, it comes at a price in [productivity], since it can force the programmer to deal with details that they haven't figure out yet.
+Rust uses a number of mechanisms to encourage code authors to list all possibilities. This thoroughness frequently helps identify bugs because it can highlight things that the programmer has forgotten about. However, it comes at a price in [productivity], since it can force the programmer to deal with details that they haven't figure out yet. As an example, consider exhaustive matches: they are frequently very useful, but when a new enum variant is added, all matches must be edited to account for it (or else they must include a `_` case).