On the topic of immutability you can actually trace it back to a point (and languages even) where every variable is a global one. That almost always leads to hard to debug errors and generally poor quality of the final product until you catch all the bugs. The natural "fix" is to have variables that a scoped and cannot be used outside of that scope - I hope I do not have to make the case for why that strictly improves long term maintainability.

Immutability is taking it a step further and provide a mechanism where scope does not matter. If you have an immutable object you can always expect the values to be what they are and not changed by some other path of code. You can freely pass around the immutable objects because they cannot be changed.

In other words, it's a mechanism that you can use to ensure that no matter what is changed, it's not the value of you immutable objects. I'd argue that it lowers the surface of things to consider and with any decent tooling also prevents you from trying.

So you try to convince me that immutability is great. But I did not say I don't believe in the benefits of immutability, I said there is no empirical evidence that it leads to better long term productivity.

I'm not in a position where I can give you any empirical evidence because I do not collect it. My teams do see a decrease in bugs that reach production when they start to embrace immutability. But, the catch is that most of those teams are on a general journey of known good practices such as integration tests, static analysis, linting, and to some degree unit tests and reducing cyclomatic complexity. So I cannot in good faith give you any numbers because I do not run controlled experiments for that alone.

Looking back on my replies a few days later I think I missed every mark I tried to hit. The arc of the "narrative" was about the nascent devops bleed into the frontend space which our team appreciates from now - but failed to make any real sense of it. I'm not a good writer.

> People were saying the same things about OO inheritance and and a bunch of other stuff which the industry have later become more skeptical towards.

In my experience this is the usual adoption curve of new practices (not necessarily best practices). They come as a shiny new solution for an annoying problem, it gets absorbed by early adopters that then become evangelists. More people start using these patterns/practices and start encountering the issues and obstacles with it, some get disheartened, frustrated and become outspoken against it.

These practices then evolve with time, becoming more nuanced, having "best applications" and "non-use cases" to better judge its applicability. And then becomes mainstream and a expected practice for modern software development/engineering.

I've seen this with multiple trends: OOP-isation of everything, UML (birth and death, kinda superseded by C4 diagrams these days), NoSQL, microservices/SOA, Kubernetes, Dockerisation, and so on and on.

FP and immutability are getting into the maturing phase of this, I remember a few years ago when it started making inwards on FE development, it was adopted, kinda overused and now I see it trending towards more cautious adoption.

I believe it's all a matter of understanding, all new shiny things will always have early adopters that can cope with the pain points. These are addressed when getting more mainstream and with that comes the knowledge of what actually these pain points are in the real world after years of adoption.

I don't see this pattern changing anytime soon, I've seen it repeat too many times the past 15 years.

Totally agree. I will add that the hype is typically ignited because a technique have shown real benefits in a particular domain. The problem comes when the technique is treated as a panacea and is applied uncritically outside of this domain. This eventually cause a backlash, which may even hurt adoption in the original domain where the technique was successful.