8 ms·

Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer w

Casey Muratori and Jon Blow have pushed this concept frequently. 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. 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. 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. 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.

pdpi 3mo ago
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.
- sarchertech 3mo ago
  Casey worked on tooling for AAA games that most certainly needed “that level” of optimization. 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. You can disagree with their opinions, but they certainly have the experience to back those opinions up.
  - gf000 3mo ago
    Well, Minecraft sold far more and it's a scratch built 3d engine isn't it? Popularity is certainly not a technical achievement.
    - sarchertech 3mo ago
      Minecraft doesn't use an off the shelf engine, but I wouldn't really call Minecraft scratch built. It's built on top of LWJGL. Popularity isn't a technical achievement in itself. But what is a technical achievement is that he built a visually impressive 3d engine that worked well enough for over a million people to buy it at a time when almost no one else was doing this. Minecraft was released nearly 10 years earlier--before Unity and Unreal had completely taken over. I'm also not saying that the witness engine is somehow better than anything else out there, but it's a significant enough technical accomplishment that along with Jon Blow's other work, he has the experience to back up his opinions. I've also never seen the critique that Jon Blow is just an influencer with no relevant experience from anyone with equivalent relevant experience. I've seen other experienced game devs who disagree with him, but I've never seen them say that he doesn't have the experience to have them.
      - pjmlp 3mo ago
        Only because there are no native OpenGL bindings for Java from Khronos, hence LWJGL.
        sarchertech 3mo ago
        I don't have any experience with Java game development, but I was under the impression that LWJGL provided more than just OpenGL bindings.
        pjmlp 3mo ago
        It is indeed a bit like using SDL, however pure OpenGL bindings like JOGL have seen better days. Also, if you are doing a game in Java, you also need bindings for sound APIs, and other ones that traditionally only care about C, thus you end up with something like LWJGL anyway.
        pdpi 3mo ago
        Well, it's more than just OpenGL bindings mostly because it's bindings for a bazillion other things too. Just look at the javadoc[0]. The non-binding stuff in there is just utilities to make the bindings at least somewhat idiomatic in Java. In practice, LWJGL games are almost always just GLFW games, which I would still qualify as being pretty damn close to "from scratch". 0. https://javadoc.lwjgl.org https://javadoc.lwjgl.org
- dismalaf 3mo ago
  Dunno, the Witness had gorgeous lighting. Both have consulted for AAA too.
- torginus 3mo ago
  They really are not - there used to be whole schools of thought on how to lay out applications in memory, using the freedom of C before C++ came along, and standardized on a bunch of solutions that are controversial in some circles - stuff like vtables and exceptions are the reason C++ is banned in the kernel. And with things like Java, you have even less visibility. They made a ton of interviews with oldschool devs, and a most of them did things differently from how Jon and Casey do, but it's not like they disapprove, it's just with modern languages, you don't get the level of control to do this.
scott01 3mo ago
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. As on some references, Ryan Fleury did an episode on Wookash podcast on RAD debugger showing ECS like approach. IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising. Edit: the sibling comment just proved my last point.
- tancop 3mo ago
  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. 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. 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. 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++. 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.
  - scott01 3mo ago
    Thanks for this, I’m actually learning Rust (albeit slowly) atm, and still can’t wrap my head around how arena allocs would fit the borrow checker
andrepd 3mo ago
> Casey Muratori and Jon Blow have pushed this concept frequently 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.
- christophilus 3mo ago
  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.
- indy 3mo ago
  "coupled with a complete lack of _hard evidence_ to back up their views" 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.
- jstimpfle 3mo ago
  Apparently you're the school of dismissive person who can't even be bothered to look up their technical achievements.
  - CyberDildonics 3mo ago
    Confusing achievements in one area for evidence in another is literally an appeal to authority fallacy.
    - jstimpfle 3mo ago
      You must mean confusing achievements in the area of creating large maintainable and performant systems on the one hand, with achievements in the area of creating large maintainable and performant systems on the other hand? And let me incude Ryan Fleury here who graduated from Casey-school with honors, he is maybe the most impressive programmer I know. His work on the raddebugger is outstanding.
