True, but that's why we've got Rust these days. (Rust is actually more optimized than C, e.g. it will automatically reshuffle your structs to get rid of excess padding, and reference accesses will automatically take advantage of compiler-checked 'restrict' constraints, thus equalizing performance with e.g. FORTRAN.)
This is in stark contrast to some other complex features that allow more stuff to happen with less code.
Rust is indeed, complex in the sense that it's features are non-trivial, but I find it less complex than C++ in the sense that it has 1) less surface syntax (because of lack of historical baggage) 2) more cohesive, principled feature set (again, hindsight is 20/20) 3) it's inherently more limiting, which helps reading, understanding and reasoning about code.
I think it is unlikely to see rust gain much traction in the game dev world. Everything is currently done in C++, and there is low incentives to move to something "safer" or "more secure", because that's not seen as relevant properties by game developers.
What matters for game dev is mostly (not listed in a specific order):
- raw performances
- low latency
- as low as an overhead as possible when dealing with GPUs
- control over memory management
In that context the borrow checker can be an unnecessary constraint, and the safety concern isn't really something that relevant. In the other hand, the rust package manager is really something that is missing in the C++ world, and would be awesome to have for game devs.
I think that's temporarily turned off because emitting noalias attributes so much exposed some llvm bug. See: https://github.com/rust-lang/rust/issues/54878
In the long run though, yeah that is an inherent optimizability advantage of Rust vs. C.
also, gcc and llvm can infer restrict much of the time if you don't manually use it
and I fail to see how having explicit control over struct layout is ever a bad thing
This is just more complexity as well. It introduces surprising behavior that can burn you when creating interfaces or serializing and forces the developer to know that the compiler will be doing such magic.
Do you regularly order your stack variables? :D
99.99% of cases there are no expectations about details of a `struct` and having to think about it all the time is a PITA. That's a good example how silly defaults in C/C++ are. Just because I might need manual ordering once in a while, does not mean I want to be bothered by it all the time.
I think what you mean is that current Rust _implementations_ optimize better than current C _implementations_. There's no reason a C99 compiler can't do those optimizations.
No, there actually is, the C standard says structs have to be laid out in memory in the same order they're written and C has much weaker aliasing rules.
