N
Niko Matsakis
smallcultfollowing.com · Personal blog · on HN since 2012
Niko Matsakis, a Rust language designer, writes the Babysteps blog on borrow checking, traits, language design, and his Dada language.
What HN saysHN commenters cite it as the authoritative source on Rust internals like Polonius, unwinding and destructors, and treat him as the borrow checker's author.
221HN people shared it
111linked it in comments
263stories submitted
3.9Kstory points
2 months agolast shared
2012people per year2026
Most-shared posts
- 1An alias-based formulation of the borrow checker (2018)12 people · 7 points · first shared 2018 · discussion on HN
- 2Babysteps9 people · first shared 2012
- 3Lowering Rust traits to logic8 people · 2 points · first shared 2017 · discussion on HN
- 4The borrow checker within7 people · 232 points · first shared 2024 · 36 comments on HN
- 5Non-Lexical Lifetimes in Rust7 people · 141 points · first shared 2016 · 58 comments on HN
- 6Drop the distinction between mutable and immutable local variables in Rust7 people · 87 points · first shared 2014 · 49 comments on HN
- 7Unwind Considered Harmful?7 people · 13 points · first shared 2024 · 1 comments on HN
- 8Rust MIR-based borrow check (non-lexical lifetimes) status update7 people · 11 points · first shared 2018 · 1 comments on HN
- 9In Rust, ordinary vectors are values7 people · 7 points · first shared 2018 · discussion on HN
- 10Rayon: data paralellism in Rust6 people · 64 points · first shared 2015 · 9 comments on HN
- 11Rustacean Principles6 people · 23 points · first shared 2021 · discussion on HN
- 12The Connection Between Memory Management and Data-race Freedom6 people · 13 points · first shared 2013 · discussion on HN
- 13The Handle Trait6 people · 9 points · first shared 2025 · discussion on HN
- 14Only Bounds6 people · 6 points · first shared 2026 · discussion on HN
- 15Claiming, Auto and Otherwise5 people · 10 points · first shared 2024 · 3 comments on HN
What HN people wrote when they linked it
aw1621107 · 2026-08-10
For a bit of context, this is the basis of what the Rust devs would eventually call Polonius. This first iteration didn't quite pan out, but the devs eventually developed a new version [0] that seems to have worked out to the point that they recently announced that they are enabling a subset of this new version (called Polonius Alpha) in nightly with the intent to stabilize later this year [1].
[0]: https://smallcultfollowing.com/babysteps/series/polonius-revisited/
[1]: https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-night…
vlovich123 · 2026-08-03
Exactly - fail_silently is illegal and you have to actually destructure the type to explicitly implement the destructor
> How would you handle destructors with arguments?
https://smallcultfollowing.com/babysteps/blog/2025/10/21/move-destruct…
yoshuaw · 2026-08-03
Niko Matsakis (T-Lang) has since also published a post on only-bounds: https://smallcultfollowing.com/babysteps/blog/2026/06/09/only-bounds. Sized hierarchy, Move, and Forget/Leak all share the same fundamental compat issues, so we're all pretty motivated to solve the underlying problems in a way that enables all the other features to be built on top.
wasmperson · 2026-07-24
The worst part about rust not having exceptions is that it actually does have exceptions, you just shouldn't use them. All the downsides and none of the benefits:
https://smallcultfollowing.com/babysteps/blog/2024/05/02/unwind-consid…
brson · 2026-02-14
Rust borrow checker author's new language designs.
Follow up posts:
https://smallcultfollowing.com/babysteps/blog/2026/02/09/hello-dada/
https://smallcultfollowing.com/babysteps/blog/2026/02/10/dada-moves-an…
https://smallcultfollowing.com/babysteps/blog/2026/02/14/sharing-in-da…
avandecreme · 2026-01-25
This article discusses making captures more flexible: https://smallcultfollowing.com/babysteps/blog/2025/10/22/explicit-capt…
I agree it would be nice, in particular to make it easier to understand when learning the concept.
andrepd · 2025-10-16
A very interesting post about this issue.
https://smallcultfollowing.com/babysteps/blog/2025/10/07/the-handle-tr…
nialv7 · 2025-10-16
> Looking at the rust rfc for the lightweight clones feature
while the Use trait (a better name is proposed [1]) is useful, but I don't see how the .use syntax adds any value over .clone()? If the compiler is able to perform those optimizations, it can also lint and ask the user to remove the unnecessary .clone()/change x.clone() to &x. IMO this is better than the compiler doing black magic.
[1]: https://smallcultfollowing.com/babysteps/blog/2025/10/07/the-handle-tr…
SkiFire13 · 2025-10-04
There haven't been any serious proposals yet, but some ideas have been floating around from time to time. For example this blog post has some ideas that might allow them https://smallcultfollowing.com/babysteps/blog/2024/03/04/borrow-checki…
The hardest problems I think is that this requires a fundamental change to the language that something might be already borrowed just by existing. It also likely needs to introduce a notion of "stable" places that will not move when you move a prefix of them, e.g. to allow moving a `Box` holding self-referential data. In other words, there's a lot of bikeshedding to do.
steveklabnik · 2025-09-17
> It's important to remember Rust's borrow checker was computationally infeasible 15 years ago.
The core of the borrow checker was being formulated in 2012[1], which is 13 years ago. No infeasibility then. And it's based on ideas that are much older, going back to the 90s.
Plus, you are vastly overestimating the expense of borrow checking, it is very fast, and not the reason for Rust's compile times being slow. You absolutely could have done borrow checking much earlier, even with less computing power available.
1: https://smallcultfollowing.com/babysteps/blog/2012/11/18/imagine-never…
m11a · 2025-08-30
For Rust, there are a few blogs that lean more on fundamentals and language design (like https://without.boats/blog, https://smallcultfollowing.com/babysteps).
For misc Rust engineering, like the OP, I agree it’s quite scattered. I personally like to save good ones in my Feedbin as I encounter them
lidavidm · 2025-07-08
Someone on the issue they made explained why Clone is "broken": https://github.com/JelteF/derive_more/issues/490#issuecomment-30374081…
Which links to this blog post explaining the choice in more detail: https://smallcultfollowing.com/babysteps/blog/2022/04/12/implied-bound…
estebank · 2024-12-24
It is also behavior that we want to change, it's just non-trivial to do so.
https://smallcultfollowing.com/babysteps/blog/2024/06/02/the-borrow-ch…
https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html
DylanSp · 2024-12-24
Case 1 is definitely addressed by the Polonius-related work. There's a post [1] on the official Rust blog from 2023 about that, and this post [2] from Niko Matsakis' blog in June 2024 mentions that they were making progress on it, though the timeline has stretched out.
[1]: https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html
[2]: https://smallcultfollowing.com/babysteps/blog/2024/06/02/the-borrow-ch…
pornel · 2024-12-24
The problem is typically caused by &mut self methods exclusively borrowing all of self.
I wish this not-a-proposal turned into a real proposal:
https://smallcultfollowing.com/babysteps//blog/2021/11/05/view-types/
Sytten · 2024-10-26
Most of the complexity comes from the fact that all types are moveable by default. That is why I prefer this proposal to make it opt-in [1]. Working with pin really sucks the joy out of you and it won't be some sugar syntax (the current &pin mut proposal) that will help that. Rust is a fine language most of the time, but sometimes like the author you fall in rabbit holes.
[1] https://smallcultfollowing.com/babysteps/blog/2024/10/14/overwrite-and…
ameliaquining · 2024-09-11
As a counterargument, here's a good blog post (written for a Rust-centric audience) that gets into the technical downsides of exceptions (not the "error handling should/shouldn't be noisy" debate that's fundamentally subjective and unresolvable): https://smallcultfollowing.com/babysteps/blog/2024/05/02/unwind-consid…
dash2 · 2024-06-23
The "Capture" trait looks very like the following proposal for a "Claim" trait, motivated by very similar pain points:
https://smallcultfollowing.com/babysteps/blog/2024/06/21/claim-auto-an…
superb_dev · 2024-06-15
I wanted to share a technique I saw recently related to a post linked within this post: https://smallcultfollowing.com/babysteps/blog/2015/04/06/modeling-grap…
> The primary disadvantage comes about if you try to remove things from the graph. The problem then is that you must make a choice: either you reuse the node/edge indices, perhaps by keeping a free list, or else you leave a placeholder.
There’s another option, called generational indices! I discovered this from the “generational_arena” crate: https://docs.rs/generational-arena/latest/generational_arena/
legerdemain · 2024-03-02
I am confused by your responses because the "reborrowing" mechanism in the Rust compiler is pretty widely discussed.
https://smallcultfollowing.com/babysteps/blog/2013/11/20/parameter-coe…
https://haibane-tenshi.github.io/rust-reborrowing/
https://stackoverflow.com/questions/62960584/do-mutable-references-hav…
Meanwhile, you are insisting on reasoning about Rust from first principles and making lists of links to documentation that is, at best, tangentially relevant.
For example, the fact that `&T` implements Deref is not relevant here. Applying Deref::deref to a &T returns a &T. For most intents, it's a no-op.
JoshTriplett · 2023-12-21
Here's the current thinking on how to support dynamic dispatch without boxing: https://smallcultfollowing.com/babysteps/blog/2022/03/29/dyn-can-we-ma…
afdbcreid · 2023-11-12
No, this is unrelated work. But see https://smallcultfollowing.com/babysteps/blog/2021/11/05/view-types/ (only thoughts, nothing concrete or proposal).
kibwen · 2023-07-19
Nobody has lost interest, the language maintainers have been pushing on this problem for years. Scroll back through Niko's blog posts and see how many of them are related to improving async: https://smallcultfollowing.com/babysteps/
The reason that progress appears slow is because the next steps for async improvement have required extending the type system, and doing that properly (making sure not to introduce unsoundness) required a massive overhaul to the type checker, and forming an entire new team solely dedicated to the verification of the type system.
duped · 2023-06-08
"private" trait impls (1) would be a much better solution. You probably never want the impl of a trait for a foreign type to be exposed to other crates, it's so unlikely that forbidding it in the name of coherence would probably work out. But there's apparently many gotchas and no one has clearly written a way around them (2).
(1) https://github.com/rust-lang/rfcs/issues/493 (although the comment section is kind of unhinged and goes off on distant tangents to modular typeclasses and first class modules)
(2) http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-…
Georgelemental · 2023-03-27
mjw1007 · 2023-01-20
http://smallcultfollowing.com/babysteps/atom.xml looks like it works
chubot · 2022-12-11
It was/is used to prototype Rust’s borrow checking rules, which are part of a really complex type system
I heard rust author Niko mention it in a talk a few years ago, and it’s mentioned here too
http://smallcultfollowing.com/babysteps/blog/2018/04/27/an-alias-based…
kccqzy · 2022-12-01
Sorry to disappoint you but if Rust had adopted higher-kinded types they wouldn't need to write a function `try_for_each` because it would just be a generic fold-and-collect-effect function that works for all effects not just Try:
traverse_ :: Foldable t => (a -> ExceptT e IO b) -> t a -> ExceptT e IO ()
Of course I'm not saying Rust should have this (there are good reasons why this isn't a good fit for Rust, see http://smallcultfollowing.com/babysteps/blog/2016/11/09/associated-typ… but it really caught my eye that you called `try_for_each` obscure; it could have been an everyday function if it had a bit more expressiveness.
charcircuit · 2022-12-01
>redux, react are heavily influenced by concepts from functional programming
Functional programming concepts don't require learning category theory
>rust has novel concepts from type theory
Type theory isn't category theory. Rust's borrow checker was not inspired by affine types.
https://smallcultfollowing.com/babysteps//blog/2012/02/15/regions-lite…
>data engineering in the cloud age leverages a lot of algebraic concepts to achieve massive data throughput
This doesn't requite category theory and those are basic concepts from algebra that you can learn outside of the context of algebra.
>We have parser combinators, lambdas, stronger typing, map and flatmap
These don't require category theory either.
withoutboats2 · 2022-11-07
Before writing a completely asinine comment like this, you might consider that I, having been paid real American dollars to design this language, might know more than you about the relationship between GATs and HKTs and the design of Rust as a whole. Your comment evinces a total ignorance of the type theoretical issues that actually informed our decision on this issue.
Fortunately, Niko Matsakis blogged about our design discussions at the time. You can read more here and in the linked predecessor posts (at the time we were calling GATs "ATCs") https://smallcultfollowing.com/babysteps/blog/2016/11/04/associated-ty…