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.
AdRoll Facebook Chat TMobile
http://erlang.org/faq/introduction.html
Amazon SimpleDB Delicious From: http://stackoverflow.com/questions/1636455/where-is-erlang-u...
Also many of the companies using Riak (written in Erlang) also leverage erlang. Some pretty big names use it.
http://basho.com/about/customers/
I would say that Erlang has more than proved itself.
One aspect of it is that it is used more of an infrastructure language so not many people see it as glamorous as rushing out to the Go community to brag about their new backend. Its a lot of mature companies that have been around a while and don't really need to show off their infrastructure.
Also Elixir is gaining momentum (but still a blip) as a very viable language built on erlang.
Use what you want and what works.
Ah yes, the "dark matter" argument. It's out there but nobody can see it. You'll just have to trust me.
As for listing companies that use Erlang, plenty of companies use PHP and COBOL too. This doesn't say anything about whether these languages are the most adequate for the task and whether these projects wouldn't be in a better shape if written in a different language.
One of them is here on HN: https://news.ycombinator.com/user?id=rvirding
Pretty sure that Erlang would barely register as a blip on such a chart.
There's a ton of stuff written in Erlang out there. A lot of really core infrastructure services that have to just run and run and run.
It's not particularly trendy, but it gets shit done, and it does so with a quiet dignity. :-)
erlang was literally developed for telephone switches
https://en.wikipedia.org/wiki/Ericsson#Products_and_services
Here's some sources that indicate that Erlang is still in daily use at Ericsson:
http://www.ericsson.com/ericsson/corpinfo/publications/revie...
http://www.ericsson.com/news/141204-inside-erlang-creator-jo...
I'm sorry I can't find the exact video I saw from Joe, but he's generally quite proud of the reach of Erlang so you'll find him stating the facts about how much of the mobile and telecoms infrastructure it supports in a few of his videos! I hope that helps.
https://youtu.be/rQIE22e0cW8?t=662
And it is also fun!
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.
Out of curiosity: Would you consider Prolog a language in which you can do “denotational” programming?
The awkwardness I'm talking about comes primarily from the non-orthogonality of Scala's features. For instance, there are situations where subclasses and implicits are both reasonable alternatives for a given programming task. On the other hand, in ML and Haskell, it is often clear which language feature is the right tool for the job.
I think Prolog counts here, too. But it's a weirder one.
Lisp doesn't actually exist. Lisp is just axioms. You run an implementation of Lisp allowing various operations. Some flavors actually have (practically) zero mutability. You just create functions and cons cells and the rest of the world gets built on top of those.
But, pure functional systems are useless (to be purely functional would mean you can't even do I/O... your program would just heat up the computer, which, in a way, is its own form of output, so you can't ever be fully functional).
Every functional language gets non-functional at some point for data processing, bootstrapping, loading/saving programs, and the best functional languages even have optional mutability constructs for performance (see: !). You can't create the most performant data structures possible if all your operations require path copying, but mutability should be reserved for internal high performance library creation and avoided in business logic/application level code to make systems easier to reason about.
And pure languages aren't useless. Not being able to do I/O can be good for many purposes. Pure Haskell is still able to model computations involving I/O, which are then executed by a trusted external runtime. There are benefits to disallowing arbitrary effects, which is also why several new languages take purity even further and disallow infinite recursion.
Now, I repeat, how exactly is Lisp “just axioms”? What are the axioms in question? The mathematical ignorance of some of Lisp's proponents never ceases to amaze me.
Any comment that begins with that is unlikely to be a good fit for HN. Please post civilly and substantively, or not at all.
We don't want programming language flamewars on HN, so please don't conduct them here.
As a result, "functional" has become pretty much meaningless when describing a programming language.
Plenty of people will disagree with it too.
functions are invoked in an encapsulating way, and no state is kept between function-cup-up-segments-of-code, but there is a R.E.P.L that (replies) when you invoke a (parens) which is, in LISP-land known as a program.
However, now that I have mind-dumped that ^ I recall haskell and erlang also being called "functional" but I don't know their syntax any more than a chimpanzee knows that the sun is round.
Note that the above definition says nothing about how functions are to be evaluated: strictly, lazily, memoizing previously computed results, or using magic. No general-purpose programming paradigm can make such decisions for the programmer.
Lisp, especially in it's early implementations is highly imperative. This is why when people talk about Clojure they always talk about Immutability, it's part of what forces a functional style on the language.
And Lisp is highly imperative even today.
Heck, Haskell was barely ever mentioned.
Not to mention that the whole idea of functional programming was introduced to the programming world with McCarthy and Lisp.
(Except if you want to say that "Lisp is not functional, it supports many paradigms" -- but I find that tired. It is, at its core, functional).
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.
This is particularly infuriating because the proper way to handle bound variables is already known: https://en.wikipedia.org/wiki/De_Bruijn_index .
And the state of the Clojure REPL is as mutable and imperative as it gets, as my paste showed.
No, you can't: http://pastebin.com/SdbKM7V7
In ML and Haskell, a new variable might shadow an old one (if they have the same name), but they are still different variables.
Shadowing is slightly harder to implement than rebinding, but it provides a useful guarantee for the user: the meaning of existing definitions remains stable even if new definitions are introduced into the environment.
I'm inclined to think the Clojure REPL is more conducive to flailing around. Now, this might sound like derision, but it isn't intended that way: Flailing around can be a very time-efficient way to familiarize oneself with an unknown domain, especially if the cost of making wrong design decisions is small.
But at some point one has to consolidate what one already has, and, in my experience, Clojure makes this very difficult.
> I guess one programmer's sandbox is another programmer's hellish nightmare of mutability.
If you absolutely want mutable definitions, you can have them in Haskell (with some noise) and ML (with no noise) too: http://pastebin.com/00ScnFxC . So a Haskell or ML programmer always has at their disposal whatever they think is the best tool for the job.
Can I have it the other way around in Clojure?
Haha, yes. This is how I feel about Matlab, actually. But I suppose Clojure is no different in this respect.
I much prefer the Haskell approach: make dangerous things hard to do. Unfortunately, a majority of programmers consider that to be "unpractical".
But there's still no type-level distinction between immutable and mutable bindings, which is why included Scala in the “anything goes” category.
Well you can't mutate variables and data in Erlang. (Try X=1,X=2 in a repl, it will fail). There is a thing called process dictionary but it is frowned upon. Concurency is handled by processes. But that's a different thing.
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?
Except when they are not there done properly (cough cough Python), it not so fun doing functional programming.
> Tail call elimination is just the right way to implement tail calls in a strict language.
Well Erlang is not strict and has tail call elimination. Because of lack immutability, recursion is used. Without tail call elimination recursion will blow the stack.
> Variables don't “mutate”, they are substituted with other expressions. What imperative languages have is “assignables”.
Yes they do. X=X+1 -- Variable mutated. Like it or not that is the bread and butter of programming. Unless someone did strictly functional programming and math. Then I can see how they'd be very confused by that statement.
There is also immutable vs mutable data. For example both Erlang and Elixir have immutable data. But Elixir has mutable variable, while Erlang doesn't.
As for assignables, I've never heard that word. I went to the standard 4 year CS program. Seemingly did a regular curriculum. Is that a translation from another langauge or a functional programming terminology?
> Functional programs have plenty of state - which changes over time.
Some have more, some less. Minimizing means making it explicit, passing it around, using immutable data. As opposed to say sticking it in a large object instance in a global singleton and then everything calls 100 something methods to mutate it.
> What (technical!) definition “declarative” are you using?
The point I think is, it is just as technical as "functional" is. It has a bit of a "No True Scotsman" thing going for it.
But as a heuristic think maybe about when you'd use patern matching to destructure something vs say a nested set of if and elses.
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.