GC has performance costs, while trait objects and symbol names do not, as long as they're opt-in.
Not exactly.
Any program even in a GC'd language can allocate non-GCd data. Even in Java, there is the Unsafe class that can do manual mallocs/frees. C# integrates it with the language. If you do a big pile of work on the non-GC heap then no GC would be triggered and GC is effectively "zero cost" for this code.
And vtable dispatch has a cost for any code that calls a virtual method. Yes, it's "opt in" but this can be misleading. You pay the cost of the virtual method call every time it's invoked. Static languages like Rust and C++ require the programmer to explicitly state which methods can be virtual to try and control this cost, but that isn't the only way.
For example the JVM is capable of eliminating the virtual method dispatch overhead in almost all cases without requiring the programmer to manually specify which methods are virtual. In fact, the JVM can eliminate the vtable overhead for calls that could be virtual, but in fact at that specific call site are not, and even for calls which are only slightly virtual (e.g. there's only really two destinations). So it's possible that in a JIT compiled program you have way more virtual dispatch in theory, but less than the equivalent C++ program would in practice once the code is warmed up.
So vtable and GC performance are very complex topics which no longer reduce neatly down to our intuitions.
>And vtable dispatch has a cost for any code that calls a virtual method. Yes, it's "opt in" but this can be misleading. You pay the cost of the virtual method call every time it's invoked.
So you're basically repeating what he said -- I don't see how the "Not really" you begin with is justified.
Of course you "pay the cost of the virtual method call every time it's invoked".
In languages like C++ or Rust you pay the cost every time the method is invoked. With other types of compiler you may not pay the cost even if the method is marked as virtual, even if it's actually used virtually in other parts of the codebase, due to call site specialisation.
Not exactly.
Any program even in a GC'd language can allocate non-GCd data. Even in Java, there is the Unsafe class that can do manual mallocs/frees. C# integrates it with the language. If you do a big pile of work on the non-GC heap then no GC would be triggered and GC is effectively "zero cost" for this code.
And vtable dispatch has a cost for any code that calls a virtual method. Yes, it's "opt in" but this can be misleading. You pay the cost of the virtual method call every time it's invoked. Static languages like Rust and C++ require the programmer to explicitly state which methods can be virtual to try and control this cost, but that isn't the only way.
For example the JVM is capable of eliminating the virtual method dispatch overhead in almost all cases without requiring the programmer to manually specify which methods are virtual. In fact, the JVM can eliminate the vtable overhead for calls that could be virtual, but in fact at that specific call site are not, and even for calls which are only slightly virtual (e.g. there's only really two destinations). So it's possible that in a JIT compiled program you have way more virtual dispatch in theory, but less than the equivalent C++ program would in practice once the code is warmed up.
So vtable and GC performance are very complex topics which no longer reduce neatly down to our intuitions.