Erlang/OTP – The fastest, cheapest way to build reliable clusters of computers (opens in new tab)

The renaming question has been debated at length multiple times, more recently in: http://erlang.org/pipermail/erlang-questions/2014-February/t...

Here's what I tell people when I mention Erlang and then OTP: "OTP stands for 'Open Telecom Platform', but it's just badly named due to old corporate history at Ericsson. It's more of a general development framework that includes generic versions of design patterns to build pretty much any Erlang application."

I have never received questions after that about the name -- people get more interested by what it contains than what the initials stand for.

For the argument about 'core Erlang devs', the post you mention is:

1. not from a core Erlang dev

2. actually from the main Erlang developer of Cowboy, one of Erlang's most used web server/framework

3. Right that JSON is a pretty inefficient serialization format, full of ambiguities and with many undesirable limitations.

4. It's also right that JSON contains nothing regarding hypertext within its data type (ignoring JSON-schema) and is therefore a weird choice for the web and REST, where hypertext is fundamental.

2600hz uses Erlang/OTP to build scalable, restful phone switches. Company was founded 3 years ago or so.

>Then you begin a 30 minute speech about the history of Erlang and phone switches

I don't do that. I'd want to do that like I'd want to give a 30 minute speech about what EMACS, UNIX, or GNU stands for. Instead, I'd just answer the question about what it was.

Yea, why understand your problem space and learn from history.

If only Erlangers spent more time on marketing and less time on building things!

I think it is a great name. It says this is reliable, old school and deep -- not questionable fad marketing fluff. But maybe it would help to do something like:

* eOTP

* iOTP

* openOTP

* OTPly

* bitOTP

* OTP2000

* Margay

* Marvelous Margay

* OTP Classic

It is a bit like SQL. Structured Query Language. I bet many don't even know the meaning. Or are there many unstructured query languages to compare it to...

I think OTP should mean a library that helps you build reliable software. Telecom is old and crusty but! that also means reliable. Phone system is surprisingly reliable compared to computer systems. You can play it off that legacy.

"See their arguments against why Erlang shouldn't support JSON"

Erlang supports JSON if you use a library[1], which is how pretty much every language other than javascript does it. Are you expecting native syntax or something?

[1] https://github.com/davisp/jiffy

The fact that OTP sounds like something less general than Erlang itself makes sense to me. If anyone with their own Big Architecture (e.g. Facebook, Amazon) they went all-in on Erlang, they would likely end up writing their own equivalent to OTP to work with that architecture. But the language itself would stay.

The extent to which this person, Loïc Hoguin, is out of touch is frightening.

Hopefully he doesn't speak for the rest of the Erlang community.

I appreciate the effort, but focusing on the multi-machine single-image clustering part would probably make more sense. Runing many processes on one machine is pretty easy and mainstream these days. Show me how to easily run code securely across a handful of dedicated machines (perhaps connected via ip6 and ipsec) - and you'll have my attention. ..

I'm still waiting on an update on dragonfly's ssi story now that there are no free and open ssi solutions for linux... i fondly remember having fun with open mosix...

Nope, that domain was in the bag for years (not by me though...)

That doesnt really solve all those problems in itself does it?

It's pretty cool but I don't think that it's open-source.

Erlang will work spectacularly well in those scenarios and is explicitly aimed at them, definitely not just for 'distributed computing within a single machine' (which is nonsense anyway). The reason why it can't deal well with network splits is better explained by internalizing this:

http://en.wikipedia.org/wiki/CAP_theorem

If I remember correctly, Erlang was designed for fault-tolerant telephone switches and there were always two of them (the switches) in one box, because the system had to cope with even hardware failures.

So Erlang is pretty much designed to deal with systems distributed on different machines, it's nice behaviour on modern multicore machines is just a byproduct of that.