With the exception of POE and similar event-driven processing, all of the concurrency mechanisms you cite use threads. That is, multiple, concurrent, in-process, paths of execution. They may be 'user threads' (aka. cooperative scheduling), or 'kernel threads' (aka. preemptive scheduling), or some hybrid that uses an in-process scheduler to distribute the kernel-scheduled time-slices allocated to the process, to the threads within the process.

I guess I didn't get that impression on my first visit to your article... please accept my apology.

I also agree that, in general, FP constructs and robust type-systems will not make it the mainstream (as long as comp-sci is treated as voodoo rather than a branch of mathematics. :)

C# and Perl6 are however getting *some* form of type-inference... in my view, a step in the right direction.

We could probably "bolt-on" a lot of the concurrency paradigms (emulating them with threads and locks), but I think that most users will stumble because of reliability problems created through lack of type-guarantees.

I honestly don't believe there will be a "reliable, safe, high-level abstraction" for concurrency until we have at least type-annotations (visible or not) for side -effecting code that can be picked up in type-inference.