"You cannot just bolt isolation on after the fact. You must design your language for it from the start."
Yes, I agree, and I'm sure I'm going to have many years of wishing they had. At the moment I don't have a better entrant in this field that is palatable to my coworkers, though. They've rather disliked Erlang (and not for lack of trying, and not for lack of good reasons, for that matter), Haskell's right out, and I'm running low on production-quality true isolation-based languages here. Several additional up-and-coming contenders; I'm sure if I could have used Rust-from-2018 I'd take that in a heartbeat, but, alas, it's 2013.
Sketched: 1. As neat as the clustering is, it's very opaque and hard to debug. And even after years of using Erlang, it's always a pain to set it up again, and opaque when it fails. This is a critical feature for the system I've written, and I just can't keep it stable. That others seem to have managed doesn't help me any, and I'm done pouring time down this sinkhole. 2. The syntax is quite klunky. I've been programming in Erlang for 6 years now, including for my job, and yes, I still don't like the syntax. In addition to ",.;", it's a terribly klunky functional language, wearing a lot of the trappings while failing to reap a lot of the benefits. And I don't just mean this is a minor inconvenience, it seriously inhibits me from wanting to create well-factored code, because it's so much work I can't factor away. (I have examples, but explaining them is a blog post, not a 6-th level nested HN post) 3. As neat as OTP is (and it is neat), it tends to encourage a highly coupled programming approach to fit into "gen_server" (or whatever), and due to problem #2, many of the tools I'd use to solve that from either the imperative side or the FP side are not present, or too hard to use. The whole gen_X encourages very choppy and hard-to-follow code. If you pour enough work into it, you can get around that, but the language doesn't help you enough. It's also bizarrely hard to test the resulting OTP code considering we started with a "functional language".
It's a brilliant language that was well ahead of its time, and I don't mean that merely as a "I want to be nice" parting comment; it is a brilliant language that was ahead of its time and every serious language designer should study it until they deeply understand it. Indeed, I will absolutely attribute a significant portion of my success in programming Go to the wisdom (no sarcasm) I learned from Erlang, and Go would be a better language today had the designers spent more time learning about it first. (It still wouldn't be an Erlang clone, but it would be a better language.) But it's just become increasingly clear that it has been a drag on my project, for a whole host of little reasons that add up. It was the right decision at the time, because virtually nothing else could do what it did when I started, but that's not true anymore.
Someone will be tempted to post a point-by-point rebuttal. My pre-rebuttal is, I've been programming in it for six years (so, for instance, if there's some "magic solution" to clustering that has somehow escaped my six years of Googling, well, I think I did my part), yes, I know all other languages will also have "little things" (and big things), and Erlang may be perfect for your project, absolutely no sarcasm.
Yes, I agree, and I'm sure I'm going to have many years of wishing they had. At the moment I don't have a better entrant in this field that is palatable to my coworkers, though. They've rather disliked Erlang (and not for lack of trying, and not for lack of good reasons, for that matter), Haskell's right out, and I'm running low on production-quality true isolation-based languages here. Several additional up-and-coming contenders; I'm sure if I could have used Rust-from-2018 I'd take that in a heartbeat, but, alas, it's 2013.
Go is tolerable, at least the way we're using it.