3 ms·

> I can't comment on DB because that is quite far out of my wheelhouse but regarding game engines, I've almost universally seen people revert to storing objects

> I can't comment on DB because that is quite far out of my wheelhouse but regarding game engines, I've almost universally seen people revert to storing objects in arrays and passing around "handles" which is literally pointers with extra steps... But I guess at least you are protected from some issues there. Regarding game engines, the empirical evidence shows that Bevy has been moving at least as fast as, if not faster than†, comparable C++ engines. I listed all the features I landed in the past year here: https://news.ycombinator.com/item?id=42945730 https://news.ycombinator.com/item?id=42945730 We love to argue on message boards about theoretical or anecdotal productivity of programming languages, but at the end of the day the only thing that matters is what people have actually been doing with the language, and for Rust the answer is "quite a lot, actually". †In my view, Bevy has been moving significantly faster than comparable C++ engines, but I don't need to argue that to make my point.

jpc0 2y ago
Don't take it as an attack on game engines in Rust. It really isn't, it's more an observation that people happily work around the fundamental language design and that should be an indicator to the language authors. And they are definitely listening though, when I last took a dive into Rust I faught a lot of weird borrow checker edge cases that I could easily verify as correct. The borrow checker now no longer complains about some of those cases. As I said I think it's a language maturity thing. It will get there.
- vlovich123 2y ago
  The borrow checker changes you’re talking about is several years old. The next gen borrow checker should solve the remaining annoyances but that’s years away. But I disagree that Rust code breaks down to emulating pointers by way of handles.
  - jpc0 2y ago
    Not entirely what I was saying, it's one of the patterns I've seen and those that use arrays and indexes into arrays as "handles" will also vehemently disagree with me when I say they just implemented "we have pointers at home". Those are pointers, there's slightly more protections with them but depending on how you model it use after free bugs are back on the table when doing that. At least buffer overflows shouldn't be possible since that is runtime checked.
    - vlovich123 2y ago
      It’s possible use after free isn’t actually possible because Rust’s ownership system lets you express lifetimes that the compiler enforces (or you enforce it at runtime yourself). But handles aren’t uncommon even in c/c++ - it’s nothing to do with the language and more how the author thinks the particular problem domain is best modeled.

jpc0 2y ago

Don't take it as an attack on game engines in Rust. It really isn't, it's more an observation that people happily work around the fundamental language design and that should be an indicator to the language authors. And they are definitely listening though, when I last took a dive into Rust I faught a lot of weird borrow checker edge cases that I could easily verify as correct. The borrow checker now no longer complains about some of those cases. As I said I think it's a language maturity thing. It will get there.

vlovich123 2y ago
The borrow checker changes you’re talking about is several years old. The next gen borrow checker should solve the remaining annoyances but that’s years away. But I disagree that Rust code breaks down to emulating pointers by way of handles.
- jpc0 2y ago
  Not entirely what I was saying, it's one of the patterns I've seen and those that use arrays and indexes into arrays as "handles" will also vehemently disagree with me when I say they just implemented "we have pointers at home". Those are pointers, there's slightly more protections with them but depending on how you model it use after free bugs are back on the table when doing that. At least buffer overflows shouldn't be possible since that is runtime checked.
  - vlovich123 2y ago
    It’s possible use after free isn’t actually possible because Rust’s ownership system lets you express lifetimes that the compiler enforces (or you enforce it at runtime yourself). But handles aren’t uncommon even in c/c++ - it’s nothing to do with the language and more how the author thinks the particular problem domain is best modeled.