4 ms·

How does that matter? You said "game development", not "writing a game engine". You said "data analysis", not "writing linalg algorithms", in which case we'd al

How does that matter? You said "game development", not "writing a game engine". You said "data analysis", not "writing linalg algorithms", in which case we'd all have to bow to Fortran anyway. Your argument also doesn't apply to GUI apps, anyway. C# and Java amount to a huge number of such apps, and they're self-hosted. GC languages are vastly more productive that manual-memory languages, and for the vast majority of users, that is worth the performance hit.

whatshisface 5y ago
If your suggestion is, "GC languages can be used to write anything so long as whatever parts can't be written in a GC language are written in a non GC language," then yes that's true. But it's also a tautology.
- maleldil 5y ago
  If you need to stay away from the GC because of some practical reason, you can always write C/C++/Rust. You implied that this is a frequent situation when it isn't. Your example of "anything with a UI" was quite a bad one. Most projects are better off written in a GC language because the productivity benefits outweigh the performance costs.
  - pkolaczk 5y ago
    There is a lot being said about productivity gains from GCed languages, but can you actually point me to any research showing these gains are real? My anecdotal, unscientific experience shows that GC is a double-edged sword that maybe makes writing simple programs slightly faster, at the expense of a much worse maintainability once the code base gets big. And non-memory resource management in GCed languages without RAII is a really huge PITA that kills all productivity gains. GC allowed memory safety until Rust happened, and that was a big gain, but now that point is moot.
- pkolaczk 5y ago
  In practice it is even not true, because there is a non-zero cost of interfacing between managed runtime and native non-managed code. Therefore not every piece of code that would theoretically benefit from writing in a non-managed language, could be actually rewritten.

whatshisface 5y ago

If your suggestion is, "GC languages can be used to write anything so long as whatever parts can't be written in a GC language are written in a non GC language," then yes that's true. But it's also a tautology.

maleldil 5y ago
If you need to stay away from the GC because of some practical reason, you can always write C/C++/Rust. You implied that this is a frequent situation when it isn't. Your example of "anything with a UI" was quite a bad one. Most projects are better off written in a GC language because the productivity benefits outweigh the performance costs.
- pkolaczk 5y ago
  There is a lot being said about productivity gains from GCed languages, but can you actually point me to any research showing these gains are real? My anecdotal, unscientific experience shows that GC is a double-edged sword that maybe makes writing simple programs slightly faster, at the expense of a much worse maintainability once the code base gets big. And non-memory resource management in GCed languages without RAII is a really huge PITA that kills all productivity gains. GC allowed memory safety until Rust happened, and that was a big gain, but now that point is moot.
pkolaczk 5y ago
In practice it is even not true, because there is a non-zero cost of interfacing between managed runtime and native non-managed code. Therefore not every piece of code that would theoretically benefit from writing in a non-managed language, could be actually rewritten.