CyberDildonics 3mo ago
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. 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. 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++.
- andrepd 3mo ago
  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 actually recognise its shortcomings are are better positioned to give INSIGHTFUL criticism into it. 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.
- dismalaf 3mo ago
  Hate C++? They both use(d) it...
  - CyberDildonics 3mo ago
    I didn't say they don't know it.
    - dismalaf 3mo ago
      As opposed to using C, Rust, or something else (Jon eventually made Jai but Casey still uses C++). Obviously they don't outright hate it.
      - CyberDildonics 3mo ago
        They talk about hating it all the time and using some minimal subset because they have to, but the point here is not what these two internet personalities hate, it's that there isn't a technical rationale against being able to use destructors. They are hugely convenient but also completely easy to avoid if someone wants to.
tialaramex 3mo ago
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 a lot 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 plus maybe 8 allocations for the ArrayList, so 508 total. Ouch. If making a Goose was itself cheap this overhead hurts badly. But a lot 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.
- ahtihn 3mo ago
  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. Allocations are really really cheap in Java by the way, so I don't get how 500 allocations would even be an issue.
  - tialaramex 3mo ago
    When you make a local variable with a Goose in Java, that's a heap allocation Goose jim = make_a_goose_somehow(); // Java, so jim is on the Heap, no way around it When you make that variable in Rust... let jim : Goose = make_a_goose_somehow(); // Rust, jim is on the stack Now, if we make a bunch of geese, maybe in a loop, and we put them into our growable array type... ArrayList<Goose> geese = new ArrayList<Goose>(); // ... some loop eventually Goose a_goose = somehow_get_this_goose(); // That's an allocation geese.add(a_goose); But in Rust... 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);
    - 3mo ago
torginus 3mo ago
They might've pushed it, but they certainly didn't invent the idea. Although I'm not 100% familiar with their arguments. POD - objects with no behavior are pretty popular way of representing data, you can serialize and deserialize them, etc. They have a pretty big caveat in non-GC languages - if you have an object with something like a dynamic array in it, suddenly your stateless POD becomes stateful, and needs RAII otherwise you get a memory leak. No idea how they solve that without GC.

pdpi 3mo ago

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.

sarchertech 3mo ago
Casey worked on tooling for AAA games that most certainly needed “that level” of optimization. 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. You can disagree with their opinions, but they certainly have the experience to back those opinions up.
- gf000 3mo ago
  Well, Minecraft sold far more and it's a scratch built 3d engine isn't it? Popularity is certainly not a technical achievement.
  - sarchertech 3mo ago
    Minecraft doesn't use an off the shelf engine, but I wouldn't really call Minecraft scratch built. It's built on top of LWJGL. Popularity isn't a technical achievement in itself. But what is a technical achievement is that he built a visually impressive 3d engine that worked well enough for over a million people to buy it at a time when almost no one else was doing this. Minecraft was released nearly 10 years earlier--before Unity and Unreal had completely taken over. I'm also not saying that the witness engine is somehow better than anything else out there, but it's a significant enough technical accomplishment that along with Jon Blow's other work, he has the experience to back up his opinions. I've also never seen the critique that Jon Blow is just an influencer with no relevant experience from anyone with equivalent relevant experience. I've seen other experienced game devs who disagree with him, but I've never seen them say that he doesn't have the experience to have them.
    - pjmlp 3mo ago
      Only because there are no native OpenGL bindings for Java from Khronos, hence LWJGL.
      - sarchertech 3mo ago
        I don't have any experience with Java game development, but I was under the impression that LWJGL provided more than just OpenGL bindings.
        pjmlp 3mo ago
        It is indeed a bit like using SDL, however pure OpenGL bindings like JOGL have seen better days. Also, if you are doing a game in Java, you also need bindings for sound APIs, and other ones that traditionally only care about C, thus you end up with something like LWJGL anyway.
        pdpi 3mo ago
        Well, it's more than just OpenGL bindings mostly because it's bindings for a bazillion other things too. Just look at the javadoc[0]. The non-binding stuff in there is just utilities to make the bindings at least somewhat idiomatic in Java. In practice, LWJGL games are almost always just GLFW games, which I would still qualify as being pretty damn close to "from scratch". 0. https://javadoc.lwjgl.org https://javadoc.lwjgl.org
