| As commented by others, F# was part of Microsoft Research, and not taken up by MS or other corporations when it was started. Erlang started out in Ericsson, a corporation. Elixir and LFE (Lisp Flavored Erlang) started out opensource and are still opensource. The term 'corporate self-interest' seems misplaced here, with the parenthetical remark turning it into the antonym of 'open-source'. The term proprietary, commercial or close-sourced seem more neutral and correct. Erlang started inhouse at Ericsson, like F# did at MS Research, except it was for a company's immediate business needs or 'self-interest' to program their telecomm switches. Elixir grew out of one person's frustration with Ruby's concurrency (Jose Valim), and a desire to have what Erlang offered him along with the BEAM VM and OTP. It has Ruby-like syntax, Jose is a popular Rubyist, and great tooling along with some other functional structures Jose added that he thought were missing in Erlang. [2] Pony is an OO, actor-based, open source language, yet it has a lot of corporate pickup from fintech and others, and it seems to be getting ready to shove Erlang/Elixir/LFE aside on concurrency and speed. It has fully-concurrent garbage collection that doesn't use the "poison pill" message approach to kill all actors. The creator of Pony, Sylvan Clebsch, has one foot in academia, and the other in business. He has worked on fintech, milsims, and games. [3] [1] http://www.ponylang.org/ [2] https://www.sitepoint.com/an-interview-with-elixir-creator-j... [3] http://www.curry-on.org/2015/sessions/pony-making-it-easier-... |
Unfortunately it is difficult to "prove" this definitively currently, until someone comes up with a "complexity polynomial metric over time" for code, except to talk to old programmers like myself (44) who have done this for a long while and gotten disillusioned due to all the time spent repairing OO complexity/tech debt bugs, and have become entranced by functional langs and the way they avoid inheritance, use immutable values and are super careful with state, all of which contributes to better long term code life
Fortunately I'm not the only old OO guy proclaiming this, I have John Carmack on my side:
http://www.gamasutra.com/view/news/169296/Indepth_Functional...
"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."
"No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."