It's so empowering to be able to answer this question with an instantaneous "no, of course not, it can't be". People that never experienced it have no idea.
In one of them it matters if your computer will stop for 10ms ever couple of minutes, or if you use an extra 20MB of memory. This is the world of C, Rust and assembly, and you'll be stupid to try high level code structures here.
The other world is where mostly everybody lives. Here having your code feature complete and correct is overwhelmingly more relevant than putting it above the 95th percentile in performance, and you would be stupid to keep adding complexity just because it's sub-optimal.
It should be very clear what world you are in, because there are actually very few borderline problems.
Yes, you are going into it wrong. What I can see on that comment is that:
- You expected to write a "mostly pure" program in a pure language. It won't let you do that, you will write a pure program. You also do not need to be careful in doing it. The most obvious thing you get on a strict language is carelessly - you don't have to care about things that the language does not allow. You focus on (re)writing your program.
- As a consequence of the first point, the more strict (on anything, including mutability) a language is, the easier it is to change old code, because you can assume a lot of stuff about it, and because you care less about making mistakes.
- Specifically about mutability, it does not take any control away. Mutable values are exactly as expressive as immutable ones. You can have mutability semantics on an immutable language, and most try to make it as near a first class syntax as possible, but the one change is that you will have to make it explicit, one way or another.
Or Lodash-FP...