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

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]

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]

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.

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.

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]