Comment by rdtsc | Hacker News Reader

Comment by rdtsc | Hacker News Reader

Erlang currently is probably the most practically used functional language. It has been in production for decades. It manages probably 50% of world's smartphone <-> internet traffic. There are many database built on it, message processing backends, handles hundreds of millions of connected device (WhatsApp).

Yet most people forget it about when talking about "functional", and end up comparing Python to Haskell basically. Maybe with F# thrown in there for good measure.

Erlang has solid closure support, tail call elimination, immutable data structures and variables, encourages using recursion instead of for loops, in practice folds/maps are common constructs instead of an oddity etc (like say in Python).

It even has an optional success typing system:

http://learnyousomeerlang.com/dialyzer

EDIT: Elixir is using Erlang's VM as well and almost everything about language features above apply to it. If you don't want to give Erlang a try, check out Elixir. It also has one of the friendliest communities for new-comers.

It's weird, I always kind of wondered why Erlang gets left out of the FP discussions. It's not as dogmatic as Haskell or something, but functional-ness is kind of its bread and butter.

I think the answer is that Erlang's creators are not academics and they sort of never went out of their way to tout functional properties of their language. Functional properties fell out of their requirements for simplicity, fault tolerance, concurrency and reliability. In other words the goal of Erlang was never to be functional but to be useful for fault tolerant distributed systems.

Someone down the line probably mentioned to them "Hey, btw, did you know you have a functional language?" And they probably shrugged and said "Oh, cool!"

I would guess Joe, Robert or Mike never went about reading papers on type theory, thinking about meta-circular evaluators, or y combinators etc and said "We need that, let's implement it!". Instead, they started with stuff like "let's minimize state" so made state explicitly passed in. "Let's minimize mutable state", so make data immutable. So then need recursion instead of for loops, so let's think about tail call elimination. They played with Prolog so language inherited the base Prolog syntax which has a functional taste to it, that helped as well.

The same thing kind of happened with the actor paradigm. They never started with a goal of implemented an actor / message passing programming paradigm. It just fell out of fault isolation property. Someone later told them "Oh btw, did you know you have implemented the actor paradigm?" and they probably shrugged and said "Oh, cool!" and went back to doing whatever they were doing.

There's a tremendous amount of truth to this.

I've talked with Robert at some length and listened to his talk on LFE, and that's more or less the way of it, plus Robert himself was an old Lisp buff from way back (hence Lisp-flavored Erlang). It was basically a combination of "this is what we need to do what we want" and occasionally bits of "well of course you do it that way".

That was actually how he described tail call elimination in his LFE talk: "of course you have TCE/O, why the hell wouldn't you?"

Which was a refreshing perspective to me, considering how many programmers still seem to have been heavily indoctrinated to the idea that recursion is automatically bad.

Because the Erlang people don't do 'sexy', they just do stuff that quietly works. They're too busy working to be a part of the social networks around programming languages, they don't care whether you care, they care whether they can get their job done.

One Erlang project that is rather friendly up-front is the Zotonic[1] web framework. As someone new to Erlang, it's great to be able to get off the ground running with such useful resources.

1. https://zotonic.com

Your link is broken; I don't think they use SSL.

Because haskell is almost a platform for discussing and implementing FP concepts. Especially if you want type system. (Not sure how much is ML discussed these days)

Erland on the other hand, is targeted on soft-real-time distributed systems. How was the quote? "Every soft-realtime highly availabe distributed system contains informally specified, incomplete and bug ridden implementation of erlang." Or something like that.

It's also driving almost all of the non-Google ad networks, has a pretty sizable footprint in high-finance, and increasing numbers of online gaming (mobile and console) backends are built with it (or its younger cousin, Elixir).

One of the most powerful things about Erlang is that there is no state other than what you are passed in locally (of course, there are still side-effect dumps, like databases & files, but those can be well-managed behind gen_server).

This property makes Erlang programs incredibly easy to reason about and test.

Agree with that. Makes it very nice jumping in understanding a complicated system -- because it is obvious how state is mutated by looking at the current function. In a typical state heavy OO, I found I am lost more often because I have no idea what the current state is and how it got to that state if it is broken when debugging.

another plug for Elixir: I'm using it right now w/ the Phoenix framework and love it. The last time I played around w/ Erlang I was frustrated and confused, so it's either a big improvement or I've gotten smarter! (more likely the former)

I think it is probably a little of both. For me, Elixir was the crutch I needed in order to break through the Erlang veil. I still like Elixir's syntax a lot better, so I tend to stick with it, but I definitely understand Erlang more because of Elixir.

Reply on news.ycombinator.com