The article "Immutability is not enough" is sub-par in every aspect.

The author never defines, what sort of problems immutable data can help avoid, or what the benefits of immutable data are. And still, after every paragraph, he wonders why functional programming didn't help him avoid bugs in his business logic.

Like, what the hell, the author produced a bug because the order of your operations was wrong? Great, write a test and restructure your code to make it work, at least you know where to look.

Functional Programming does not fix your Game Loop, and it never promised to.

FWIW I came to the comments because I also found the “Immutability changes everything” paper nearly unreadable.

I just wanted to comment that I love your last paragraph from a conceptual level. You want immutability? Great, let's talk about what performant game design looks like in that context. Games are special, in that they kind of do everything that computers are good at, to varying degrees. The author's ideas about snapshots of relational databases inviting further schema changes in the pipeline—I guess I see the idea you're trying to introduce, but what does it actually look like in a chess program? Or a choose your own adventure game?

The article rang true for me. I heard the same FP promises that the author did, and eventually ran into the same issues in my FP programs, and left disillusioned. The article captured the experience perfectly.

I like to say that mutable state is to software as moving parts are to hardware. If you can avoid them, great! But a number of systems/designs simply require them.

[link redacted]

Thanks for the link to “Immutability is not enough” I’ve resubmitted the article here: https://news.ycombinator.com/item?id=27642263