Add internal links to related blog posts for deeper reading

mre · mre · commit 38bd216144bc · 2026-03-15T21:51:29.000+01:00
diff --git a/config.toml b/config.toml
@@ -5,6 +5,7 @@ author = "Matthias Endler"
 
 compile_sass = true
 build_search_index = false
+ignored_content = ["**/code/**/*.md"]
 generate_feeds = true
 feed_filenames = ["atom.xml", "rss.xml"]
 
diff --git a/content/blog/cpp-rust-interop/index.md b/content/blog/cpp-rust-interop/index.md
@@ -86,6 +86,8 @@ Recognizing that a complete switch from C++ to Rust is not always feasible or de
 
 Tyler wrote a series of blog posts on [Rust and C++ interop](https://tylerjw.dev/posts/rust-cpp-interop/) that go into great detail about integrating Rust into C++ projects, which covers FFI bindings, CMake (a build system generator for C++ projects), Cxx (a code generation tool), Conan (a C++ package manager), and more.
 
+For an up-to-date, step-by-step guide on the tooling and strategies involved in this process, see [How to Introduce Rust into a C++ Codebase](/blog/rust-ffi-incremental-migration/).
+
 It is recommended to start with the most safety-critical or unreliable parts of your codebase:
 
 > What you have to do is think about how important security is at each level of the stack and how to address it in small incremental ways. - [Jeremy Soller in the Rust in Production podcast](https://corrode.dev/podcast/s02e07-system76/?t=47%3A52)
diff --git a/content/blog/defensive-programming/index.md b/content/blog/defensive-programming/index.md
@@ -9,6 +9,10 @@ reviews = [
     { name = "Tyler Stevens", url = "https://www.linkedin.com/in/tpstevens/" },
     { name = "kat", url = "https://www.sakurakat.systems/" },
 ]
+resources = [
+    "[Making illegal states unrepresentable](/blog/illegal-state/)",
+    "[Compile-time invariants in Rust](/blog/compile-time-invariants/)",
+]
 +++
 
 I have a hobby.
@@ -738,4 +742,4 @@ By following these patterns, you can:
 It's a skill that doesn't come naturally and it's not covered in most Rust books, but knowing these patterns can make the difference between code that works but is brittle, and code that is robust and maintainable for years to come.
 
 Remember: if you find yourself writing `// this should never happen`, take a step back and ask how the compiler could enforce that invariant for you instead.
-The best bug is the one that never compiles in the first place.
+The best bug is the one that never compiles in the first place.
diff --git a/content/blog/flattening-rusts-learning-curve/index.md b/content/blog/flattening-rusts-learning-curve/index.md
@@ -81,7 +81,7 @@ Don't make it too hard on yourself in the beginning.
 Here are some tips:
 
 - Use `String` and `clone()` and `unwrap` generously; you can always refactor later -- and refactoring is the best part about Rust!
-I wrote an article on saving yourself time during that phase [here](/blog/prototyping).
+I wrote an article on saving yourself time during that phase [here](/blog/prototyping/).
 - Use simple if or match statements before starting to learn some of the more idiomatic `.and_then` etc. combinators
 - Avoid async Rust in week 1. The additional rules are a tax on people still learning the core ownership model.
 
@@ -356,7 +356,7 @@ In the long run, finding the right resource saves you time because you will lear
 I personally don't like doing toy exercises that others have built out for me.
 That's why I don't like Rustlings too much; the exercises are not "fun" and too theoretical. I want more practical exercises.
 I found that [Project Euler](https://projecteuler.net/) or [Advent of Code](https://adventofcode.com/) work way better for me.
-The question comes up quite often, so I wrote a blog post about [my favorite Rust learning resources](/blog/rust-learning-resources-2026).
+The question comes up quite often, so I wrote a blog post about [my favorite Rust learning resources](/blog/rust-learning-resources-2026/).
 
 #### Don't Just Watch YouTube
 
diff --git a/content/blog/foundational-software/index.md b/content/blog/foundational-software/index.md
@@ -8,7 +8,7 @@ template = "article.html"
 series = "Rust Insights"
 +++
 
-Ten years of stable Rust; writing this feels surreal. 
+Ten years of stable Rust; writing this feels surreal.
 
 It's only been *yesterday* that we all celebrated the 1.0 release of this incredible language.
 
@@ -49,7 +49,7 @@ The Linux kernel wasn't built in a day.
 **People need time to learn.**
 
 The whole idea of Rust is to enable **everyone** to build reliable and efficient software.
-To me, it's about breaking down the barriers to entry and making larger parts of the software stack accessible to more people. 
+To me, it's about breaking down the barriers to entry and making larger parts of the software stack accessible to more people.
 You can sit with us.
 
 > We are committed to providing a friendly, safe and welcoming environment for all
@@ -165,7 +165,9 @@ Rust is useful in situations where the ["worse is better" philosophy falls apart
 > With the right thing, designers are equally concerned with simplicity, correctness, consistency, and completeness.
 
 I think many companies will choose Rust to build their future platforms on.
-As such, it competes with C++ as much as it does with Kotlin or Python.
+As such, it competes with C++ as much as it does with Kotlin or Python [^sustainability].
+
+[^sustainability]: This also raises the question: ["Will Rust be alive in 10 years?"](/blog/rust-in-ten-years/) And to me the answer is clear: many large organizations have already bet on it and are building their future on top of it. Rust is here to stay.
 
 I believe that we should shift the focus away from memory safety (which many other languages also offer) and instead focus on the explicitness, expressiveness, and ecosystem of Rust that is highly competitive with these languages.
 It is a language for teams which want to build things *right* and are at odds with the "move fast and break things" philosophy of the past.
@@ -202,6 +204,8 @@ There is more to be said about supply-chain security and sustainability in a fut
 ## Rust Is A Language For Decades
 
 Building foundational systems is rooted in the profound belief that the efforts will pay off in the long run because organizations and society will benefit from them for decades.
+([Long-term Rust Project Maintenance](/blog/long-term-rust-maintenance/) covers the day-to-day work of keeping a Rust codebase healthy over years: dependency management, API design, release automation, and more.)
+
 We are building systems that will be used by people who may not even know they are using them, but who will depend on them every day; that's critical infrastructure.
 
 And Rust allows us to do so with great ergonomics.
diff --git a/content/blog/idiomatic-rust-resources/index.md b/content/blog/idiomatic-rust-resources/index.md
@@ -16,9 +16,18 @@ Here's a curated list of resources to **help you write ergonomic and idiomatic R
 The list is open source and [maintained on GitHub](https://github.com/mre/idiomatic-rust), and contributions are always welcome!
 
 Discover a wealth of tutorials, workshops, and articles created by Rust experts, all aimed at helping you become a better Rust programmer. Each resource is peer-reviewed to ensure adherence to Rust best practices. Plus, you can easily filter, sort, and search by tags, year, and difficulty level to find exactly what you need.
+<<<<<<< Updated upstream
 
 <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js"></script>
 <script src="https://cdn.datatables.net/1.13.7/js/jquery.dataTables.min.js"></script>
+||||||| Stash base
+
+<script src="//ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js"></script>
+<script src="//cdn.datatables.net/1.13.7/js/jquery.dataTables.min.js"></script>
+=======
+<script src="//ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js"></script>
+<script src="//cdn.datatables.net/1.13.7/js/jquery.dataTables.min.js"></script>
+>>>>>>> Stashed changes
 <script src="dataTables.checkboxes.min.js"></script>
 <script src="table.js"></script>
 
diff --git a/content/blog/iterators/index.md b/content/blog/iterators/index.md
@@ -348,4 +348,4 @@ are and they are a powerful stand-in for those list comprehensions you might
 know and love from Python.
 
 I encourage you to explore the iterator API in Rust and see how you can use it
-to make your code more expressive and concise. 
+to make your code more expressive and concise.
diff --git a/content/blog/long-term-rust-maintenance/index.md b/content/blog/long-term-rust-maintenance/index.md
@@ -524,17 +524,18 @@ consistent code style and catch common errors:
 
 Run your CI pipeline on a regular basis to ensure that your codebase is always
 in a deployable state. The worst time to find out that something is broken is when
-you're trying to deploy a fix. 
+you're trying to deploy a fix.
 
 Look into [release-plz](https://github.com/MarcoIeni/release-plz) for release
 automation. It can create pull requests for new releases, which you can review
 and merge when you're ready.
 
+
 ![release-plz](release-plz.png)
 
 If you are afraid of triggering a release, it's a sign that your release process
-is too complex. Simplify it until you are confident that you can release at any
-time.
+is too complex or too slow. Simplify it until you are confident that you can release at any
+time and [speed up your Rust CI builds](/blog/tips-for-faster-ci-builds/).
 
 ## Invest in the Rust Ecosystem
 
diff --git a/content/blog/memory-safety/index.md b/content/blog/memory-safety/index.md
@@ -194,6 +194,8 @@ As I wrote in a recent post on [choosing Rust](https://endler.dev/2025/choosing-
 
 Google, Microsoft, Amazon, Meta, Cloudflare, and Discord have all independently arrived at the same conclusion and are investing heavily in Rust for their critical infrastructure. [Microsoft's CTO of Azure stated](https://x.com/markrussinovich/status/1571995117233504257) that new projects should be written in Rust rather than C or C++. Both the [Linux kernel](https://docs.kernel.org/rust/) and the [Windows kernel](https://x.com/markrussinovich/status/1656416376125538304) now contain Rust code.
 
+If you're sceptical about Rust's long-term viability before committing to it, I wrote an [article on the ecosystem maturity, corporate investment, and funding structures that make Rust a sound long-term bet](/blog/rust-in-ten-years/).
+
 ## The Cost of Waiting
 
 Some organizations look at this landscape and think: "We'll wait for the regulations to be finalized. We'll act when we have to."
@@ -230,7 +232,7 @@ At a minimum:
 
 1. **An inventory of memory-unsafe code** in your products, prioritized by risk (network-facing code, cryptographic operations, data parsing).
 2. **A plan for new development** in a memory-safe language.
-3. **A migration strategy** for high-risk existing components, potentially through incremental Rust rewrites using the FFI (Foreign Function Interface).
+3. **A migration strategy** for high-risk existing components, potentially through incremental Rust rewrites using the FFI (Foreign Function Interface). See [How to Introduce Rust into a C++ Codebase](/blog/rust-ffi-incremental-migration/) for a deep guide on tooling, build system integration, and migration patterns if you're coming from C++.
 4. **Interim mitigations** for code that won't be migrated soon (compiler hardening, fuzzing, static analysis).
 5. **Timeline and milestones** showing a credible, prioritized reduction of memory safety vulnerabilities.
 
diff --git a/content/blog/paradigms/index.md b/content/blog/paradigms/index.md
@@ -604,6 +604,7 @@ Here are my personal rules of thumb:
   smaller scopes like functions and closures, functional methods such as
   mapping, filtering, or reducing can make your code both concise and clear.
   Use functional programming when you can phrase your problem as a series of transformations over some data.
+
 * **Use imperative style for granular control.** In scenarios where you're
   working close to the hardware, or when you need explicit step-by-step
   execution, the imperative style is often a necessity. It allows for precise
@@ -624,3 +625,5 @@ Here are my personal rules of thumb:
 Lastly, avoid bias towards any particular paradigm. You can write better code if
 you test your assumptions every now and then.
 
+
+
diff --git a/content/blog/prototyping/index.md b/content/blog/prototyping/index.md
@@ -675,9 +675,7 @@ help: consider using the `'static` lifetime, but this is uncommon unless you're
 
 ([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7274f20a06226316c93d9984f1d66b5f))
 
-A simple way around that is to [avoid lifetimes altogether](/blog/lifetimes).
-They are not necessary in the beginning.
-Use owned types like `String` and `Vec`.
+A simple way around that is to use owned types like `String` and `Vec` and avoid lifetime annotations altogether. [They're needed less often than you'd think](/blog/lifetimes/).
 Just `.clone()` wherever you need to pass data around. 
 
 ```rust
diff --git a/content/blog/rust-option-handling-best-practices/index.md b/content/blog/rust-option-handling-best-practices/index.md
@@ -18,7 +18,7 @@ More specifically, the problem arises when you want to return early from a funct
 
 It has been discussed a million times already, but, surprisingly, not even the Rust book mentions my favorite approach to handling that, and many forum posts are outdated.
 
-With a bit of practice, robust handling of `None` can become as easy as `unwrap()`, but safer. 
+With a bit of practice, robust handling of `None` can become as easy as `unwrap()`, but safer.
 
 Jump to the end if you're in a hurry and just need a quick recommendation.
 
@@ -259,7 +259,7 @@ The one issue I had when teaching this was that it looked a bit more verbose for
 
 ## Solution 4: `let-else`
 
-With Rust 1.65, [the `let-else` expression was stabilized](https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#let-else-statements), so now you can write this: 
+With Rust 1.65, [the `let-else` expression was stabilized](https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html#let-else-statements), so now you can write this:
 
 ```rust
 let Some(user) = get_user() else {
diff --git a/content/blog/sharp-edges-in-rust-std/index.md b/content/blog/sharp-edges-in-rust-std/index.md
@@ -279,7 +279,9 @@ There are a few options:
 
 As you can see, my list of warts in the Rust standard library is quite short.
 Given that Rust 1.0 was released more than a decade ago, the standard library has held up *really* well.
-That said, I reserve the right to update this article in case I become aware of additional sharp edges in the future. 
+That said, I reserve the right to update this article in case I become aware of additional sharp edges in the future.
+
+If you're looking to go further, [Pitfalls of Safe Rust](/blog/pitfalls-of-safe-rust/) covers a broader set of bugs that the compiler won't catch: integer overflows, unsafe type casts, TOCTOU races, and more.
 
 In general, I like that Rust has a relatively small standard library because once a feature is in there it stays there forever. [^forever]
 
diff --git a/content/blog/simple/index.md b/content/blog/simple/index.md
@@ -381,7 +381,10 @@ What I appreciate about Rust is how it balances high-level and low-level program
 We should leverage that more often. 
 Most of the time, I write Rust code in a straightforward manner, and when that extra bit of performance becomes critical, Rust always lets me go back and optimize. 
 
-## Keep Your Users in Mind 
+For example, in hot code paths, avoiding allocations might make sense, at which point you might have to deal with [lifetimes](/blog/lifetimes/).
+But that's a late-stage optimization. Don't reach for it while the design is still in flux.
+
+## Keep Your Users in Mind
 
 Most of the code you'll write for companies will be application code, not library code.
 That's because most companies don't make money writing libraries, but business logic.
@@ -528,6 +531,7 @@ Use all the features you need and none you don't.
 Crucially, writing simple software does not mean implementing "good-enough-for-now" software.
 That approach surely will lead to technical debt and maintenance nightmares further down the line as workarounds get stacked on top of each other.
 No, simple software can still be well-designed software, but it keeps the current requirements in mind.
+For example, [compile-time invariants](/blog/compile-time-invariants/) and [making illegal states unrepresentable](/blog/illegal-state/) are techniques that add real safety without adding accidental complexity. The type system does the work so your code doesn't have to.
 The goal is not to take shortcuts. Quite the contrary: the goal is to avoid unnecessary complexity, which often is the root cause for having
 to take shortcuts later on when bad systems design prevents a cleaner solution. 
 In [code reviews](https://endler.dev/2025/how-to-review-code/), I pay extra attention to ensuring we don't cut corners to avoid doing the necessary design work.
