I've been working with Clojure and most code is written using pure functional style. As a concrete example, Pedestal HTTP server has around 18,000 lines of code, and 96% of it is pure functions. All the IO and side effects are encapsulated in the remaining 4% of the code.

This has been a common scenario for the vast majority of Clojure programs I've worked on in the past decade. Core of the application does data transformations using native Clojure data structures. This is where all your interesting business logic lives. The interop lives at the edges and typically used for stuff like database drivers, HTTP servers, file access, and so on.

And I completely agree regarding immutability being the sane default.

I find that there are two major problems with OO. First is that it takes a lot of effort to learn how an API works because you have to pass object graphs around, and each object is a unique snowflake in terms of methods and behaviors it has. So, you often have to learn how dozens or even hundreds of objects are intended to be used.

Second, is that each object is effectively a state machine, and your application is structured as a graph of interdependent stateful objects. This makes it effectively impossible to reason about any non trivial application because all these relationships are too big to keep in your head. The only thing you can do is fire up a debugger get the application in a particular state and inspect it. Unfortunately, this is just heuristic since it's hard to guarantee that you've covered all the paths leading to a particular state.

Meanwhile with FP library APIs become data focused. You call a function, pass it some data, get some data back, and that's all you need to know. Data is both transparent and inert in nature. You don't have any behaviors associated with it, and you don't have to know what methods to call. The scope of information you need to keep in your head is drastically lower because you're able to do local reasoning.

Which industry?

Programming is more than just writing Yet Another CRUD-backed data-siphoning web app. It's more than supercomputing/high performance computing. It's more than spreadsheets and word processors. It's more than games.

Any one of those fields I mentioned are effectively a completely separate industry from the others. And I haven't even touched the 500kg gorilla of embedded systems that outnumber all of those put together by an order of magnitude or two.

Some software industries (the web stuff, say, or user-facing software like spreadsheets and word processors) will find pure functional or major steps along that path to be useful and an improvement over current techniques. Others (high performance computing, games) will find themselves stepping backward if they go the full-functional route. And that 500kg gorilla I mentioned simply can't use functional programming. (Hell, I don't think there's a pure-functional runtime that fits into any of the kit I work on, not to mention the runtime plus an actual application. I'm willing to be corrected, though: if there's a functional language out there that will let me write non-trivial applications that fit in 256KB code space and 48KB dynamic data space, I'm eager to hear about it!)

However much you think you know about software development, be aware that it's far larger than you think. (This applies to me too. I haven't even glanced at financial or health software's direction, and only have very vague notions of what aerospace systems entail.) And as a result, different tool sets are required for different problem domains. Functional doesn't fit them all.