[wredue]

I don’t really care what people making claims say when they make claims without evidence. ”Who” makes a claim has no bearing on its truth.

Immutability is a tool, not a rule, and I am free to reject any assertion otherwise when those assertions provide no evidence, or shitty anecdotes.

Prove your claims.

Certainly, immutability is a foundation for performance problems.

Another provable rule in computing is that more lines of code = more bugs. Immutability uses more lines of code.

Another demonstrable fact is that Haskell based programs have just as many bugs as any other programming language whether you have immutability or not. Therefore, immutability is not a bastion of robustness.

You’re going to have significant difficulty proving to me that immutability = scalability and robustness when both are demonstrably not true just by taking measurements of thing you expect to improve out of those foundations.

Immutability is not a silver bullet. It is a tool that is sometimes useful, but has significant drawbacks, including shitty performance, and significantly limiting how your data can be managed (without that limitation paying off in any significant way)

[WolfeReader]

You begin with "I don’t really care what people making claims say when they make claims without evidence". May I hold you to your own standards?

Because the rest of your post is pretty LOL-worthy in light of your opening sentence.

[wredue]

Sure:

1) immutability has performance problems: source: literally every measurement of immutable vs not data structures ever performed.

Source 2: logic - copying data is slower than not copying it

Source 3: cache lines: modern CPUs rely pretty heavily on cache lines and branch prediction to improve performance. Immutability measurably harms both.

2) immutability requires more code and loc is the best predictor of defects

Clarification: runtime immutability requires more code

Source: it takes more lines of code to return deep copies of objects than to not do that.

Source: https://www.researchgate.net/publication/316922118_An_Invest...

Package densities are the best predictors of defects

3) Haskell projects have as many bugs as any other language

Source: the best evidence we have here is “the large scale study of programming languages on GitHub”, but I suggest that you look deeper here, as the authors qualifications of defects is somewhat questionable (a project that never fixes defects would have low defect rates in this study, it additionally doesn’t properly compare projects sizes and other things). Anyways, in responses that do have better controls in place (and hilariously even in this paper itself, where we see Haskell programs tend of see higher defects as projects go on while c projects tend to have fewer), we see that Haskell does absolutely no better than anything else for bugs and defects.

[WolfeReader]

When you say "the large scale study of programming languages on GitHub", are you referring to this? https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

"Table 7: Functional languages have a smaller relationship to defects than other language classes where as procedural languages are either greater than average or similar to the average."

"The data indicates functional languages are better than procedural languages; it suggests that strong typing is better than weak typing; that static typing is better than dynamic; and that managed memory usage is better than un-managed."

You got owned by your own source.

As for your un-sourced claim that "copying data is slower than not copying it", I'd suggest learning how immutable-first languages practice data sharing between objects to minimize the amount of copying needed.

[mrkeen]

I wanted to write that making defensive copies is something you need to do in mutable situations to preserve safety, (not in immutable situations!), but it looks like enough commenters have hit that point.

So lets disabuse your mistrust of immutability in another domain!

Here is some typical "go fast and mutable!" nonsense code:

    int foo(int i, int j) {
      while (i < 10) {
        j += i;
        i++;
      }
      return j;
    }

Let's compile it with https://godbolt.org/, turn on some optimisations and inspect the IR (-O2 -emit-llvm). Copying out the part that corresponds to the while loop:

  4:
    %5 = sub i32 9, %0, !dbg !20
    %6 = add nsw i32 %0, 1, !dbg !20
    %7 = mul i32 %5, %6, !dbg !20
    %8 = zext i32 %5 to i33, !dbg !20
    %9 = sub i32 8, %0, !dbg !20
    %10 = zext i32 %9 to i33, !dbg !20
    %11 = mul i33 %8, %10, !dbg !20
    %12 = lshr i33 %11, 1, !dbg !20
    %13 = trunc i33 %12 to i32, !dbg !20
    tail call void @llvm.dbg.value(metadata i32 poison, metadata !17, metadata !DIExpression()), !dbg !18
    tail call void @llvm.dbg.value(metadata i32 poison, metadata !16, metadata !DIExpression()), !dbg !18
    %14 = add i32 %1, %0, !dbg !20
    %15 = add i32 %14, %7, !dbg !20
    %16 = add i32 %15, %13, !dbg !20
    br label %17, !dbg !21

  17:
    %18 = phi i32 [ %1, %2 ], [ %16, %4 ]

Well, would you look at that! Clang decided (even in this hot loop) never to re-assign any of the left-hand-sides, even though my instructions were just: "mutate j in-place. mutate i in-place."

[wredue]

Listen dude. I’m not going to argue about this:

Immutability is measurably slower. Full stop.

The fact that you can come up with silly, overly simplistic, non-idiomatic anecdotes showing that sometimes a compiler will prefer calculation doesn’t change that. It is a commonly known fact in low level programming that just because you’re calculating something doesn’t make it slower by default.

When Haskell devs can produce a game engine that doesn’t look like PS2 on a 4090, we can chat again about how immutability is supposedly not slow.

[ilikehurdles]

> Source 2: logic - copying data is slower than not copying it

> Source: it takes more lines of code to return deep copies of objects than to not do that.

