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). 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. I don't know much about this in C++ but I know that error handling in Go is at least as bad. On the other hand stuff like `unwrap_or` could make that much clearer without slowing anyone down. Carefully handling every case could legitimately be a needless time sink for some situations. >* 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. I don't see why this isn't fixable? It's just a lack of library support AFAICT. That's a good tradeoff here because the bugs are mostly harmless and easy to track given the constrained environment. >* 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. * I don't agree with all of tomaka's points (e.g.) but they would certainly be an issue for many game developers. * 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. * 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. Similarly, Rust might just not be a good fit for games because of some tradeoffs it makes: 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. If it's handled through bindgen, it still needs code completion support. DirectX (Windows/Xbox One) is all COM-based, which is strongly related. * C++ support- though maybe different from what application developers need. Though console support would have to come from the console vendor, anyone could work on supporting things like variable name hovering and data display. * Visual Studio integration, including code completion and debugging. 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: 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. 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. 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++. To support Rust would require not only porting the toolchain (though this wouldn't be too bad on current-gen, since e.g. For some idea of the timeline- most consoles transitioned from assembly to C around the N64/PS1 era, and then to C++ around the time it was standardized.Ī 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. I suspect the console vendors and engine/library developers would all have to be on board at some level. I honestly don't know how fundamental an issue it is.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |