'You cannot program without mutation in the general case. You simply don’t always have the performance/power budget for it.'

So by 'general case' you mean 'every case'? Because to my mind, those instances you don't have the performance/power budget for 'it' are very much special cases, not general ones. It also seems a curious distinction; I mean, Python and Ruby both allow for mutable data, but are quite slow and memory intensive. Haskell doesn't allow mutability, but is quite fast, and also surprisingly memory efficient when written well. What languages do you consider to be able to address 'the general case'?

I mean for a programming language to be able to handle the general cases it should also handle the maybe 10% or 20% of programs that might need mutation in their hot paths. Obviously one solution is to call out to a different programing language for only the areas that require it, but I’d consider that a definite deficiency if it’s commonly required.

I think e.g C# and F# handle mutation well, but I think F# does the right thing by not encouraging it like C#.

Being able to control the in-memory representation of data and do things like sort arrays in-place etc to some people seems to be rare and to others happens on day 1 even at toy scale. Depends on what problems you are solving I suppose.

"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?

I’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.

To me "avoiding mutations" does not mean "no mutations", but rather "no mutations in-between states in a state machine". The system should model state as an immutable snapshot, while mutations when forming that state are completely acceptable.

There is obviously mutation at some level of abstraction but usually one form of coding is idiomatic and one isn’t. I’m all for using immutable data and pure functions, but I’d discard a language and standard library that doesn’t have a good/idiomatic story for e.g mutating large arrays in place or has a good selection of contiguous (array-backed) collections be too limited for many types of work.

How is it avoiding subtle bugs? Looks like a sane default to me

Which default is default though? An ordinal comparison? Or system-local one? (E.g one that considers a German ß equal to “ss” or one that doesn’t?).

On that same note, coming from a country that uses decimal comma, I very much would prefer it if code always had to specify a target locale when printing a decimal number.