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

I thought this was going to be a response to Jonathan Blow's video about how doing your own memory management is effectively turning off the borrow checker: [VIDEO] The takeaway being that the borrow checker doesn't magically prevent the use-after-free class of bugs. Although you will never experience a segmentation fault in safe Rust, the bug is still there and your program keeps running in an invalid state. The symptoms are changed, but no less dangerous. To make the problem even more obvious, think of allocating a large array to be used as a heap and handing out indices to implement your own malloc. You have bounds checking to prevent indexing outside the bounds of the heap, but it doesn't really help when the elements have logically different lifetimes and occupy different parts of the array. I don't think this is a contrived example either. A less obvious version of this can easily creep into large or complex systems, as evidenced by the Entity Component System in Rust example.

This was extensively discussed on reddit and a few other places (not HN afaik, or I couldn't find the thread), after the video^ Jonathan Blow posted on the topic. I think the tldr; is, opinions vary. Using indexes manually doesn't by-pass the borrow checker, its just a different, manual, memory allocation and management strategy. It preserves memory-safety, but, it's questionable if you're better or worse off in terms of correctness of application logic when you use it. ...you're probably better off using the borrow checker (that's why it exists) or an abstraction in a crate to deal with this sort of problem, regardless of whatever implementation strategy it uses internally (unsafe, this, etc). [1] - [VIDEO]

And the response by Jonathan blow [VIDEO] One of his points is that you still have to solve synchronization for allocations and deletions from the arrays.

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): [VIDEO]

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

I just recently came across these two videos. Using Rust For Game Development by Catherine West: [LINK] Counter-rant from Jonathan Blow: [VIDEO]

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. [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. [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]

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.

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: [VIDEO]

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 [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] [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] [VIDEO]

I find that Jonathan Blow ranting about Rust game development here [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.

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: [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