Complicated things are not inherently terrible ideas: your CPU is complex, but you have compilers to abstract you from it. Likewise the ways your multi-core machine shares memory is complicated, and the JMM partly abstracts it, but really you're meant to use much higher level constructs. The JMM matters to people writing lock libraries and compilers, not ordinary users.
It's a common logical fallacy that you can simplify a complex solution by simply redefining the problem it solves as not a problem. The "Erlang model" you discuss is in fact the model the entire computing world used before threads were invented and there were only processes. But threads weren't invented for shits and giggles, they were invented for good reasons!
> But threads weren't invented for shits and giggles, they were invented for good reasons!
I remain unconvinced ;-) It always seemed to me, that if threads were such a great idea, operating systems should expose threads, and not processes. In a way NT and Linux took different paths here - on Windows processes are expensive, on Linux threads and processes are pretty much the same in terms of overhead (but threads obviously allow sharing memory, for better or worse).
I've long suspected that if threads really could "be done right", they would've been preferred to processes. But just like people worked really hard to get hardware protected memory to be fast enough to be usable, I think working hard to get processes to be "fast enough" is more viable than "getting threads right". Amusingly, I suppose Erlang is actually an example of how mixing the two ideas can be a great idea: Don't let programmers know their "process" is a scheduled thread, force messaging over shared memory - and reap the benefit of light weight processes and strong(-ish) protection between threads...
I seem to remember first seeing threads used to run Novell and OS/2 on the 80286. (they must of been invented long before that, but that was my initial "OMG!" exposure to them)
But threads aren't just complicated, they are dangerous. E.g. - if somebody forgets and updates something in an instance variable in a Java servlet, rather than local variables, hilarity/calamity ensues.
By the time you are using thread pools, vs "spawn at will", how much better off are you than using a pool of processes safely separated by explicit interprocess communication?
It's a common logical fallacy that you can simplify a complex solution by simply redefining the problem it solves as not a problem. The "Erlang model" you discuss is in fact the model the entire computing world used before threads were invented and there were only processes. But threads weren't invented for shits and giggles, they were invented for good reasons!