Casey Muratori and Jon Blow have pushed this concept frequently.<p>They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work.<p>My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it.<p>In my experience, RAII is my preferred pattern for certain things (std::lock_guard), and you can almost certainly express the majority of these "uber game dev patterns" using RAII/smart pointers/etc, but the c++ implementation of these "uber game dev patterns" tends to be more complicated (and imo esthetically ugly) compared to really well written C.<p>These new languages (zig, odin, jai) appear to be attempts to improve C to allow an alternative to C++ that doesn't have the ugly baggage that C++ has.
From what I understood, their critique of RAII is twofold: coupling of allocation and initialisation, and enforcement of deallocation. The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts. Also I remember they mentioned it’s not necessary to free memory if you’re about to close your program, because the OS will take the memory back. Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.<p>As on some references, Ryan Fleury did an episode on Wookash podcast on RAD debugger showing ECS like approach.<p>IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising.<p>Edit: the sibling comment just proved my last point.
most of that criticism only works on C++. rust does enforce RAII but uses stack allocation for locals by default instead of touching the heap so it skips the slow part.<p>on the other hand there are no constructors (just normal functions) so you cant initialize values in place, only stack allocate and return. i think rust needs to add in place init and change the rules from "always init at declaration site" to "must be initialized at first use" like kotlin.<p>the big missing piece is custom allocators that let you use something like a bump arena with the same convenience as system malloc. they already exist on nightly but nobody knows when they will land on stable.<p>honestly thats the biggest problem with rust, they come up with a lot of useful changes but then take ages to stabilize because the core team is overworked. they also have a kind of perfectionist culture as a reaction to all the half baked features shipping in C++.<p>there should be a stage between nightly and full release where feature is in stable toolchains behind a cfg flag and you get a warning if upstream crates use it. show commitment to shipping it in time but still make it clear that it can change (in minor incompatible ways) before release.
<i>The ease of use of smart pointers makes it tempting to allocate/free of temporary structures even within one single function. Given enough number of such occurrences, it kills performance by a thousand cuts.</i><p>This isn't true and doesn't make any sense. Smart pointers don't need to enter into it. If you need a lot of something you make a vector and allocate once.<p><i>Also I remember they mentioned it’s not necessary to free memory if you’re about to close your program, because the OS will take the memory back.</i><p>It is an extremely niche scenario to need a program to shut down so much faster that you can't even deallocate memory. If you don't make lots of small allocations in the first place the deallocations won't take any time.<p><i>Obviously you need to gracefully deinitialise some things, like audio or other devices, but that’s beyond the discussion.</i><p>It's actually a pretty big advantage to destructors to deal with stuff like this as well as memory and locks.<p><i>IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising.</i><p>I think it gets polarizing because they are both undeniably sharp programmers but don't have any real evidence of this stuff, they are just grasping at rationalizations.
Casey spends a lot of effort on what he considers an anti-pattern where you're making a huge number of separate objects. I think <i>a lot</i> of this comes from Java, a language where all the user defined types actually are obliged to be heap allocations. If I make a Goose type, and I say I want a Goose, Java will allocate space on the heap for the Goose and put my Goose there, that's really how Java works. If I make a growable array of them ArrayList<Goose>, and add each of 500 geese, that's 500 allocations for geese <i>plus</i> maybe 8 allocations for the ArrayList, so 508 total. Ouch. If making a Goose was itself cheap this overhead hurts badly.<p>But a <i>lot</i> of languages aren't like that, and so this doesn't translate. Obviously in Rust with Vec<Goose> that's only 8 allocations, each local Goose lives in the stack - or, if you knew up front there were 500 geese, you Vec::with_capacity(500) and it's a single allocation - but similar is true in many languages, Java is an outlier.
Java doesn't mandate the usage of a heap - it can in certain cases avoid doing so and allocate on the stack (escape analysis).<p>Besides, as mentioned java's allocations are much closer to something like using an arena in a low-level language, then a "slow" malloc. It uses thread-local allocation buffers, where you have a large buffer with a pointer pointing to the start of the free region. Allocation is just a pointer bump, not even needing synchronization since it is per a single thread. As it gets full, the GC moves out still alive objects <i>in the background</i> and resets the buffer.<p>This is pretty much the most efficient one can be after per-object type arenas and simply not allocating.
Maybe I'm missing something but when would the 500 geese instances ever be stack allocated in Rust? That comparison seems unfair, the lifetime of that kind of object isn't going to be compatible with stack allocation.<p>Allocations are really really cheap in Java by the way, so I don't get how 500 allocations would even be an issue.
When you make a local variable with a Goose in Java, that's a heap allocation<p><pre><code> Goose jim = make_a_goose_somehow(); // Java, so jim is on the Heap, no way around it
</code></pre>
When you make that variable in Rust...<p><pre><code> let jim : Goose = make_a_goose_somehow(); // Rust, jim is on the stack
</code></pre>
Now, if we make a bunch of geese, maybe in a loop, and we put them into our growable array type...<p><pre><code> ArrayList<Goose> geese = new ArrayList<Goose>();
// ... some loop eventually
Goose a_goose = somehow_get_this_goose(); // That's an allocation
geese.add(a_goose);
</code></pre>
But in Rust...<p><pre><code> let geese: Vec<Goose> = Vec::new();
// ... some loop eventually
let a_goose : Goose = somehow_get_this_goose(); // But this is not
geese.push(a_goose);</code></pre>
Memory is memory, stack is not a unique hardware element. It just tends to be hot, but so can certain part of "the heap".<p>Of course this is a toy example, but were the compiler not smart enough (it is surely smart enough in this case) then the "too simple rust" version may actually be slower - it would allocate a Vec on the stack, but only a length, capacity and a pointer is stored there, the actual backing array is on the heap. Then it would create stuff on the stack, and copy over those bytes to the heap, object by object (it's a move).<p>Meanwhile the java version would have a continuous region of memory, next to it it would have objects, and it would just write pointers to said objects without moving/copying anything.<p>Surely enough rust is smart enough to optimize out this useless move in this case, but I think you are painting a way too simplified picture here.
Casey Muratori and Jon Blow are both hyper-dogmatic "my way or the highway" types, and, crucially, neither of them has built any of the super high fidelity types of game that would require that level of optimisation. They're basically influencer types.
Casey worked on tooling for AAA games that most certainly needed “that level” of optimization.<p>Jon Blow worked on numerous AAA games that required “that level” of optimization. And he’s one of the very few developers in the last 15 years who have managed to sell more than a million copies of a game running on a scratch built 3D engine.<p>You can disagree with their opinions, but they certainly have the experience to back those opinions up.
Dunno, the Witness had gorgeous lighting. Both have consulted for AAA too.
I think those guys both hate C++ so much that they want to dismiss everything about it instead of using all the features that work for them like most people.<p><i>My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it.</i><p>They might say this, but there isn't a good technical rationalization here since anyone can create a global data structure just as easily in C++.
Exactly! The most interesting arguments for Rust that I've ever read have come not from people who hate C++, but precisely from people who are really into C++, because those are the people who <i>actually recognise its shortcomings</i> are are better positioned to give INSIGHTFUL criticism into it.<p>People who are motivated by a superiority complex or by the wish to impress a herd of twitter followers hardly if ever produce a thought I want to read.
Hate C++? They both use(d) it...
> Casey Muratori and Jon Blow have pushed this concept frequently<p>Ah... The school of what I like to call "maximum opinions and minimal evidence". Aggressive arrogant dismissal of anything except their exact view (and for Muratori, you're also "woke" for good measure), coupled with a complete lack of _hard evidence_ to back up their views. In that regard, they're not unlike "investment advice" instagram influencers.
"coupled with a complete lack of _hard evidence_ to back up their views"<p>Didn't Casey Muratori write a proof of concept windows terminal to highlight Microsoft's substandard implementation? And Jonathan Blow has spent the past decade+ developing his own programming language and funding the development of a game. Seems like they are backing their views.
I can see why you would think that about Jon Blow, though I disagree. But Casey? He has a number of thorough videos with plenty of evidence, and has never struck me as arrogant.