4 ms·
"Depends on what problems you are solving I suppose. " - well, yes. Hence my question about what you're defining as the general case; that 10-20% seems rather h
by lostcolony 6y ago
"Depends on what problems you are solving I suppose. " - well, yes. Hence my question about what you're defining as the general case; that 10-20% seems rather high for cases you'd need mutability.
I think it's a bit of a red herring to ask "can you solve them quickly enough" - after all, if pure speed across all use cases is your concern, why would you advocate a garbage collected language?
- alkonaut 6y agoI’d only advocate using GC’d languages as a general (ie covering as many use cases as possible in one language - this isn’t even necessarily a good idea to begin with!) where it’s easy to dodge it. For example it must be easy and reasonably idiomatic controlling what is and isn’t heap allocated. Obviously all languages are a tradeoff between ergonomics and performance, but it should be easy and idiomatic to use the back doors. Using mutation in F# or stack allocation in C# doesn’t feel like swimming upstream. If the language offers a comfortable experience for the 80-90% case and a not-terrible experience for the rest, that’s very good. If the “back door” is e.g. JNI or being forced to use SoA when you wanted AoS in Java that’s not very impressive. I grabbed the 10-20% number of “programs that need mutation” out of my behind obviously, but it is highly subjective.