dismalaf 3mo ago
Dunno, the Witness had gorgeous lighting. Both have consulted for AAA too.
torginus 3mo ago
They really are not - there used to be whole schools of thought on how to lay out applications in memory, using the freedom of C before C++ came along, and standardized on a bunch of solutions that are controversial in some circles - stuff like vtables and exceptions are the reason C++ is banned in the kernel. And with things like Java, you have even less visibility. They made a ton of interviews with oldschool devs, and a most of them did things differently from how Jon and Casey do, but it's not like they disapprove, it's just with modern languages, you don't get the level of control to do this.

scott01 3mo ago

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. As on some references, Ryan Fleury did an episode on Wookash podcast on RAD debugger showing ECS like approach. IMO, their RAII critique is a but nuanced, but because of their personality the discourse often gets polarising. Edit: the sibling comment just proved my last point.

tancop 3mo ago
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. 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. 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. 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++. 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.
- scott01 3mo ago
  Thanks for this, I’m actually learning Rust (albeit slowly) atm, and still can’t wrap my head around how arena allocs would fit the borrow checker

andrepd 3mo ago

> Casey Muratori and Jon Blow have pushed this concept frequently 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.

christophilus 3mo ago
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.
indy 3mo ago
"coupled with a complete lack of _hard evidence_ to back up their views" 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.
jstimpfle 3mo ago
Apparently you're the school of dismissive person who can't even be bothered to look up their technical achievements.
- CyberDildonics 3mo ago
  Confusing achievements in one area for evidence in another is literally an appeal to authority fallacy.
  - jstimpfle 3mo ago
    You must mean confusing achievements in the area of creating large maintainable and performant systems on the one hand, with achievements in the area of creating large maintainable and performant systems on the other hand? And let me incude Ryan Fleury here who graduated from Casey-school with honors, he is maybe the most impressive programmer I know. His work on the raddebugger is outstanding.

CyberDildonics 3mo ago

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. 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. 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++.

andrepd 3mo ago
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 actually recognise its shortcomings are are better positioned to give INSIGHTFUL criticism into it. 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.
dismalaf 3mo ago
Hate C++? They both use(d) it...
- CyberDildonics 3mo ago
  I didn't say they don't know it.
  - dismalaf 3mo ago
    As opposed to using C, Rust, or something else (Jon eventually made Jai but Casey still uses C++). Obviously they don't outright hate it.
    - CyberDildonics 3mo ago
      They talk about hating it all the time and using some minimal subset because they have to, but the point here is not what these two internet personalities hate, it's that there isn't a technical rationale against being able to use destructors. They are hugely convenient but also completely easy to avoid if someone wants to.

tialaramex 3mo ago

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 a lot 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 plus maybe 8 allocations for the ArrayList, so 508 total. Ouch. If making a Goose was itself cheap this overhead hurts badly. But a lot 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.

ahtihn 3mo ago
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. Allocations are really really cheap in Java by the way, so I don't get how 500 allocations would even be an issue.
- tialaramex 3mo ago
  When you make a local variable with a Goose in Java, that's a heap allocation Goose jim = make_a_goose_somehow(); // Java, so jim is on the Heap, no way around it When you make that variable in Rust... let jim : Goose = make_a_goose_somehow(); // Rust, jim is on the stack Now, if we make a bunch of geese, maybe in a loop, and we put them into our growable array type... ArrayList<Goose> geese = new ArrayList<Goose>(); // ... some loop eventually Goose a_goose = somehow_get_this_goose(); // That's an allocation geese.add(a_goose); But in Rust... 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);
  - 3mo ago

torginus 3mo ago

They might've pushed it, but they certainly didn't invent the idea. Although I'm not 100% familiar with their arguments. POD - objects with no behavior are pretty popular way of representing data, you can serialize and deserialize them, etc. They have a pretty big caveat in non-GC languages - if you have an object with something like a dynamic array in it, suddenly your stateless POD becomes stateful, and needs RAII otherwise you get a memory leak. No idea how they solve that without GC.