A working group for Rust game development?


#21

#22

I wish they wouldn’t do that.


#23

I haven’t followed the state of Rust game development in the past year or so, but to me the three major lacking areas when I left were basically:

  • No way to easily create a task system like most commercial game engines use. I guess this could now be done with procedural macros.
  • Still no safe way to have graphics. All the graphics crate right now are at least partially unsafe. I’m a bit confused as to why people are so keen on using Rust if it’s not to rely on total safety.
  • The debate about UI is still raging. However to be fair this is the case in IT and game development in general, and not specific to Rust. There is no straight-forward not-relying-on-graphics crate that is able to handle the user interface.

#24

I actually feel the opposite way. Worrying about safety in graphics APIs seems wasteful, both in terms of costly runtime checks and it terms of development time. When I’ve done graphics programming in C++, memory safety was almost never an issue. On the other hand AFAIK, we don’t have any rust graphics APIs that have hit 1.0, and two of the crates with perhaps the most momentum behind them (gfx-hal and rendy) haven’t even had any releases at all yet.


#25

But if you don’t really care about safety, why not use bindings to an existing game engine or graphics engine that exists in C/C++? It’s also the best way to save development time.


#26

I don’t disagree with you that safety is a good thing in rust and should also be utilized in game development, but there are far more reasons why I would use rust rather than C++ in game development even ignoring the safety story in rust:

  • Once you get past the borrow checker, it is often much easier to write.
  • Often easier to read
  • Easier to do many tasks in rust, because rust just has this functionality in the library,
    • string manipulation (yes, there are some things there, spread between C++ and C, but it leaves out a woeful lot of functionality that people continuously have to re-implement)
    • file system (until c++17)
    • ranges (until c++20)
    • slices(until c++17, and even then, not fully implemented)
    • optional (until C++17)
    • any (until C++17)
    • variant (until C++17)
    • byte (until C++17) Keep in mind that during the CPP con during september 2018, IIRC surveys showed less than 20% users even used C++17, and MSVC has blocked many from switching (since they continue to lag behind in standard supported features despite claiming C++XX compliance). Also note this is only the stuff which overlaps with newer versions of C++, there are many more things Rust has that C++ just doesn’t or won’t ever have.
  • Rust, surprisingly, has much better built in facilities in the library to do bit manipulation than C or C++. For real I roll my eyes when any C or C++ dev yaps about how “easy it is to manipulate bits!”.
  • Easier to use other libraries
  • Easier to accomplish concurrency
  • Easier to use SIMD
  • Better Macros, though with out const generics, C++ has a better compile time story (at least for my use cases).
  • Faster in many circumstances than C++ where it shouldn’t be, but C++ rules and 1000 page+ long legalese prevent, especially when dealing with object construction, and passing objects around (C++ really isn’t zero overhead when it really should be).
  • built in build system supported by language team
  • built in package manager supported by language team
  • modules
  • amazing comment system and documentation generation system
  • Only one compiler per system to worry about (for now), though Rust still doesn’t technically have a stable ABI either.
  • Again, seriously, I don’t think people realize just how easy it is to manipulate bits in Rust compared to C and C++