3 ms·

Yes, based on a few attempts chronicled in articles from different sources, Rust is a weak choice for game development, because it's too time-consuming to refac

Yes, based on a few attempts chronicled in articles from different sources, Rust is a weak choice for game development, because it's too time-consuming to refactor.

Defletter 1y ago
Yup, this one (https://news.ycombinator.com/item?id=43824640 https://news.ycombinator.com/item?id=43824640) comes to mind. The first comment says "Another failed game project in Rust", hinting that this is very common.
bakugo 1y ago
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: https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI
- simonask 1y ago
  Basically all of those problems originate with the tradition of conflating pointers and object identity, which is a problem in Rust as soon as you have ambiguous ownership or incongruent access patterns. It's also very often not the best way to identify objects, for many reasons, including performance (spatial locality is a big deal). These problems go away almost completely by simply using `EntityID` and going through `&mut World` for modifications, rather than passing around `EntityPtr`. This pattern gives you a lot of interesting things for free.
  - bakugo 1y ago
    The video I linked to is long but goes through all of this. Pretty much nobody writing games in C++ uses raw pointers in entities to hold references to other related entities, because entities can be destroyed at any time and there's no simple way for a referring entity to know when a referenced entity is destroyed. Using some sort of entity ID or entity handle is very common in C++, the problem is that when implementing this sort of system in Rust, developers often end up having to effectively "work around" the borrow checker, and they end up not really gaining anything in terms of correctness over C++, ultimately defeating the purpose of using Rust in the first place, at least for that particular system.
    - simonask 1y ago
      Can you give an example of what problems need workarounds here? The benefits seem pretty massive, at least on the surface. For example, you can run any system that only takes `&World` (i.e., immutable access) in parallel without breaking a sweat.
ramon156 1y ago
We've only had 6-7 years of hame dev in rust. Bevy is coming along nicely and will hopefully remove these pain points
- flohofwoe 1y ago
  "Mit dem Angriff Steiner's wird das alles in Ordnung kommen" ;) As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. 6..7 years is a long time, and a single engine (especially when it's more or less just a runtime without editor and robust asset pipeline) won't change the bigger picture that Rust is a pretty poor choice for gamedev.
  - eru 1y ago
    > As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. Did they? What's your evidence? Are you including consoles? Btw, the alternatives in the 1990s were worse than they are now, so the bar to clear for eg C or C++ were lower.
    - flohofwoe 1y ago
      I was there Gandalf... ;) Console SDKs offering C or C++ APIs doesn't really matter, because you can call C APIs from C++ just fine. So the language choice was a team and engine developer decision, not a platform owner decision (as it should be). From what I've seen, around the late mid-90's, C++ usage was still rare, right before 2000 it was already common and most middleware didn't even offer C APIs anymore. Of course a couple of years later Unity arrived and made the gamedev language choice more complicated again.
      - eru 1y ago
        > I was there Gandalf... ;) You were at most in one place. My question was rather, which corners of the industry are you counting? However you are right that one of the killer features of C++ was that it provided a pretty simple upgrade path from C to (bad) C++. It's not just API calls. You can call C APIs from most languages just fine.

Yes, based on a few attempts chronicled in articles from different sources, Rust is a weak choice for game development, because it's too time-consuming to refactor.

Defletter 1y ago

Yup, this one (https://news.ycombinator.com/item?id=43824640 https://news.ycombinator.com/item?id=43824640) comes to mind. The first comment says "Another failed game project in Rust", hinting that this is very common.

bakugo 1y ago

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: https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI https://youtu.be/4t1K66dMhWk?si=dZL2DoVD94WMl4fI

simonask 1y ago
Basically all of those problems originate with the tradition of conflating pointers and object identity, which is a problem in Rust as soon as you have ambiguous ownership or incongruent access patterns. It's also very often not the best way to identify objects, for many reasons, including performance (spatial locality is a big deal). These problems go away almost completely by simply using `EntityID` and going through `&mut World` for modifications, rather than passing around `EntityPtr`. This pattern gives you a lot of interesting things for free.
- bakugo 1y ago
  The video I linked to is long but goes through all of this. Pretty much nobody writing games in C++ uses raw pointers in entities to hold references to other related entities, because entities can be destroyed at any time and there's no simple way for a referring entity to know when a referenced entity is destroyed. Using some sort of entity ID or entity handle is very common in C++, the problem is that when implementing this sort of system in Rust, developers often end up having to effectively "work around" the borrow checker, and they end up not really gaining anything in terms of correctness over C++, ultimately defeating the purpose of using Rust in the first place, at least for that particular system.
  - simonask 1y ago
    Can you give an example of what problems need workarounds here? The benefits seem pretty massive, at least on the surface. For example, you can run any system that only takes `&World` (i.e., immutable access) in parallel without breaking a sweat.

ramon156 1y ago

We've only had 6-7 years of hame dev in rust. Bevy is coming along nicely and will hopefully remove these pain points

flohofwoe 1y ago
"Mit dem Angriff Steiner's wird das alles in Ordnung kommen" ;) As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. 6..7 years is a long time, and a single engine (especially when it's more or less just a runtime without editor and robust asset pipeline) won't change the bigger picture that Rust is a pretty poor choice for gamedev.
- eru 1y ago
  > As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. Did they? What's your evidence? Are you including consoles? Btw, the alternatives in the 1990s were worse than they are now, so the bar to clear for eg C or C++ were lower.
  - flohofwoe 1y ago
    I was there Gandalf... ;) Console SDKs offering C or C++ APIs doesn't really matter, because you can call C APIs from C++ just fine. So the language choice was a team and engine developer decision, not a platform owner decision (as it should be). From what I've seen, around the late mid-90's, C++ usage was still rare, right before 2000 it was already common and most middleware didn't even offer C APIs anymore. Of course a couple of years later Unity arrived and made the gamedev language choice more complicated again.
    - eru 1y ago
      > I was there Gandalf... ;) You were at most in one place. My question was rather, which corners of the industry are you counting? However you are right that one of the killer features of C++ was that it provided a pretty simple upgrade path from C to (bad) C++. It's not just API calls. You can call C APIs from most languages just fine.