We’ve all heard that Erlang was created for working with telecom switches, but I haven’t seen a discussion go any deeper. The original telecom switches, how did they communicate with each other? Was it some form of TCP, or a different protocol? Serial? Something proprietary?
I’d like to see how Erlang did its early communication, it would be interesting to study and possibly help me with my current project.
Here’s a short writeup about an early Erlang system (1999), the AXD 301:
Protocol-wise, these used technologies like ATM and frame-relay that are lower-level than IP. The article even calls out IP switching over ATM as a work-in-progress.
That’s an awesome find from 26 years ago. From the writeup:
Automatic recovery from software errors
The high-level characteristics of the Erlang programming language (Box B) yield high quality software programs. However, since it is virtually impossible to ascertain that a software application is absolutely bug-free, and since bugs or corrupt data almost always manifest themselves as a runtime execution error, the Erlang language and runtime system provide several mechanisms for detecting execution errors and for triggering error handlers. These mechanisms are used extensively in AXD 301 software. Ordinarily, when an execution error occurs, a single call is lost or a single ongoing management operation is aborted. If runtime recovery occurs too many times within a given time frame, the recovery action is escalated, meaning that the application on the processor is restarted and reinitialized.
So it looks like Erlang was kind of experimental, written in Prolog in the 80’s and really wasn’t used in production into 1993 or so, when networking protocols were becoming the norm. TCP, ATM, others.
OK… I post this a bit tongue-in-cheek, but I do think it’s relevant to the question.
Oh dear… I feel old. At the time this document was published I was managing a small data center and network for a chain of retail stores… I spent many a night logged into the Cisco routers at the core of our Frame Relay based WAN watching cross network latencies and watching LMI metrics with our telecom provider… and yes, we were at least contemplating if our next steps network-wise might include IP over ATM. I would say simpler times, but in this case I’m not so sure that the were .