Ask HN: Why isn't Erlang more popular?

This. It's amazing and powerful if you need 1m+ client connections per server. Outside of the epic scale engineering problems of facebook, twitter, google, amazon, whatsapp... It's very difficult to get anything done with Erlang.

If you have fewer than a million people using your application at a time, you're probably better off writing it in a more normal language.

I'm seriously thinking about Erlang now. What raised my eyebrows was "2-3 million concurrent connections on a single FreeBSD box"[this is what WhatsApp achieved]. Async network IO can be done with library support in Python, natively in nodeJS, etc. I wonder if one can push those stacks to this level.

You can recover a substantial portion, but there's a few things you can't quite get back. Since Go is a mutable-state language, and also a shared-state language (isolation is by convention, not by language design), you have to live with the consequences of that. In my supervisor tree implementation, the restart of a monitored goroutine is just to fire off a new goroutine on the exact same object again; if you still have bad state lying around and immediately crash again, well, too bad, the supervisor can't do anything about that. (Except not thrash the processor with endless restarts.) In contrast, when an Erlang supervisor restarts a process, it is guaranteed to be a fresh process with no shared state from the one that just crashed. It's much more likely to not immediately crash.

(I fiddled with having the user specify a closure that is supposed to "create" a new object for the restart, but then simplified that away when I realized that the closure itself could well have mutable state too. Better just to stick with the simpler interface and document the consequences of failing to clean out state at the beginning of your monitored code. On the plus side, so far the interface for the supervised-things is "Serve()" and "Stop()", and nothing else; hard to argue with that level of simplicity!)

You also won't ever be able to recover live code restarts; you can try to transfer all state to a new process, including file handles, but that's a lot of implementation work. (I'm stuck right now on the fact that my connections are encrypted, and the encryption code won't let me even get to the state, let alone transfer and reconstitute it somewhere else. Someone's got some code for moving file handles around on GitHub but I can't seem to Google it up.) Most people already live in a world where live restarts are difficult or impossible, though, so they won't miss that. Getting a REPL into a live Go server is impossible, at least with Go itself, and will also probably never be as clean as Erlang. (Go "2.0" could fix that with an official Go interpreter, which is the missing bit. I can handle the sockets, I can bind readline and give you a nicer REPL, but interpreting Go is a challenge. Progress is being made, I believe as part of the new compiler implementation, but I'm not sure anyone has this as an explicit goal.) Again, most people live in a world where they already don't have a REPL into their running code, and therefore won't miss this.

There's also some more subtle semantic differences, but I'm saving that for a blog post. (It gets long, especially if I first have to explain Erlang, which is what the blog post does.)

I'm always baffled by these kinds of statements. I learned ocaml first, so haskell wasn't too big a leap for me. But I did get to watch my wife go through the process of learning haskell, and she didn't have any more problems than learning any other language.

My wife is a web designer. She has no interest in programming. She taught herself PHP and javascript because she needed to use them. When she finally got to the point where she couldn't tolerate PHP's shittiness anymore, she asked me what she should use instead. I said "scala is a good choice, or you could just skip a step and go straight to haskell". She tried both, decided on haskell because she didn't like lift or play, and proceeded to teach herself haskell. She has never read real world haskell, or even learn you a haskell. I just asked her what a monad is: "Beats me, just use do and the arrow things". She's already finished two big websites written in haskell. This idea that you need to be a compsci phd or something to use haskell is simply not reality.

I do not have direct knowledge, but I'm pretty sure the problem with "network" channels in Go is the synchronous nature of channels. Even if we did have a perfect network, that works poorly across a network, and if the network starts degrading even a bit the sync channels just completely fall apart. The language treats them as a fast synchronization method. You can very nearly translate RPC to "channel" in this argument and it works: https://news.ycombinator.com/item?id=2318249 (Err, I did try to find a better explanation that wasn't mine, but Googling up an RPC criticism was hard, because saying "RPC" comes up with a pretty big search pool to be trying to find the word "bad" in...)

My reign library basically just ports over the Erlang idea; asynch messages, PID-like things that can be transmitted across the network and identify the same mailboxes within a cluster. It's meant to be a porting aid, not a solution you'd reach for in Go to create a brand new program. (If you do that, it's on you.) Clustering like this is nontrivial and the big reason I'm sitting on the code locally until clustering is at least working under some circumstances; without clustering support, the mailboxes are just an invitation to write nonidiomatic code for no gain.