| I'll take a language with ugly syntax but beautiful semantics over one with ugly semantics any day. Sadly the erlang semantics aren't all beautiful either, at least for the things that most people would use it for today. This quote that I picked up on the erlang mailing list was an eye-opener to me (from memory): Erlang wasn't designed to make easy things easy.
It was designed to make hard things possible.
This explains a lot about the erlang mindset. Things like the obscure syntax or the abhorrent string handling are simply not very high on their priority list.For example, strings weren't used much in the telecom projects that erlang was original conceived for - hence they didn't get much love until recently. Similarly the syntax seemed like a good fit for the problems that erlang was looking to solve, because it makes the expression of very complex, concurrent constructs comparably sane. The problem for us "normals" is that in our codebases we very rarely need that kind of expressive power (and the associated learning curve). We tend to need it in 2-3 critical spots, the remaining 99% is best solved by a general-purpose language that allows for quick iteration. Introducing the behemoth of erlang to a project only for these 2-3 spots very rarely passes a cost/benefit analysis. That's why we hack shoddy, slow and fragile bandaids in our go-to languages, instead of using erlang. |
* Except for the bit syntax, but that's more for binary data.