Note down takeaways from a fasterthanli.me article

1 files changed, 34 insertions, 0 deletions

diff --git a/reviews/blog-roll.md b/reviews/blog-roll.md
index 3b7f08c..155b67b 100644
--- a/reviews/blog-roll.md
+++ b/reviews/blog-roll.md
@@ -328,3 +328,37 @@ and breaking down "explicit" into more precise epithets:
 [Without boats]: https://without.boats/
 [Not Explicit]: https://without.boats/blog/things-explicit-is-not/
 ["reasoning footprint"]: https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html
+
+# [fasterthanli.me](https://fasterthanli.me/)
+
+:::: tags
+- Rust
+- Go
+- Language design
+::::
+
+In-depth explorations of various topics (I mostly read posts covering
+programming language mechanics), told in a dialectic and very
+entertaining style that sustains interest over their Homeric lengths.
+
+## [What's in the box?](https://fasterthanli.me/articles/whats-in-the-box)
+
+:::: tags
+- Rust
+- Go
+::::
+
+> The Rust compiler is trying to help us.  "You can't just return a
+> reference to something", it pleads.  "You need to tell me how long
+> the thing that's referenced is will live".
+
+> * How does one return different error types without forcing a heap
+>   allocation?
+
+… preferably without having to maintain an ever-shifting enumeration
+of possible error types?
+
+Spoiler: there's no escaping the `enum`, but at least
+[`thiserror`](https://lib.rs/crates/thiserror) lets us focus on *just*
+the enumeration, and generates the boilerplate for the `Display` and
+`From` traits.