The guarantees offered by functional programming and immutable data are great, but they mostly evaporate when you move from a single process application to a multiple processes system, distributed on many machines and communicating through IPC.
Are you aware of a 2M lines code base that fully relies on FP and immutable data?
I beg to differ: the guarantees functional programming and data immutability offer are exactly the sorts of guarantees needed for scalable parallelisation.
LOC is not a useful metric for the utility of a program, in fact the reverse is true in terms of maintainability and places for bugs to hide.
This chap claims to write very robust programs, entirely functionally that are worth billions in their operation.
The argument being that non functional programming has fundamental limits to its scalability, seems like a very important question as the complexity of code begins to grow exponentially.
Large imperative codebases are inherently fragile, hence the need for test driven development - good batteries of tests offer demonstrable reliability.
The counterargument is that very large codebases tend to be composed of multiple services. Each service lives in its own process and maybe in its own machine, and communicate with other services through IPC. At that point, you've lost the benefit of functional purity and immutability, because each service can maintain some "hidden" state.
You're right, above some threshold, it becomes hard to reason about imperative code with mutations. Your preferred solution is to adopt functional programming and immutability. Another solution is to decompose your system in multiple communicating services. Google's codebase is a very well known example of the latter approach.
This is false. Well, it may be true in Erlang, but its false in Haskell, where there is always clear separation between equations and effects/state no matter the source (IO to other services or local state). Not to mention that there are tools such as STM that let you deal with state in a much safer and less error-prone way.
Separating the state between multiple communicating services is basically the same strategy as OOP (objects that communicate via messages and encapsulate state) but with stronger encapsulation requirements (access only via API, you can't just "reuse" methods willy-nilly all over the place but you have to come up with a sensible library or a third service, etc etc).
It works, yes but it works about just as much as OO does. Which is... not very much. And it also comes with its own tradeoffs (good luck getting atomic changes over multiple microservices)
I don't think so. An Erlang process has no mutable state. But it can communicate with another Erlang process to set/get some state. This is how a lot of mutable structures are implemented in Erlang.
Do they, now? Or do they only evaporate in Erlang?
Since most FP codebases do the same with a few orders of magnitude less code, no, I'm not aware. Though I imagine that if they had to copy their code for every single instance of their generic typeclasses, they would quickly amass many millions of lines.
Are you aware of a 2M lines code base that fully relies on FP and immutable data?