It would be nice if you could elaborate on why you think it's idiotic. What's "better" for one scenario could be worse for another. There are tradeoffs to be made.
In my experience immutable data simplifies a lot of things and avoids a lot of common problems related to concurrency. Implementing efficient copy-on-write isn't too hard when everything is immutable.
You’re making your programs orders of magnitude slower to the back of claims that have absolutely zero metric demonstration.
>simplifies a lot of things
Runtime immutability simplifies nothing.
>avoids common problems related to concurrency
While simultaneously creating new problems. Like fine, you cannot make an edit on an object out from under the rug of another thread… except that in most cases, you have now just made that old object into invalid state that is lingering around your program like a death trap and to get around this, you are forced in to some pretty terrible synchronization bullshit that just locking objects doesn’t suffer from.
>Implementing CoW is not too difficult
The single greatest predictor of defects for every single language ever is “lines of code”. Implementing CoW sounds straight forward, but actually, incorrect CoW is a common source of bugs and you are just hand waving that away.
Not sure why you're coming across so aggressively.
Orders of magnitude slower? Citation needed. I don't think I've ever encountered any performance problems caused by immutability in anything I've worked on. But as always, there are tradeoffs, and if there's a bottleneck then it can be addressed when identified.
> The single greatest predictor of defects for every single language ever is “lines of code”.
Did you hallucinate whatever you think you replied to? At no point did I mention LoC. I mentioned simplicity. Two very different things.
You are reading aggression in based on the fact that I am disagreeing with you. It is text over the internet. Whatever tone you are gathering is purely imagined. I would suggest you visit fewer circle jerk areas and discuss things. People telling you you’re wrong and why is not aggression.
>source
I mean. I assume you’re a developer as you have a strong opinion on immutability. So just test it? It isn’t as if testing the impacts of immutability of performance is a difficult thing to test out.
It is actually difficult to find results because functional programmers have flooded the internet with “yes performance is impacted, but performance doesn’t matter. Performance is a premature optimization”
Nevertheless, even with things smaller than a register, performance is impacted here:
By several X. Now get it objects that are larger than a register with numerous stack blowing deep copies and the effects are massively more pronounced.
The fastest Haskell game engine looks like PlayStation 2 on modern hardware.
I mean. That immutability massively hurts performance is not a point of contention, even among immutability fanboys.
>did you hallucinate
I think you forgot your own post. You stated that CoW is trivial and I gave you a specific reason as to why that claim is a lie.
In my experience immutable data simplifies a lot of things and avoids a lot of common problems related to concurrency. Implementing efficient copy-on-write isn't too hard when everything is immutable.