> Modern GCs are faster but they're by no means free, and totally unnecessary if you just give the compiler the information it needs to do its job statically
These are not mutually exclusive.
(1) A GC'd language can still do static analysis at compile-time or JIT-time to avoid GC all-together when possible
(2) GC'd languages can have RAII/static-scoping capabilities such as immutable value-typed (non-ref) structs which require initialization and using{}/after blocks for scoped lifetime
(3) GC'd languages can have owned-object semantics like C#'s Span<> to avoid GC
(4) You can use unsafe and pointers and GC'd languages a well
So you can still program with an eye toward efficiency for any code that shows perf issues using many of the same constructs you do in Rust, in a GC'd language -- but be able to fall back on GC when lifetime issues are complex or hard real-time perf is not an issue.
Again, I'm not bad-mouthing Rust at all -- I'd far prefer it to C++ in the context where the latter is appropriate.
These are not mutually exclusive.
(1) A GC'd language can still do static analysis at compile-time or JIT-time to avoid GC all-together when possible (2) GC'd languages can have RAII/static-scoping capabilities such as immutable value-typed (non-ref) structs which require initialization and using{}/after blocks for scoped lifetime (3) GC'd languages can have owned-object semantics like C#'s Span<> to avoid GC (4) You can use unsafe and pointers and GC'd languages a well
So you can still program with an eye toward efficiency for any code that shows perf issues using many of the same constructs you do in Rust, in a GC'd language -- but be able to fall back on GC when lifetime issues are complex or hard real-time perf is not an issue.
Again, I'm not bad-mouthing Rust at all -- I'd far prefer it to C++ in the context where the latter is appropriate.