Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer
Casey Muratori | Smart-Pointers, RAII, ZII? Becoming an N+2 programmer on HackerTube: recommended by 6 Hacker News commenters across 6 separate months, 2024–2026.
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.
What HN commenters said
9 Hacker News comments link this video. Each one links back to its thread.
jackclaytonJul 2026Strongly recommends
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: ▶ this video I can confirm after exploring programming like the above video explains, that everything he says is completely true.
in “Claude Code uses Bun written in Rust now” · View on HN
gingerBillJan 2026Strongly recommends
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: ▶ this 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
in “Odin: Moving Towards a New "core:OS"” · View on HN
bsderSep 2024Strongly recommends
C and C++ are very different. I think Casey Muratori hits the nail on the head here: ▶ this 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.
in “Committing to Rust in the Kernel” · View on HN
ChrisTrenkampMay 2026Recommends
This is a hot take, but programming languages haven't progressed since the 90's. We've been conditioned to believe that if you want to be a serious programmer, you have to either use C++-style RAII (which includes Rust), or garbage collection, and there's no in-between, and C programmers are dinosaurs who can be ignored. Arena allocators are a great way to automatically manage memory allocations. You malloc a whole bunch of memory and release it all with a single free, which makes it much easier to reason about your program's memory safety. Casey Muratori has a good video talking about this. ▶ this video And about Zig, you have an Arena Allocator out of the box: [link] . And it's not just limited to that, you have debug allocators that detects memory leaks and gives you stack traces where they occurred. This isn't to say that Zig is great at everything. I think Rust is great for things like kernels, high-frequency trading systems, and authentication servers where memory safety and performance is paramount. But for things like video games, memory leaks and buffer overflows aren't that big of a deal, and Zig's "Good Enough" approach is great for those types of applications.
in “Bun ported to Rust in 6 days” · View on HN
thegeekpirateDec 2025Recommends
There's a GC library around somewhere, but I doubt anyone uses it. Manual memory management is generally quite simple, as long as you aren't using archaic languages. ▶ this video is worth a watch.
in “Zig's new plan for asynchronous programs” · View on HN
slowmovintargetMay 2025Recommends
Here's Casey Muratori on his habit of moving to ZII: ▶ this video Much better outcomes and failure modes than RAII. IIRC, Odin mentions game programming as one of its use cases.
in “Odin: A programming language made for me” · View on HN
Show 3 more comments
gingerBillMay 2025Recommends
> It seems to me... that initialization time is unlikely to be significant The thing is, initialization cost is a lot more than you think it is, especially when it's done on a per-object level rather than a "group" level. This is kind of the point of trying to make the zero value useful, it's trivially initialized. And in languages that are much more strict in their approach, it is done at that per-object level which means instead of the cost of initialization being anywhere from free (VirtualAlloc/mmap has to produce zeroed memory) to trivially-linear (e.g. memset), to being a lot more nested hierarchies of initialization (e.g. for-loop with constructor for each value). It's non-obvious why the "strict approach" would be worse, but it's more about how people actually program rather than a hypothetical approach to things. So of course each style is about trade-offs. There are no solutions, only trade-offs. And different styles will have different trade-offs, even if they are not immediately obvious and require a bit of experience. A good little video on this is from Casey Muratori, "Smart-Pointers, RAII, ZII? Becoming an N+2 programmer": ▶ this video
in “Odin: A programming language made for me” · View on HN
budroJan 2025Cites it
> And this is where Rust differs; Rust will reduce the likelihood of bugs from happening in the first place. I'm not saying Zig doesn't also do that, Rust just does it more. I'd argue that it does this a LOT more. When it comes to spatial safety, Rust and Zig are on par. However in terms of temporal safety I think Zig lags far behind Rust... along with basically every other compiled systems language. If you had to come up with a single good reason to use Rust over Zig, it would definitely be temporal safety. A majority of applications don't need this though, or can be designed such that they don't. One of my main issues with Rust is that it makes it easy to write spaghetti code that uses reference counting all over the place. I don't recommend people to use Rust until they become a "N+1 programmer" that Casey Muratori describes as "grouped element thinking" [1]. At this point, most of that programmers problems are solved and suddenly the Zig vs Rust debate becomes much more nuanced. [1] ▶ this video
in “Show HN: Uscope, a new Linux debugger written from scratch” · View on HN
Capricorn2481Dec 2025Critical
>> In Go and Rust and so many other languages, you tend to allocate little bits of memory at a time for each object in your object graph. Your program has thousands of little hidden malloc()s and free()s, and therefore thousands of different lifetimes. > Rust can also do arena allocations, and there is an allocator concept in Rust, too. There's just a default allocator, too. Thank you. I've seen this repeated so many times. Casey Muratori did a video on batch allocations that was extremely informative, but also stupidly gatekeepy [1]. I think a lot of people who want to see themselves as super devs have latched onto this point without even understanding it. They talk like RAII makes it impossible to batch anything. Last year the Zig Software Foundation wrote about Asahi Lina's comments around Rust and basically implied she was unknowingly introducing these hidden allocations, citing this exact Casey Muratori video. And it was weird. A bunch of people pointed out the inaccuracies in the post, including Lina [2]. That combined with Andrew saying Go is for people without taste (not that I like Go myself), I'm not digging Zig's vibe of dunking on other companies and languages to sell their own. [1] ▶ this video [2] [link]
in “Thoughts on Go vs. Rust vs. Zig” · View on HN