Defensive copying and deep copying is not a thing you have to do in immutable languages. Even under the covers, it's not happening the way you seem to think it is. If I had a large immutable map in use by some other process, and needed a version of it with an element changed or added, why would I deep copy it when I can just point to that same map instance, and add a pointer to the key-value pair I want to substitute [1]? I think this is a common reservation people have about immutable programming because they come into it with a OO mindset. At least, I know I did.

In a really simplified example, a = (1, 2, 3, ..., 100) and b = (2, 3, ..., 100) are not allocated as two full lists in memory space. a contains 1 followed by a pointer to b. Because you have guarantees that b will never change, the single instance of b can be recycled in other data structures (or passed to many other functions and threads) and you avoid the complexity of managing race conditions, mutexes, semaphores, which are a significant source of bugs in other languages.

See [2] for a more realistic implementation.

1. https://en.wikipedia.org/wiki/Radix_tree

2. https://en.wikipedia.org/wiki/Hash_array_mapped_trie

[wredue]

In order to flatten these to regain cache hits, a deep copy is required all the way down.

There’s a reason that the fastest Haskell game engine looks like ps2 graphics on modern hardware.

[lvass]

If you're requesting proofs, don't make so many bold statements you cannot prove yourself.

[wredue]

Provided above.

[WolfeReader]

The only link you've provided in this discussion is about the relationship of LoC to bugs, nothing to do with immutability or FP: https://www.researchgate.net/publication/316922118_An_Invest...

You have posted nothing else besides your own assertions.

[dimitrios1]

There isn't some universe where there exists a list of axiomatic, unfalisifable proofs for what or what doesn't constitute the foundations of scalability and robustness, rather, you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives, and Joe Armstrong was someone who trailblazed that tradition in blood sweat and tears so to speak, as well as a majority of developers here, many of which have had experience writing software that handles millions, sometimes hundreds of millions of requests per second who would very much likely agree with Joe on a lot of things.

Not everything people say on a discussion board is some scientific claim, subject to scientific inquiry and in need of a thesis defense. But if you really off-the-cuff dismiss Joe Armstrong's opinion on a matter because it hasn't met your criteria of proof, despite you thinking you are somehow being the rational scientist here, you are actually revealing your own stupidity.

[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

[HexDecOctBin]

> you have a tradition of development practices that have much more often lead you to scalability and robustness than than the alternatives

I'm not GP, but these traditions are usually not backed by any evidence but by cargo-culting and cult-of-personalities. Not to mention people who over-hype their favourite technologies to high heavens, poisoning the well for everyone else (no, most telecom industry doesn't run Erlang, Naughty Dog didn't ship Lisp on PlayStation 2, and Prolog didn't lead to fifth-generation computing).

[dimitrios1]

Do they need to be backed by evidence to be correct? What if they are just right? Do other companies not running Erlang mean its wrong? Because that's a bold argument that could be restated to disprove many things -- X technology claims to do Y well and has a track record of doing it really well, but Z companies don't use X technology, therefore...[insert whatever].

I don't believe in blindly believing things without evidence either, especially if I have never encountered them before, but I also don't believe in blindly dismissing experience of world renowned experts in their field because they didn't provide me a point by point prooftext of every claim they made (Again we aren't sitting here discussing a dissertation or mathematical proof). Their experience and what they've provided to the world is the evidence. We took this 19th century german ultra-materialist philosophy too far here in the west, and that's what gave us post modernism/poststructuralism with its disastrous consequences, but it still seems like we haven't learned anything from that.

The ancients had it right that theres different types of knowledge, and different ways of knowing things (and knowing them to be true, at least as far as it mattered). We here in the modern era with the most unfettered access to information have quite possibly the narrowest definition, ironically.

[HexDecOctBin]

> The ancients had it right that theres different types of knowledge

People hawking these traditions usually do for consulting money, not spiritual fulfilment. I am all for non-materialism, but only as long as it's not used to exploit me. Belonging to a post-Colonial country, I know exactly where that leads.

[mrkeen]

> Another demonstrable fact is that Haskell based programs have just as many bugs as any other programming language whether you have immutability or not. Therefore, immutability is not a bastion of robustness.

Bugs happen when you think you can program something correctly, but can't.

If you look at the implementations of transactions in any other language... Oh wait there aren't any!

People keep trying to implement it in their own languages, figure out it's a non-starter (because of uncontrolled mutation), and give up.

[senderista]

I mostly agree with this (having worked on a simple STM for C++), but with a couple caveats:

- Clojure doesn't enforce purity (it can't), but from what I hear its STM seems to work pretty well (aside from some perf issues possibly? haven't used it). That's because "mostly pure" functional programming is encouraged by both the language itself and the culture and ecosystem around it, so uncontrolled side effects are less likely to be a problem.

- I think STM can work "well enough" in unmanaged languages as long as you don't try to boil the ocean and make it perfectly transparent, safe, and fast under all circumstances (Microsoft, IBM, Intel and several others tried for years and failed). That means there will inevitably be huge footguns for non-expert programmers (e.g., any side effect might be invoked every time a transaction is optimistically and transparently retried). These footguns can be mitigated by affordances like commit/abort handlers and infallible transactions.