Rant: Entity systems and the Rust borrow checker ... or something.

I find that Jonathan Blow ranting about Rust game development here ▶ this video . He adds interesting perspectives to the discussio, how the language makes the Rust game developer resort to arrays and their so called Rust point of views.

These discussions always remind me of some talks by Jonathan blow where he argues rust doesn’t solve the hard problems he needed it to. There are podcast episodes with better discussions, but the main one people link to seems to be this I haven’t used rust, but I sympathize with his problems with pointers and learned a lot from the various ways people try to solve them ▶ this video

Pointers living through a render pass aren't the main use case he is interested in. It's a problem space that many engineers are familiar with so it's easy to talk about. Game developers have some very domain-specific problems that are less common outside of game engines. A more detailed description of his opinions are laid out here where he goes into much more detail about his experiences porting The Witness to mobile (I think): ▶ this video

> What features in Jai make it superior to C++ for writing games specifically? I know that Jonathan Blow can be abrasive and one-sided in his talks on programming, but I think we should be open-minded about Jai. Yes, he is making this language because he doesn't like C++, but you make it sound like he is hating on C++ just for the sake of it. I mean, is it really so hard to imagine that someone might not like something about C++? There are plenty of people who think we could have a better systems language, which is why we have seen languages like Rust, Zig, and Odin pop up. In Blow's case, he has said that he doesn't like Rust because he feels that satisfying the borrow-checker slows down iteration time[1], which is important especially in the early stages of game development when you are still experimenting with mechanics are where requirements and architecture are still very much subject to change. As far as what Jai offers, it seems his focus is on making a simple but powerful language (contrary to C++'s ever-growing bag-of-tricks), with fast compile times (less than 3 seconds on a full build of his new game), better build and dependency management (no more cmake), and powerful meta-programming features. In a talk on the language[2], he demos how he is able to use the language's meta-programming features to develop powerful code-analyzing and memory-analyzing tools. These tools, in particular, hint at his philosophy: lots of ideas in programming like RAII, garbage collecto

There's also the fact that a lot of patterns that are commonly used in game development are fundamentally at odds with the borrow checker. Relevant: ▶ this video

ECS can be implemented in any language, it's orthogonal to my comment re: why Rust for gamedev? ECS is such an obvious concept, it's akin to file descriptors and PIDs on *NIX; an indirection table for handles, :slowclap:. There's nothing Rust-unique about it. The amount of hype I see surrounding ECS like it's some kind of groundbreaking amazing thing, often muddled into "Rust for gamedev" conversations, causes me to question everything said in such pro-Rust discussions. Blow actually responded to the keynote you linked [0]. What's still unclear to me is what's the advantage that Rust is bringing to the table? Is game development velocity higher than in C++/C/C#? The ecosystem is obviously less mature, and the borrow-checker is an obvious source of friction... How do we separate the hype from the facts? [0] ▶ this video

This is really impressive work and I applaud the author for building something that I'm sure lots of folks will find interesting and possibly very useful, but I want to say that I think there's a reason reference semantics (using and sharing heap allocations) are hard in Rust: It's because references are just plain hard to use safely. Rust tries to make the gnarly things awkward, but what is the easy path? If you look at the Hylo (formerly Val as of 3 days ago) language [0] that folks like Dave Abrahams have been working on, they're outright saying to just not use reference semantics if you can avoid it. In this talk at CppCon about Value Semantics, Dave argues that we should be decoupling object graphs from access to objects [1]. That's right folks, using `usize` indexes into collections, or adjacency lists, isn't just a hack to get around the borrow checker as people like Jonathan Blow have famously critiqued [2], it may just be the right way of doing things . [0] link [1] link [2] ▶ this video

Right, it sounds like you are circumventing the borrow checker and then experiencing some of the classes of bugs it was supposed to prevent. And this seems common: ▶ this video

The hvasilev's comment got flagged and I could not reply to it anymore, so I'll reply here (sorry) and copy-paste the hvasilev's comment verbatim below, for the sake of commenting on it's claims: --- Reality is not on the side of this language. 11 year old, has a very low adoption with virtually no jobs associated. ( link ) On the other hand if you search for "Rust" in the latest "Who wants to be hired?" thread, you will see it is quite popular with unemployed people. The reality is that the language has a lot of friction, the ergonomics are bad, the syntax is heavy and some poor decision making has been made there for a systems-level programming language. There are a lot of ideological traps in this industry and many people that fall for them. Why people are interested in ideologies and cults is beyond me. [ A screenshot: link ] --- <rant> Now my comments on the issues mentioned in the hvasilev's comment. > Reality is not on the side of this language. 11 year old, has a very low adoption with virtually no jobs associated. ( link ) Tiobe index is shit. The most flattering thing I've read about it states that it (poorly) depicts quantity of educational materials available online for particular programming language. Unfortunate naming of programming languages after letters of alphabet, symbols (++, #) and real-life stuff (like islands) doesn't help this rating either. That said, Rust isn't that popular and isn't growing much according to other better language ratings: 1.

On why ECS gets in the way for him: > Because it is far more complicated, thus takes far more work, than what you actually need to do. That work has a large opportunity cost. link To me this has more nuance than, “you ain't gonna need it”. I don't think “concrete implementations” would do all that much to strengthen his argument that unnecessary complexity gets in the way of shipping for indie devs: > Even 10% friction more than I ever had would have killed me. I wouldn't have been able to make the things I had. Even 5% more friction would have been really bad. ▶ this video And… > I have, several times, built games where I barely managed to finish. … I've just experienced that too many times to increase friction. I need to decrease friction. ▶ this video And again, in relation to entities rather than Rust's borrow checker: > If you are trying to focus on the way your entities are set up, you are mis-directing your effort and that's going to make it harder. Try to solve the problem that makes your game interesting. What is it about the gameplay that makes it interesting … that users can see? Focus on that, solve those problems. link On what he uses instead of ECS/components in his engines: > One struct per entity type, with a base struct that is common to all of them. link

I just recently came across these two videos. Using Rust For Game Development by Catherine West: link Counter-rant from Jonathan Blow: ▶ this video

Jon Blow addresses this in some earlier rant here: ▶ this video His point being that now you're effectively implementing a form of manual memory management to circumvent the borrow checker.