Robert Virding is not “the occasional Erlang syntax defender”, look him up. Or were you referring to myself maybe? Anyway, I’ve been using Erlang, too, since about 2000 and I cannot relate to “doing things the wrong way rather than the harder, right way”, I guess it works in a different way for you.

What practical usage of Erlang are you talking about? I work in telco and I have yet to see that practical usage of Erlang ends up using it as an imperative language. What you are referring to can happen in many other functional languages when used by people without FP experience. I don’t see how this is related to Erlang in an explicit manner. I agree with you that it does not provide what Haskell does but it’s a functional programming language, wether you like it or not.

You talk too general. Again, which real world are you referring to, I am working in telco and the quality of the code is impressive in most of the areas. If you work in a startup where programmers used Node and Ruby until yesterday and today they are doing CRUD with Erlang then yeah, probably the quality of your real world Erlang lets to be desired or maybe not, but you get the point. However, the code that I had contact with so far was functional, easy to understand and reason about, despite being written in Erlang.

-- In fact you could strip it out entirely, allow in-process "mutation", and as long as you prevented processes from being able to share any data, you would not notice the difference, excepting that your code might get simpler. --

Erlang is a niche language, you can also prevent dangling pointers, that’s not the point though, people make mistakes. The fact that everything is immutable is very important in the domain that Erlang was conceived for. What do you mean that the code might get simpler? Are you sure? I guess it would get more complicated since you no longer have the immutability guarantee.

-- Erlang is programmed procedurally, with isolation between actors being the primary isolation tool. --

Says who? And which Erlang are we referring to?

-- In terms of learning multiple paradigms, if you're already intimately familiar with Go, Erlang won't teach you very much. --

It will teach you some functional programming concepts, requirements and architecture of real-world soft real-time distributed systems (given that you will not ignore OTP), the fail first concept. These are not light subjects. As I said earlier, I am very intimately familiar with Go. I contribute code to the project and use it almost daily, however I fail to see how Go would learn me anything about these issues, and this list is big and important enough for me so that it would make it worth to learn something about Erlang, probably not good enough for you and I understand that.

-- I have extensive experiences in both. --

Please allow me to have my doubts about that. What kind of systems have you built with Go, how about Erlang? Have you tried to implement 3GPP in Go for instance, how about Erlang? Are you confident that you could reimplement 3GPP in Go with minimal effort, and get back the same guarantees that you get for free in Erlang? If not, how can you reason that Erlang brings nothing new to the table if you already know Go.

-- On the grand scale of things, they are fairly similar. Locally they have a lot of differences, but designs come out fairly similar in both cases. --

No, they are not. They are completely different, the only commonality being that they offer concurrency primitives. Again, what kind of systems are we talking about? CRUD web apps?

-- With just a bit of grease code added to Go, you can straight-up port an Erlang design to a Go design. --

Right, I am really curious to see someone porting a distributed Erlang system to Go in the same amount of code, with the same safety guarantees, with “just a bit of grease code added“. I am not saying that it is not possible to achieve something similar, I am saying that you will probably need a lot more work than you imagine or describe here, and your first attempt will be 50x less robust than the Erlang solution. Not to talk about hot code reload for instance, which alone would drive you insane. And I am not talking about some kill main process and keep descriptor alive, then switch to the process carrying the new version kind of thing, I am talking about real code swapping like the one that you can achieve in an Erlang system.

-- I think perhaps the perspective difference here is that I've also got a great deal more than just Erlang and Go under my belt. --

Yeah, I guess me too, the only difference is that when I say I have something under my belt, I really have it, unlike lots of other people that talk from what they read in the news.

-- You missed the biggest practical difference between the languages, which is that Go's synchronization primitives default to synchronous and Erlang's to asynchronous. I find that dominates most of the other differences you listed. --

No, I omitted that one intentionally since it’s a lot more subtle than the obvious differences that I was trying to describe.

-- As opposed to issues like garbage collection, which hardly even enter your mind until you've got a system larger than what your average Go programmer will encounter. --

Right, as I said before, you probably work with CRUD web apps (which is not a negative thing) but in my world these kind of things are of crucial importance. Please go ahead and implement soft real-time systems ignoring this aspect and then fix it later when you “got a system larger than what your average Go programmer will encounter“. I was actually talking about exactly those kind of systems in my first comment when I said that the two languages have nothing in common because, you see, Erlang was conceived precisely those kinds of problems that you take out of discussion and then conclude that they are more or less the same. I guess we can agree that for some systems you can get the same out of both languages, but not for any systems.

-- For that matter, my experience is that Erlang's multi-node stuff is a bit oversold. --

Yes, if you build web-apps probably. If you want to implement distributed systems they are not oversold.

-- and I personally have had huge stability problems with Mnesia for years. --

Maybe, but without facts, means nothing. I could tell you that I used Mnesia in lots of systems, the kind that millions of people use, and never encountered such problems. So yeah, each to its own.