[Jtsummers]

At least on (2), that's actually one of the nice things about Erlang. It removes a lot of the kinds of things that make concurrency difficult for people. There are no locks on data. There is no shared data. The model is based on message passing with actors. This means that bad designs that don't fit this model make themselves apparent (they introduce complex bookkeeping overhead or are cripplingly slow due to coordination overhead), but good designs (data flow, a process per connection, processes as isolation mechanism for state) become easy in this language and perform very well.

And since processes are so key to Erlang, the green thread mechanism that BEAM provides is very fast and message passing is about the same overhead as a function call (which is to say, not much). This model of concurrency should be teachable to any 3rd year CS major in college (and possibly earlier) without breaking their brains.

[mybrid]

If one is doing async programming my experience with Promises in JavaScript is that glossing it over only works to the degree the async mostly behaves like synchronous. To quote Albert Einstein, make something as simple as possible, but no simpler. If one is writing programs for asynchronous applications abstracting them away as if the asynchronous behavior environment doesn't exist is problematic.

Most developers I work with day-to-day are not designers. Fred Silverman's "The Mythical Man Month" from 1972 has a good take on this. The way I see it, languages like Erlang are amber that locks in dead code because no one except the original author can maintain it. Once code goes into maintenance mode good luck finding Erlang maintainers.

[macintux]

Erlang effectively makes everything asynchronous, so you're forced to deal with it. It's not glossed over at all, although it does give you good primitives to cope with it.