The Secret Sauce of Erlang: Opinionated Language and Focused Community
Please log in to watch this conference skillscast.
As one who joined the Erlang community before it really even was one, I've had reason to consider and debate what makes Erlang special. Because it _is_ special. In this talk, I will summarize some of my own thoughts on the matter, exemplified by some war stories. My thesis is that while the impetus for creating the language is important, the evolution of the community and the niches where Erlang got some traction also play a vital role. Learning what has been successful in Erlang, what hasn't, and why, could give important clues not just to future adopters, but perhaps also to other communities (Elixir?) still developing a personality.
Q&A
Question: What was the programming language PLEX like, is it documented anywhere? What kind of language was it?
Answer: The PLEX programming language was a form of event-based high-level assembly. There are some papers, I think, where you can see what it looks like. It evolved into more of a structured programming language, and HL-PLEX (High-Level PLEX) actually had a form of selective message reception.
“The Execution Model for APZ/PLEX” http://www.es.mdh.se/pdf_publications/663.pdf
Found this comment about PLEX:
Syntactically it was a cross between Fortran and a macro assembler. You couldn't pass parameters to functions, for example; you assigned them to variables instead, much like the limited GOSUB of an 8-bit BASIC. The advantage was that there was a clean one-to-one correspondence between the source code and the generated assembly code, a necessity when it came to writing patches for live systems where taking them down for maintenance was Very Bad Indeed.
https://prog21.dadgum.com/22.html
And here is a more detailed description of it. I think it reflects how PLEX programming was very much a structural approach in the sense that the language reflected the structure of the system (not in the sense of structured programming as we know it). The language itself was fairly low-level, but the whole system, including the APZ CPU, was custom-built for the task, and PLEX was never intended to run outside of that system.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.4843&rep=rep1&type=pdf
BTW, regarding patches for live systems, this was often done by local experts in different local markets. The old world of fixed-line telephony was quite fragmented, and each market had its own set of local protocols. This was one important reason why the culture of the fixed-line division was decentralized: there was simply no way to centrally support all local varieties.
Question: Why was Unix/Solaris not considered a good OS for telephony systems?
Was Erlang/OTP running on other Operating Systems other than Unix?
Answer: There were some concerns about the memory integrity of Unix systems when running non-stop. Basically, our systems were intended to support better than "5-nines" availability, so ideally, they should just keep running. While there were reasons to believe that Unix could deliver (we thought so), the tradition had been to use proprietary OS:es, custom-made for the stringent requirements. Scheduling was also an area where there was reason to be suspicious, but since Erlang executed in a VM, it wasn't so much of an issue for us.
We (and CSLab) did believe that it would work nicely, and it did.
A few years later, I was in a meeting where an architect of a proprietary real-time OS said: "You can't build 5-nines systems on top of UNIX!". I commented that "We have been doing it for years", and he said, "yeah, if you use Erlang!", as if this was somehow cheating.
Initially, Erlang/OTP was made for Unix, but there was also a port to OSE/Delta, one to VxWorks, one to Windows, …
Question: why the opposition to type checking? do you think this might change in the near future? many other dynamic languages have recently warmed to type hinting...
Answer (Franceso Cesarini): No one knew how to write a type system, so it was never done. The problem became worse when, because of language design issues, it became very hard to bolt one on without changing the semantics of the language.
Work is happening to make a static type system possible in one of the big tech companies, results will be published soon.
From our end, we actually got used to dealing with it in the programming model (as you need to handle corrupt state and bugs anyhow), so it never bothered us.
(Ulf): One concern was that it would need to derive types from the already fairly large code base, and also report errors in a way that didn't require a PhD in type theory to understand.
(Aside: Phil Wadler and Simon Marlow published this paper on building a type system for Erlang. https://homepages.inf.ed.ac.uk/wadler/papers/erlang/erlang.pdf)
Another concern was that Erlang was deliberately designed to support live code updates and evolving systems over multi-year life spans (ideally never being stopped in the process). It was by no means clear how to do that with global type analysis.
Lastly, many type analysis approaches did reasonably well with function calls, but couldn't help with message passing. Actually, this was (I believe) a reason why Concurrent ML went for fully synchronous message passing: not to break the type system.
Now, Dialyzer was eventually accepted, since it struck a nice compromise, and people should use it as much as they can.
Personally, I think that getting typing right, you have to do it from the very beginning. Evolving Erlang into a statically strongly typed language will probably never work. OTOH, perhaps Cloud Haskell is what you should go with instead, then.
Question: You mentioned UX not being a focus for Erlang (with a remark "Web, GUI..."). What about the UX of using the language itself? That seems to be gaining visibility and popularity recently with seemingly minor issues (whitespace, syntactic sugar) having lots of discussion in e.g. TypeScript, Go (and the recent Scala syntax changes).
Answer: the UX of the language itself? Yeah, well, it's an acquired taste. :) I'm not really sure what to say about it.
Question: my question is about whether Erlang is still used in Ericsson systems. also, do you know what languages other telecoms providers (Nokia, Alcatel, etc) use by any chance?
Answer: Yes, actually, Erlang is now used in some of Ericsson's most important products. However, the company has learned a lesson regarding being too transparent about technology choices. Also, there seems to be a silent agreement to simply do it and not talk about it much.
Regarding what other telco companies use, I actually have no idea.
Question: You mentioned being selective in which areas to not pursue in Erlang e.g. GUIs. Are there any areas that Erlang should be pursuing that it currently isn’t?
Answer: I happen to think that Erlang would be amazing for complex embedded IoT devices. This was something we tried to pursue at Feuerlabs, but as I said, I think we were way ahead of the curve. With e.g. GRISP2, I think the threshold should be lower today, and there is much to be done there.
Question: What's your thoughts about the Elixir language/community? Did you think it has the same values of Erlang? How do you see the adoption of Erlang by the new generation of developers?
Answer: Re. Elixir, I think it's a great development.
One thing that I particularly like is that the Elixir community actually has a slightly different focus, and a much better story not least in the area of Web UX. This seems to be in line with my idea that community focus is very important. Without this perspective, one might argue that Elixir doesn't really add much to Erlang: it relies on the goodness of OTP, offers a different syntax, but mostly the same semantics. Yet, these things do matter, and most importantly, they have managed to attract a new group of developers and build a strong culture of their own.
Having lived through a period where there was basically no job market outside Ericsson for Erlang developers, and some political turmoil inside the company around Erlang, I've come to think that Erlang is worth learning for its conceptual strengths, even if you later end up using another language. Akka is an example of how Erlang concepts can be imported and successfully applied in other environments, and Cloud Haskell was explicitly a project to implement Erlang-style concurrency in Haskell.
Of course, learning Elixir should give you access to the same concepts, but again, the Erlang community itself is a strong reason to learn Erlang, so I very much hope that new developers will give it a chance.
YOU MAY ALSO LIKE:
The Secret Sauce of Erlang: Opinionated Language and Focused Community
Ulf Wiger
Being a cat person, Ulf has noticed how cats love to seek out the spots where they can observe everything going on in their world. As CTO of Erlang Solutions, Ulf has such a vista of the Erlang community.