Erlang versus Go

Three big differences in comparison with Erlang: 1- Cannot externally kill a process (yes, ergo processes have a Kill method, but the process will be in a "zombie" state until the current message handlers return... maybe stuck forever) 2- No hot code reloading. 3- No per-process GC.

Ergo: Erlang-inspired event driven actor framework in Go

(github.com/ergo-services)

Interview to Joe Armstrong

This is the first post in my Interviewing the Parallel Programming Idols-Series. My interview partner today is Joe Armstrong, one of the founding fathers of the Erlang programming language. He presently works for Ericsson, where he designed the very first version of Erlang (that was a long time ago in 1986). He is also co-author of the book on Erlang to date: Concurrent Programming in Erlang. And soon, we will have the pleasure of having another book from him in association with the Pragmatic Programmers (this time with him as the main author) – Programming Erlang: Software for a Concurrent World. Besides writing books and inventing programming languages, he teaches courses on Erlang, pursued his PhD in computer science, founded one of the first Erlang startups and enjoys his motorcycle. I wonder where he finds the time to do all that. 😀 But enough with the preface, let’s start with the interview. The first five questions are about parallel programming in general: Michael: As we are entering the many-core era, do you think parallel computing is finally going to be embraced by the mainstream? Or is this just another phase and soon the only people interested in parallel programming will be the members of the high performance community (once again) ? Joe: mainstream yes yes yes – we’re talking about potentially doubling efficiency on a dual-core quadrupling efficiency on a 4x core etc. I have had programs running 18 times faster on a 32 core machine. This is x 18 – we’re used to looking for 5% – 10% improvements by re-coding parts of our applications not 400% or 1800% – this effects all software. Michael: From time to time a heated discussion evolves on the net regarding the issue of whether shared-memory programming or message passing is the superior way to do parallel programming. What is your opinion on this? Joe: Shared memory systems are impossibly difficult to understand and get right, especially when errors occur. It’s bad enough without errors, but with errors it’s virtually impossible. If a program holds a lock and is messing around with shared memory and crashes how the heck can the other processes know what it was doing and fix up the errors? Transaction memories and pure message passing system suffer from none of these problems. Michael: From your point of view, what are the most exciting developments /innovations regarding parallel programming going on presently or during the last few years? Joe: P2P architectures, distributed hash tables, planet-scale integration of systems things like planet lab etc. Things like bit torrent are destroying traditional industries, the spinning jenny destroyed the home yarn spinning industry in the 1770’s bit torrent is doing the same thing to the record industry. It’s not a question of if it happens it’s a question of when. Michael: Where do you see the future of parallel programming? Are there any “silver bullets” on the horizon? Joe: Yes – pure message passing infrastructures will solve many problems (things like amazon simple queue service). This is back to Paul Morisson’s flow based programming. Michael: One of the most pressing issues presently appears to be that parallel programming is still harder and less productive than its sequential counterpart. Is there any way to change this in your opinion? Joe: It’s not harder – it’s hard because the dominant model is locks, threads, shared memory – now that is hard. Pure message passing systems are easy to program and reason about. The world is parallel – we are parallel. So much for the first part of this interview. Without further ado, here is the second part about Erlang: Michael: What are the specific strengths and weaknesses of Erlang as compared to other parallel programming systems? Where would you like it to improve? Joe: Strengths: It was designed for building fault-tolerant systems, so it degrades nicely in the presence of software and hardware failures. It takes failure seriously. Processes and failure handling is a defined part of the language and NOT something provided by the OS. Weakness – distributed Erlang has all-or-nothing security. It would be better to have different levels of security and capability or trust based security models. Michael: If you could start again from scratch in designing Erlang, what would you do differently? Joe: Michael: Are there any specific tools you would like to recommend to people who want to program in Erlang? IDEs? Editors? Debuggers? Profilers? Correctness Tools? Any others? Joe: No – 95% of all the fun can be had with the compiler alone. Then people get very religious about their IDE’s etc. Me, I use emacs and make and xterm. There are pointy clicky things which some people love but I can’t speak about these from personal experience. Michael: Please share a little advice on how to get started for programmers new to Erlang! How would you start? Any books? Tutorials? Resources on the internet? And where is the best place to ask questions about it? Joe: Books – (shameless plug) read my new book – it will be coming out really soon. Michael: What is the worst mistake you have ever encountered in a Erlang program? Joe: Programs without documentation – I hate it when people say “read the code” – the code is the solution to a problem – by reading the code I have to guess what the problem was, and this is error prone. I like to be told what the problem was, not guess. So the worst mistake was when I wrote a multi-page comment to explain some particular tricky point in a program only to find that in a later version somebody had removed the entire comment. Michael: Thank you very much for the interview!