But somehow the Haskell, OCaml and Scala users never want to include Erlang when talking about "functional". Even though it is probably the most practically used functional language.
Would love to get some evidence to back up Erlang being the most practically used functionally used language, because for all I know, it's hardly used at all these days.
But, "practical" doesn't show up on everybody's radar much these days with so much effort focused around fads-of-the-half-decade.
Erlang is made by professionals with decades of experience who grow the system towards being the most stable, scalable, safe, and as understandable as possible. People use Erlang, solve problems, stay quiet, then make money using it.
On the other hand, the thought leader these days seems to be Go (even though it's made by out of touch weirdos (review: http://www.evanmiller.org/four-days-of-go.html)) and has a creepy cult/fanatical following more suited to tribal sportsball teams than what we would expect from professional technical work needing to be stable over the long term.
Who are they, besides Joe? Can you at least provide their names?
I'd really like to take a look at their credentials because beyond WhatsApp and an obscure Ericsson router from 20 years ago, there isn't much data to go by.
And there is plenty of evidence to show that C, C++, Java and more recently Go have some pretty strong success stories to justify their claim to scalability.
Pretty sure that Erlang would barely register as a blip on such a chart.
But the feature set of Facebook is not all implemented in Haskell or OCaml either. There is lots of PHP etc.
Lisp is not much at all like these languages. Nor is Erlang, though it is vastly closer.
This is not true. Having written a good amount of OCaml I would argue that programming with side-effects in OCaml is extremely approachable - almost as much as Clojure. There are mutable data structures in the stdlib (Array, Hashtbl) and IO etc. is straightforward. Like Clojure, there exists a ref type which can be easily mutated. It's one of the reasons why OCaml strikes as an extremely pragmatic language to me.
(0) Absolutely anything goes. Examples: Racket (in the REPL), Lisp, Clojure, Scala, Erlang, etc.
(1) Values are immutable, but any computation might have any effect. Examples: Standard ML, OCaml (mostly), Racket (mostly).
(2) Values are immutable, and computations are type-annotated with their possible effects. Examples: Haskell, Idris, Ur/Web.
Or functional as having proper closures.
Or tail call elimination.
Or using immutable data, or immutable variables.
Or minimizing mutable state.
Or being decalrative.
etc...
;-)
Closures are an implementation detail.
> Or tail cail elimination.
Tail call elimination is just the right way to implement tail calls in a strict language.
> Or using immutable data, or immutable variables.
Variables don't “mutate”, they are substituted with other expressions. What imperative languages have is “assignables”.
> Or minimizing mutable state.
Functional programs have plenty of state - which changes over time. You can't have computation without traversing a state space - over time.
> Or being declarative.
What (technical!) definition “declarative” are you using?
https://redmonk.com/sogrady/2015/07/01/language-rankings-6-1...
That seems like a very dangerous thing to do to me.
They give you a rough head count yet you have absolutely no idea what percentage of them are actually good programmers you'd want to hire.
Usually the more popular something is, the more you need to weed out bad candidates as well; its kind of killing the popularity argument.
If you pick a technology based on its popularity or visible activity you're only making it much easier for your competitors to crush you really.
I can only refer to pg's Beating the Averages at this point: http://www.paulgraham.com/avg.html
Has no relevance to actual language quality, potential or value.
If this wasn't the case, then no language would ever pass, or fall behind, another language in popularity.
Popularity is a reflection of already-realized value. That's all.