[banachtarski]

I would argue the immutability is actually not a great thing in Erlang to be honest. It makes it hard to reason about what gets copied, what gets shared in the global heap which may be a source of contention, makes code unnecessarily verbose, etc. I think it's one of those features (like lazy evaluation in Haskell) that language practitioners tend to advocate without necessarily understanding what tradeoffs they are making in the process.

[ams6110]

It actually makes reasoning easy. What gets copied: everything. What gets shared: nothing.

[im_down_w_otp]

Except that isn't true in Erlang (or other BEAM languages). Binaries larger than some threshold are managed on a shared-heap. I think a couple other things have been promoted to being managed that way too fairly recently.

[ramchip]

You might be thinking of the optimization for constant pool references: https://medium.com/@jlouis666/an-erlang-otp-20-0-optimizatio...

[im_down_w_otp]

Yes, that. Thank you.

[banachtarski]

That's not true in a number of cases, and thankfully what you said isn't right or the BEAM would truly be a disaster.