> Is data changing that big of a problem?

Yes, but it is hard to recognize it as such until you've experienced the alternative.

I don't know much about Kotlin, but the fact that it relies heavily on Java libraries is sufficient to tell me that it is a particularly poor example of the power of immutability. You see the usefulness of immutability when you have objects that are deeply immutable - when you pass them around, you know those functions haven't changed them. It is much easier to reason about deeply immutable objects than mutable ones.

> in immutable languages, are there cases where immutability extends to nonscalar values like arrays or hashes or objects

Yes, this is largely the point. Although, you will rarely see an immutable array or hashtable - more likely it will be a linked list or balanced binary search tree.

Kotlin runs on JVM but it's closer.to Scala, not Java. You can sure have immutable structures all the way down in it, as if it were Haskell. It doesn't enforce this style, though.

You're probably right, Kotlin's version of immutability is perhaps not the best example -- pretty sure the whole var/val thing is language sugar which explains why it doesn't work for nonscalars.

Makes sense, I can see the appeal now. Thanks

> Plus, in immutable languages, are there cases where immutability extends to nonscalar values like arrays or hashes or objects?

Yes, see (among others) Erlang or, if you like static typing with your immutable values, Haskell, both of which are pervasively immutable.

This is why the `deep_dup` and `ice_nine` gems live in most of my projects.

The last 3 years of development to the language have been...momentous, to say the least.

Even if you just look at what's been done in garbage collection alone, it's leaps and bounds.

The "why immutable" question usually attracts zealots that throw around terms like "easy to reason about" and detractors that mention "slows code down and is harder to write"--as if those statements were inherently true, universally understood, and defined in an agreed-upon way. None of those are the case.

The usual argument in favor of immutability is not that mutability is a big problem in general, but that when unexpected mutation occurs, it's a really hard to find (debug) type of problem.

If you have a well behaved codebase that does "a = { :foo => 'bar' }; render_hash_to_browser(a); store_hash_to_database(a);", you're fine: you can assume the same data ends up in the browser and in the database.

However, if that assumption ever fails ("users are seeing data that isn't in the database!") it's often a debugging nightmare, because you have to dig down into any code that might possibly ever touch the hash to see if it's accidentally mutating it. This includes utility functions, totally unrelated areas, et cetera.

If you have a good debugger to assist you, and an easy way to attach your code to a harness that follows bug-reproducing paths, you're set. But those things are a) never as present as we want them to be ("just don't write bugs, duh!") and b) tend to be harder to get working in old, large, monolithic projects--just the kind of projects where sneaky mutation can become a frequent issue.

Now, all debugging is hard. And a lot of it involves delving into code you've never seen/touched before to find a bug. But sneaky-mutability issues typically expose a much wider variety and volume of code as suspect. Because of that, mutability issues often tend to be, if not objectively more difficult, at least objectively more frustrating to debug.

With this as in all things, there's a spectrum. Some folks are fine with ultra-dynamic languages that let you mutate/bind anything, and protect against that with convention and tooling. Hell, some folks are fine with languages that mutate their data structures when you do nothing but read from them (https://perlmaven.com/autovivification). For others, they just want control over what you can bind to names (a type system, or "const"--the Java/etc kind--which prevents rebinding). Still more folks want the ability to opt into truly immutable deep data structures. And others want everything in their platform to be immutable when they use it, and have all the mutability (which you nearly always need, if only for performance alone) handled behind the abstractions of their runtime.

However, past a certain criticality or size (of code/complexity/age/number of developers threshold) of a project, it often becomes necessary to move "up" that ladder to something that provides more programmatic/automatic assurances about "what is happening to my data as it passes through all this code?"