> I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames
The game developer community is actually one of the communities that jumped onto Rust really early, well before it hit 1.0.
The game developer community is actually one of the communities that jumped onto Rust really early, well before it hit 1.0.
> Memory safety is not a problem in game development, they will just patch the bugs.
You must not have played any Bethesda titles. That said, there is much more to Rust than memory safety. That's just a side effect of the safe parallelism -- it's a minor story.
Did you ever seen AAA game source code?
> You must not have played any Bethesda titles.
I've played. Most bugs I've seen were logic errors, doesn't matter which language you would pick.
I (and I presume many others) would appreciate it if you would stop making grand, unfounded assertions about what Rust is good for. Games do make very different tradeoffs from most software- type and memory safety aren't an obvious, uncontested win there.
> stop making grand, unfounded assertions about what Rust is good for
You are basically stating that everything that I have done in Rust is a lie. I will not stand for that.
Nobody here, least of all me, has claimed that Rust cannot be used for any game at all, nor have they disputed your own experiences. Grow up.
> I would love to use Rust in games (I currently work in games) but it's not clear that it would work out.
There are many contradictions in your posts on here.
* Destiny's Multithreaded Rendering Architecture: https://www.youtube.com/watch?v=0nTDFLMLX9k
* Multithreading the Entire Destiny Engine: https://www.youtube.com/watch?v=v2Q_zHG3vqg
The problem (speaking as someone working on a console game at a AAA studio) is more likely that it's not officially supported. Console SDKs include C++ toolchains and C++ libraries, and there's a lot to lose by trying to bypass that, especially on a game project schedule.
The support thing makes total sense. Do you think it's fundamentally insurmountable? I'm pretty sure this is an area where the team itself has a blind spot, or maybe rather, just doesn't have the necessary expertise to even know what we'd need to do to make this possible.
A move away from C++ would probably be significantly higher-effort than the move to it- C++ can not only trivially call C APIs but can also compile most C code without modification. To support Rust would require not only porting the toolchain (though this wouldn't be too bad on current-gen, since e.g. the PS4 even uses Clang), but really working well with the console SDKs, and third-party libraries and middleware, which are all written in C++.
It would probably also be a much tougher mindshare hill to climb- even C++ took a long time to be accepted, and its standard library still isn't. Vulnerabilities are not really an issue for games the way they are for, say, browsers, since games' inputs and environments are so constrained and there's often no real consequences worse than a player losing their save file.
So from my perspective (which to be fair is relatively new to the industry) these might be the most important features for getting Rust into games:
* Visual Studio integration, including code completion and debugging. Though console support would have to come from the console vendor, anyone could work on supporting things like variable name hovering and data display.
* C++ support- though maybe different from what application developers need. DirectX (Windows/Xbox One) is all COM-based, which is strongly related. If it's handled through bindgen, it still needs code completion support.
* SIMD, inline assembly, etc. This stuff gets used all the time for performance, and for a lot of it portability is not a concern, because things are handled differently per-platform anyway.
Similarly, Rust might just not be a good fit for games because of some tradeoffs it makes:
* Games can't get by with just malloc-style memory management- and while it's easy to mess up, C and C++ handle arenas/pools/etc with far less friction than Rust, where you'd want to package up every little pointer thing behind a safe API. That's a good tradeoff here because the bugs are mostly harmless and easy to track given the constrained environment.
* Maybe error handling? (Mostly devil's advocate at this point.) The games I've worked on tend to just assert in debug mode and ignore errors in production. Carefully handling every case could legitimately be a needless time sink for some situations. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down.
* I don't agree with all of tomaka's points (e.g. https://www.reddit.com/r/rust/comments/616rc8/rcpp_discusses...) but they would certainly be an issue for many game developers.
I don't see why this isn't fixable? It's just a lack of library support AFAICT.
>* Maybe error handling? (Mostly devil's advocate at this point.) The games I've worked on tend to just assert in debug mode and ignore errors in production. Carefully handling every case could legitimately be a needless time sink for some situations. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down.
I don't know much about this in C++ but I know that error handling in Go is at least as bad. Rust's fancy type system should in theory make error handling easier if you use it correctly (that's supposed to be an advantage of type systems after all) but it requires not just understanding how the type system can be used for error correction but a way of integrating that knowledge into development methodologies. This has to be developed by the teams themselves although it also forms a part of the collective knowledge base of the programming community (most of us are familiar with unit tests in imperative languages at this point).
>* I don't agree with all of tomaka's points (e.g. https://www.reddit.com/r/rust/comments/616rc8/rcpp_discusses...) but they would certainly be an issue for many game developers.
Just guessing:
>The biggest is probably the fact that it's impossible to safely put a borrowee and a borrower in the same struct. This has very deep consequences on API design.
You should probably use `unsafe` for this. As noted, you're flying blind if you do this in C++ as well. It's possible that some partial solutions will be implemented but I doubt that the project will cover every possible use case. The reason that this isn't in safe Rust is that it's very hard to reason about when this is and isn't safe. An issue is that people have difficulty reasoning about the behavior of unsafe Rust because of its unfamiliar semantics.
>No decltype is really a deal breaker as well. The core team has recently added the -> impl Trait syntax because iterators and futures were too annoying to deal with. I'm manipulating types that are ten times worse than iterators, and I have to put them in my structs.
Holy pretty printer Batman! Let me see:
>When you write struct Foo<T: Trait> it's the user of the struct that choose what T is. In my code I have a very precise type that I want to put in the struct, I just can't express it in the source code because it's too long. I don't want the user to choose this type for me, this is totally difference.
I think this could be fixed in exactly the way that tomaka wants it to be fixed, by allowing type aliasing which is limited to a particular lexical scope. Since this is basically equivalent to creating a trait which is only implemented by a single type (which he could in theory do but it's very awkward) it shouldn't introduce any new complexity to the type system.
Tomaka's other points are being fixed. Rust is a very large undertaking...
Libraries could help, but game often have a lot of one-off memory stuff too that you can't put in a library and you can't do in safe Rust. Maybe there are some more creative solutions that nobody's had to come up with yet because C makes it so frictionless.
> error handling in Go is at least as bad
The thing is that style lets you ignore errors in cases where the error isn't gonna happen. That's usually bad, but in games it's often fine because you control everything. The equivalent in Rust requires an `unwrap` of some kind which introduces performance and syntactic overhead.
I guess all I'm getting at is that beyond the implementation, there is still design work to be done if we want Rust to work well for games.
The contradiction in your logic here is that if you don't want to handle errors, then don't design your functions to return errors. In addition, many of the larger time game studios write and use their own standard library, so they could devise an efficient 'game stdlib' where they don't have to pay such costs.