The origin of the name "Erlang" is shrouded in rumor.

Sources generally agree that Bjarne Dacker named it, but what the name means is debatable: with most suggesting that it's either a reference to mathematician Agner Erlang, or an abbreviation of "Ericsson Language".
In "A History of Erlang", Joe Armstrong shares that his team even encouraged this mystery: What started as an experiment in “adding concurrency to Pr
Anyway, I just found a 2001 paper I'd never seen before, by Bjarne Dacker, titled "Introducing Concurrent Functional Programming in
the Telecommunications Industry".

In it, he admits to naming the language after the Danish mathematician!

link.springer.com/content/pdf/10… The next development step started with Prolog to which concu
Granted, this doesn't prove anything -- it's always possible that Bjarne had other ideas originally, but eventually grew to prefer the false etymology to his own -- but it is the first time I've seen an origin story spelled out so clearly by one of the early contributors.
Let's talk about Agner Krarup Erlang's work!

If you're like me, you probably don't recognize his name. If you worked in telecommunications or queueing theory in the 20th century though, that'd be a different story.

As far as I can tell, he basically invented the fields.
His contributions are so vast that his name is given to the units of "carried load" and "offered load":

With carried load, 1 erlang is the amount of traffic a single resource can process through continuous use: single telephone operator can process 1 erlang of traffic per hour.
Offered load is the average number of concurrent calls to a system, assuming that there are infinite resources available to process them.

This can calculated by multiplying the "call arrival rate" (λ) by the "average call-holding time" (h):

E = λh
If this looks familiar to you, it's because it's precisely Little's Law: one of the most remarkably versatile results in mathematics.

It shows up in everything from queues at the grocery store, to reasoning about the capacity of a web server.

Let's go back to Agner Erlang: in the paper I linked, Bjarne specifically called out the Erlang loss formula, also known as the Erlang-B formula

This formula calculates the "blocking probability" for any queueing system: though it was originally described for telephone networks.
The blocking probability of a system is the chance that any request to the system will fail because there are insufficient resources available to process that request.

Importantly, it only applies under the condition that a failed request is not queued or retried.
In its basic form, the Erlang-B formula is expressed as follows:

Here, "E" is the "offered traffic" we calculated using Little's Law, and "m" is the number of parallel resources available.
There's a simpler recursive expression though, that you can use to construct a table of the blocking probabilities for a given number of resources:
This is an incredibly elegant formula for thinking about systems, but keep in mind that it does have limitations.

For example, it assumes that the arrival rate of requests is constant, and so it can't be used to plan around your weekend project being criticized on Hacker News.
I don't know whether this is the real etymology behind the name "Erlang", but I hope it is.

For an ecosystem that spends so much time thinking about backpressure and load shedding to pay homage to the father of it all in this way is almost too good to be true.
This all only scratches the surface of the myriad ways Agner Erlang influenced traffic engineering, and also every other field that deals with systems.

I can't do his legacy justice, but I hope that next time you're provisioning a k8s cluster, you'll ask "What would Agner do?"
Anyway, next time I pull open @mononcqc's book "Erlang in Anger", I know what I'll be mentally substituting the name with.
I thought I was done with this thread, but I just found an incredibly relatable anecdote from his sister, about the way he'd fall asleep working, with the lamp still burning, only to immediately wake up and scold her if she were to ever turn it off.

From: web.archive.org/web/2011071912…

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Quinn Wilton

Quinn Wilton Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @wilton_quinn

31 May
I decided I should finally read Joe Armstrong's thesis, about building fault-tolerant distributed systems.

It has a lot of gems so far, but this sentence is amazing:

"The real world is concurrent and consists of a large number of events, many of which happen simultaneously"
Concurrent programming is easy:

1) Identify concurrent activities
2) Identify their relationships
3) ???
4) Profit! (write the program) A 3 step guide to writing concurrent programs, ending with &
I hope this doesn't come across as me making fun of Joe's work. Every page has been filled with wisdom so far and I can't wait to get through it.

I just love how nonchalant he is about one of the hardest types of programs to write.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!