Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1]

> Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is <100ms on average. The BuckleScript author estimates that the build system should scale to a few hundred thousands files in the current condition.

> Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! *

> Most of the messenger core team's new features are now developed in Reason. Dozens of massive refactors while iterating on ReasonReact. Refactoring speed went from days to hours to dozens of minutes. I don't think we've caused more than a few bugs during the process (counted toward the total number of bugs).

In a high-velocity codebase, modularity is the name of the game. And you will be hard-pressed to find languages outside the ML family which are that good at modularity. OCaml is just about the only industrial-ready language in this space.

[1] https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...

Don't buy that propaganda, however well-intentioned it is.

At the time when that post was written (including the "no bugs") the web version would continuously fail in the simplest of tasks while having a fraction of the features of the app version.

Any moderately complex app is made up of so many moving pieces, I'm amazed that you can pinpoint those failures specifically to the web frontend piece.

I can't find what I wrote at the time, but there were multiple UI/UX issues and logic bugs.

In any case, the point I was making was that languages from academia potentially could scale up in high-velocity and larger teams.

They must have changed how they report bugs, because the number of issues messenger.com experiences is definitely more than 10 a year. Also super slow.

Aren't Reason and ReScript different languages? It's confusing which one they're talking about here.

They are now, at the time the post was written ReScript did not exist and people used to refer to the combination of BuckleScript + Reason as 'ReasonML' for simplicity.

> my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day

Why would they? Many are designed meticulously to address the issues industry has. I've worked on a multi-million line Haskell code base in a financial institution and it scaled better than e.g. C++ or Python. In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

God what's the compilation time of millions of line of Haskell?

> In 30 years time, I'm sure the industry will be extolling the virtues of algebraic data types, purity, immutability and referential transparency.

There are plenty of industrial languages with algebraic data types and immutability. Not as many as I would like with purity but I doubt it will take 30 years.

> God what's the compilation time of millions of line of Haskell?

It wasn't compiled with GHC, but a proprietary compiler. It could typecheck the entire lot in a few minutes (in parallel) which was usually enough to detect breaking changes.

> There are plenty of industrial languages with algebraic data types and immutability.

A few do, yes, certainly not plenty. But defaults matter and immutability means more than just "const", e.g. persistent collections.

> Not as many as I would like with purity but I doubt it will take 30 years.

Given that big tech is delivering languages that are basically the same as Algol 60, I honestly think it will take at least 30 years.

http://cowlark.com/2009-11-15-go/

Purity is nice and clear to reason about. But when you want the last drop of performance, having a place to overwrite memory as you invoke a SIMD algorithm or cast and do bitwise stuff is invaluable from a performance point of view, whether we like it or not.

Such a function can still be pure on the outside. This is real (state) encapsulation, not the encapsulation sold to you by OOP vendors.

Ok but there was discussion about Haskell so I was sticking to that... of course if you can have functional as an extra without preventing imperative in the low level then you can apply the best of both worlds.

Haskell let's one write fast imperative code when needed or call C functions.