HackerTube.dev

Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer

xDahl · 162.8K views · 2024-07-13 · 30:12

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

Casey Muratori argues against smart pointers and RAII, advocating grouped-element thinking, zero-is-initialization and stubs as better ways to structure memory and handle errors.

On Hacker News

HN commenters in memory management and language design threads cite it as the best explanation of group lifetimes versus per-object ownership.

Recommended by 6 HN people across 6 months · HN mentions 2024–2026

Topics

Search by tags

What people said

jackclayton · 2026-07 · Strong recommendation

Above poster is talking about thinking in terms of grouped lifetimes and bulk allocations/deallocations, which is better for performance, and makes Rust borrow checking and other RAII style features completely pointless as they don't add any safety benefits. I used to think like you until I watched this video: [VIDEO] I can confirm after exploring programming like the above video explains, that everything he says is completely true.

Read the original HN comment ↗
gingerBill · 2026-01 · Strong recommendation

Unfortunately I don't think you've understand what I was I trying to say. Rust was designed from day-0 around explicit individual-value based initialization. Odin from day-0 was not designed around this (explicitly). This ever so minor choice might not seem like a big thing to you, as you have stated in your comment, but it leads to MASSIVE architectural decisions later on when the user programs. Odin could not "just add" non-nil pointers and it be "fine". It would actually not be Odin any more, and the entire language would not even be a C alternative any more, and feel much more like C++ or Rust. Rust and OCaml (which Rust is based off) are different kinds of languages to Odin and their approach does not translate well to what Odin (or C) is trying to do. Unfortunately I will not be able to explain this to you in a comment or article, and it is something that takes a while to understand since it is a subtle effect of locality affecting globality. The best video on this might be from Casey Muratori: [VIDEO] > Yes, initialization can be less efficient in Rust but then most of the time spent is spend in algorithms when they run, not during initialization of the data structure. Sadly this isn't as true as you think it is. I've written a lot of C++ code before and doing its boilerplate for ctors/dtors actually leads to much slower code in general, and I'd argue this does apply to Rust too. Most of the time isn't necessarily spent in "algorithms", especially when "algorithms" als

Read the original HN comment ↗
bsder · 2024-09 · Strong recommendation

C and C++ are very different. I think Casey Muratori hits the nail on the head here: [VIDEO] In short, RAII and smart pointers and borrow checker are all signs of "individual element thinking" and that way lies madness. You smear out lifetime and ownership so badly that it practically by definition becomes a problem. Your goal is to think about this stuff in groups to make thinking about allocation way, way easier. Programming is all about abstracting to the next layer. I'm not sure he has quite gotten to the heart of the issue, yet. However, a bunch of smart people (Casey Muratori, Jonathan Blow, Andrew Kelley, etc.) are all dancing around something that Rust and C++ don't seem to fit the bill on. Hopefully they can crystallize it out so that everybody can see it.

Read the original HN comment ↗

Sources

Video by xDahl, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources