4 ms·

Disclosure: I am a Go contributor and my day job consists in writing and maintaining Erlang systems. I am not biased towards any of them, on the contrary, I rea

• jerf 13y ago
  "Or is it just your personal opinion?" Of course it is. But contrary to the occasional Erlang syntax defender, after 8 years of use I still find it klunky. It's klunky enough that I find myself frequently having to override a desire to do something the easy, wrong way rather than the harder, right way. I consider this a great sin. 'Let’s go to the next point where you claim that Erlang is a “bad” functional language. What does that mean? “Bad”?' It makes everything functional a real pain. Yes, you can pass functions around, but the syntax is klunky and annoying enough that you don't want to do it. Practical usage of Erlang ends up using it as an imperative language with a "strange" restriction against using the same variable twice (leading to the very common Result, Result1 = Something(Result), Result2 = SomethingElse(Result2), etc pattern), not as a functional language. Compare the structure of Erlang code with other functional languages; Erlang looks more like imperative code than functional code. It's a bad functional language. It's a decent enough language itself, but it's not a good functional language. And let me pull that out and emphasize that... I'm not looking at the theoretical design issues of the language, I am looking at what code comes out in the real world. Erlang is not programmed functionally. 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. As near as I can tell, virtually nothing would require any significant rearchitecting, or indeed even any API changes to speak of. It's entirely incidental to the real considerations of total process isolation and message passing. Erlang is programmed procedurally, with isolation between actors being the primary isolation tool. 'As a user of both languages I have no idea what you mean when you say “there's still some nice aspects of the Erlang language as compared to Go, you've still gotten quite a bit of the Erlang value out of Go”.' In terms of learning multiple paradigms, if you're already intimately familiar with Go, Erlang won't teach you very much. "Only someone without experience in the languages would say that the concurrency in Erlang is like the one in Go." I have extensive experiences in both. 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. Compare with the incredible differences that you get in Haskell designs, or conventional threading designs. With just a bit of grease code added to Go, you can straight-up port an Erlang design to a Go design. This would not be optimal in Haskell, and not be practical in a pthreads&locking-based world or an event-based world like Node, both of which would exert significant pressures to structure your code in other ways. Again, I am looking at how the designs come out, not the theoretical considerations. 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. For all the superficial differences, if you already know one, if you're out to get a lot of experience in the different languages in the world, you're better off learning something else entirely than go learn the other. Erlang has some advantages on the crash-first front and multi-node stuff, but they aren't open-your-eyes perspective changing the way that, say, your first encounter with closures are, or a read-through of the SICP is. 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. 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. (Mine is, though, but even then it's not stopping me.) For that matter, my experience is that Erlang's multi-node stuff is a bit oversold. Less is provided that is often claimed (you certainly do not simply write idiomatic Erlang code and get a multi-node capable system; you must write a multi-node capable system, Erlang just gives you a few primitives. Useful, but nowhere near a complete solution.) and I personally have had huge stability problems with Mnesia for years. It just likes to stop clustering sometimes, for no apparent reason, on machines sharing a switch, multiple times a week, on a load that shouldn't be a problem.