[wredue]

The author claimed that immutability is a foundation for scalability and robustness.

I reject that claim.

In this comment, you simultaneously agree and disagree with me.

I don’t give a shit what Joe Armstrong says about immutability because the facts are the facts:

1) immutability cause performance problems

2) immutability significantly limits how you can manage data, which is counter to what computers are meant to do

3) immutability measurably does not reduce bugs in programs

I am not dismissing <insert name> off the cuff. I am dismissing them because their claim does not align with metrics you expect to improve as a result of their claim.

>it doesn’t have to be a scientific claim

When you are telling people to “make immutability a foundation of their programming”, you 100% are opening yourself to scientific scrutiny. If you cannot back up this claim with actual metrics, and you’re just going to say “hurr durr, just let me make claims without calling me out to providing evidence please”, why should anyone believe you?

[ilikehurdles]

You continue to express strong claims on strong claims without backing a single one of them up. And then you drop to mocking others for challenging those claims.

Have you ever heard the saying, “assertions made without evidence can be dismissed without evidence?” My experience differs.

Immutability has been the foundation of many of our large scale programs. It makes safe concurrent programming easier, and languages built around immutable data structures usually optimize memory handling in ways that are not available when simply writing “functional style” code in non-functional languages. ie under the hood they’re using persistent data structures, structural sharing, tail call optimization, etc.

[prophesi]

I think the main thing (in the context of Elixir) is that immutability gives you concurrency out-of-the-box, which in turn gives you predictability and scalability. It is very easy to spin up a couple of nodes that can communicate with each other thanks to this ecosystem.

[ch4s3]

> 3) immutability measurably does not reduce bugs in programs

I'd be curious to see how you back this claim up. Are you referring to something published that we can all go and read?

[sodapopcan]

It doesn't sound like you've used a natively mutable language before. If all you've ever used is immutable.js or something like that then I can understand why you think this way. Otherwise, you've gotta be trolling.

[mjhay]

A bit of the pot calling the kettle black here. You still aren't providing evidence yourself while making strong claims.

For your points:

1) Yes, immutability can cause performance problems in some contexts. However, it can also help in the whole. Mutability in concurrent systems requires all sorts of complications such as mutexes that slow things down considerably. In even single-threaded systems, mutability leads to defensive copying in practice. Furthermore, persistent data structures[0] exist for lists, dictionaries, etc., that achieve very good space and time performance by mutating internally while exposing an immutable interface.

At any rate, even if it is slower, most of the time the performance difference just doesn't matter.

2) How does it limit how you can manage data? It's still possible to mix immutable and mutable data if necessary, but immutable data can be transformed just as mutable data can.

3) You say it measurably does not reduce bugs in programs, again with no evidence. Immutability eliminates entire classes of commonly-encountered bugs, including many pernicious ones related to concurrency. These are bugs that happen commonly with mutable data, but simply don't for immutable data.

In addition, there is some limited empirical evidence to the contrary, which is rare for this kind of thing. Immutable-first Clojure had the lowest proportion of Github issues labeled as bugs, even beating out static languages. [1]

[0] https://en.wikipedia.org/wiki/Persistent_data_structure

[1] https://dl.acm.org/doi/10.1145/2635868.2635922