4 ms·
As someone in the games industry, I don't see anybody moving towards either of these languages over C++, or really even any excitement over them. I'd be very su
by yoklov 11y ago
As someone in the games industry, I don't see anybody moving towards either of these languages over C++, or really even any excitement over them. I'd be very surprised if Rust displaces C++ here, and put the chance of Go doing so at pretty much 0.
If anything, the current trend is moving more low level (rather than higher level, which these languages both are), as techniques like data oriented design becoming more mainstream.
- steveklabnik 11y ago> (rather than higher level, which these languages both are) Rust should be (and is, modulo wrinkles, I mean there's no fundamental reason) as low level as it gets. What makes Rust too high-level for gamedev?
- Sharlin 11y agoI guess Rust has many features people are only used to seeing in high level languages - and to some people that equals "too much abstraction" which equals "slow". But the thing is - Rust's "high-level" features are all compile time with either no or very little runtime overhead.
- mike_hearn 11y agoIt's probably not too high level for game dev. However, modern AAA game dev is largely about customising and upgrading large existing game engines, which are all C++ based. Rust could be used for them, but isn't, and the extra features Rust brings are not compelling enough to rewrite huge amounts of working code and suffer (re)training costs. This is a hole many new languages find themselves in. JetBrains have come up with a very clever solution for their Java/Scala competitor Kotlin: the language was carefully designed from the ground up with perfect Java interop in mind (Java/Kotlin call into each other seamlessly, the IDE can refactor across languages, Kotlin uses the same standard library etc). And quite amazingly, the IDE can automatically rewrite Java into Kotlin. This isn't a party trick, it works very well. I think if Rust wants/wanted to be a serious competitor to or upgrade path from C++ it'd have needed to take at least some level of C++ interop into account from the start such that Rust and C++ could be intermixed freely. AFAIK though, the best you get is a typical C export/import layer which is too trivial to be compelling. Of course, it's a lot harder than connecting with Java because of the way C++ stuff is defined using header files. But at least basic interop could have been done.
- steveklabnik 11y agoYes, this is a good point about AAA. The issue with interop is on the C++ side, unfortunately, not our side. Until C++ has a well-defined ABI, it's not really possible.
- mike_hearn 11y agoC++ has a well defined ABI on many important platforms. On GCC/LLVM based platforms it's standardised in specification documents. On Windows, I think the Visual C++ ABI is the de-facto standard. Regardless, there are only a handful of top C++ compilers. Interop with even one of them would be of tremendous value.
- steveklabnik 11y agoYeah, I mean, the basics of interop might be possible, it will just never be as robust as it could be if C++ had features better designed to play with other languages. (This of course also affects Rust as well; we don't have a defined ABI either.)
- mike_hearn 11y agoSure, you can't get completely perfect interop. However a LOT of real C++ codebases don't use or explicitly ban some of the trickiest features, so even partial support can go a long way. For instance, supporting the basic class/vtable layout C++ uses (or even just adopting the C++ ABI for Rust itself here) along with char* strings, would immediately allow you to call into a lot of real C++ APIs, albeit older ones. Supporting C++ value types, even without templates, would in turn be enough to support quite a lot more. For instance Unreal Engine defines its own string types, as do Qt and so on.
- steveklabnik 11y agoYeah, to be clear, I think such a thing would have value too. Just hard to get 100%, there are always gonna be caveats.