I wish they wouldn't do that.
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.
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.
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.
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. Language aims to have minimal std, and facilitate using libraries. C++ ends up having a bloated std library that still doesn't do half the things you want it to, you are constantly forced to use other libraries, and using other libraries is non trivial compared to rust.
-
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. C++ rules and 1000 page+ long legalese prevent C++ from being faster, 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.
Safety isn't why I come to rust; it's
(i) no header files
(ii) traits instead of classes
(iii) propper immutability
(iv) better lambdas
(v) better macro system
(vi) enum/match (i didnt' come for it but after discovering it, that's kept me)
That's a fair question. I agree that right now, using a commercial C/C++ game engine (either by writing bindings or giving up on Rust entirely) is likely the fastest way to build a "modern" looking game. But there are a bunch of reasons you might not want to do that. Even ignoring safety, using APIs intended for Rust is going to be much more pleasant than whatever you'd get from FFI to C. And other commenters have already mentioned why they feel Rust is nicer to work in than other alternatives. Further, you won't have to worry about royalties given that the Rust ecosystem is open source, and FFI bindings don't play nice with tooling.
If anyone wants to help bring more sponsorship 
into the Rust gd ecosystem, adding Rust support to BackYourStack would be an outstanding contribution:
As @repi from Embark studios puts it:
The Rust ecosystem is growing fast and quite a few crate maintainers in the community are on Patreon, though almost none on opencollective yet unfortunately.
More and more companies are using Rust also, including the one I'm at (Embark), and I would love to have an easy way to sponsor and support any crates that we use, and for other companies and individuals to the same as well.
On a different note, anyone looking for example games written in the Rust+Amethyst variety can now find an exhaustive list here:
https://community.amethyst-engine.org/t/games-made-with-amethyst/134?u=erlend_sh
I also put together something for Rust on N64. (Still unpublished/WIP.) I didn’t see any links to the github group though. Mind sharing it here?
Oh! Yes, of course. Well, the link is https://github.com/rust-console, but the way that github groups work is I’ll have to add each person that wants to actually be in the group.
Thanks for the reminder. I pinged https://github.com/Igor1201/rusted-switch about this effort as well.
oh dag! I’ll make sure the Megaton Hammer folks know about that and about this thread and stuff
I just published my personal take on next steps for this working group:
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.