If you look at the programming language landscape I think one wouldn't be unreasonable in pointing out that very little is understood in terms of how you go from good ideas to widely adopted language.
What affects reality is important.
I really like how ML implements it, does that make me somehow less human?
Industry language designers are trying to make their users more productive enough to justify the cost to design and build the language. An industry language that doesn't have enough users and doesn't make those users' lives better enough to offset the salaries of the language team is a losing proposition and a bad language.
Academics are trying to publish papers on novel ideas. A language that cured cancer would be considered a bad language if someone had already designed a language that cured cancer the prior year.
These incentive structures a somewhat opposed: the easiest way to make a language easier to adopt is to make it more familiar and less novel. But they are somewhat aligned as well. A language with no new ideas can't be any better than the languages before it.
So there is a natural diffusion process where academia explores the frontier of weird language ideas. Many don't pan out. All of them are weird and unapproachable when they first appear. The ideas worth keeping stick around. Eventually an industry language will add a dollop of those novel ideas and surround them with a familiar framework so that users can actually absorb and use the thing.
Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.
> 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...
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.
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.
> 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.
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.
It's really hard to know what you are doing right or wrong when you are writing a large program. There are no guidelines for proper layout, logging, and error checking practices, and no matter what you do, it's verbose and error-prone (more code = more bugs). It's all DIY. I referred to HashiCorp code to see how they do things, for example.
As someone here said once - Go is basically improved C, after snoozing through four decades of language development. On one hand Go lets you go wild, and on the other it imposes rules that are seemingly arbitrary, like enforced naming conventions, but only in certain places.
Go is odd in that its proponents seem to flatly deny any of the very reasonable criticisms levied against it. And they continue to do so right up until the moment that the language authors finally address them.
I feel, programming too often lost productivity with quite a few modern languages. Go brings that back and adds a good amount of modern features, but doesn't get too much distracted by them.
What bad faith nonsense.
So the definition of success is that Go makes those people productive. If you give these fresh hires C++, now everything is on fire and even experienced people sent in to extinguish the flames end up just saying evacuate the entire site and let it burn itself out because that will be cheaper than diagnosing what's wrong.
This goal means some choices Go makes which I don't like seem more respectable. For example Go specifically warns you not to get clever. This is sound advice for a 22 year old new programmer who still probably thinks "Romeo and Juliet" is about true love, but it'd be very frustrating if you were trying to squeeze the last drops of performance juice out of a system. The answer from Google's point of view is that Go is the wrong language in that case and it's time to rewrite.
Also Go is mostly used externally, Google's key projects are all based on Java and C++, even Kubernetes would have stayed in Java if it wasn't for some Go folks joining the project and pushing for a rewrite.
From my discussions with employees at Google, the rationale for Go is to keep a large staff of promising CS graduates busy on dead-end projects (while preventing them from causing too much damage) until something takes off and they need to actually put some of that spare headcount to use.
Also, it would be interesting to hear your take on why you think languages that are, as you say, from "a sound theoretical foundation" tend to struggle with adoption?
Could it be that you fail to take into account that the things that make a language appealing in an academic sense may not make the language a particularly practical language?
Wide adoption means certain academy-hostile rules: backwards compatibility, a lot of user pressure towards certain directions, etc. Academics need freedom, and adoption is not about freedom.
ADA may be up your alley. it was fully designed and specified before a single line was written.
Each time we added more advanced typing to new sections of the system, new bugs and security issues were found. At the end there were over 100 places that were being used incorrectly. This is something that linters and the library itself failed to catch for years, but with proper typing we got there.
With the difference that with a better type system it becomes significantly harder to do this kinda thing to begin with, and that's a GREAT thing. Your business code is extremely simple, reusable, isn't intertwined with IO stuff and is 100% testable with minimal effort, without needing mocks or anything of the sort.
If you don't care about this kind of correctness, then fine, but don't pretend this is something that's not sought after by both OOP and FP practitioners.
About the "IO monad in business" issue: there's ways to solve it without having to pass IO through business layers or having to break architectural constraints. In the OOP architectures alone there's lots of patterns to avoid doing it already, and if you're doing it should all be in place, probably by passing a repository down to the business layer. In FP there are similar patterns to avoid needing a monad down in business code, passing down a repository-analog is enough. If you can't solve it without a "hack", then it's fine: that's just technical debt. That's on you to fix later. Or not, it's your work. About the question: gotta need more context for that, that's the vaguest thing someone asked me lately.
It's however one's own choice to decide how to deal with that. I prefer using constraints imposed by the typing system. You're free to do otherwise, but don't imply nobody wants it like you did in your first post, as there's people who find it useful. Once again, not everything is about you and you alone.
I've found Dart to be perfectly adequate. Like Go it doesn't try to be overly clever; unlike Go it doesn't consider verbosity to be a feature, and believes you're capable of using advanced techniques like ternary expressions responsibly.