While they may be duals formally, they still have significant differences in how individuals are able to model them mentally.

I've felt the appeal for the message passing style for a while, but always disliked the additional bulk/rigidity of frameworks for it. Recently though, I've been thinking about a concept for program organization based on 'domains' and 'converters,' that's (in part) an extremely minimal message passing system in Java. There's a little essay on my github for the project: https://github.com/westoncb/Domain-slash-Converter

If most developers knew both sides of the coin, then most projects would choose which approach was a better fit for their situation.

But what happens is, developers work for years only knowing one way, thinking it is the only way. They start to notice problems/friction/"code smells", and they follow the resulting thought process till they eventually discover the other way.

At this point, they might mistakenly think the newly discovered way better in all cases. They might also mistakenly think it is their invention.

Learning theory really is a powerful shortcut.

Why not both?

Locking (spinlocks, mutexes and conditions) is a building block for higher level concurrency primitives just as "goto" is a necessary building block for higher level control flow patterns.

You need locking to implement message passing anyway. Although message passing can be done in lock free manner (using atomics) if busy waiting is good enough, but that is not suitable for all (most?) cases.

I see this philosophical argument against locking often used as an excuse for not learning how to use mutexes and conditions properly. It might not be practical for all higher level tasks you need to do but there's no excuse not to learn how it works (and that needs practice, intuition is almost useless here). For low level concurrency work, you need to know how to use locking correctly.

Study the history and the theory because otherwise you are running around like a chicken with its head cut off. We need more articles like this.

Regarding duality - obligatory meijer reference - this time on async and observables. main point: any one design could very well be isomorphic to a whole range of options in the design space - https://www.youtube.com/watch?v=pOl4E8x3fmw&feature=youtu.be...

Also regarding duality - just because there is a proof of duality between designs it does not follow that they design the same thing at all.

Classic example from CT: In sets (well, the category of sets and maps but still...), the cartesian product is dual to the disjoint union (sum type, variant record etc.) From this, anything proven about cartesian products (which is a lot, as it is fundamental to most of set-theory) proves something about the disjoint union through the duality. What it actually proves about disjouint unions is open to interpretation on a proof by proof basis.

Which is to say: The consequences of duality are rich and powerful, but they are often non-obvious and for systems with many moving parts almost certainly non-trivial.

Good point

Note that this article is the first in a 5 part mini-series, the other articles are well worth reading too.

I like to think that the conclusion is that Haskell is the most perfect language for concurrent programming, but maybe that's my rose coloured glasses.

I think you may have over-indexed on the context that is most appropriate for your use-case.

*edit - The core point IMHO: You have to build on your system's primatives. If it can afford haskell, great (And in many cases we associate with general programming, this may be true) - but I don't think we should say it's the case catagorically.

Another comment in this article prompted a lookup of the difference bewteen message passing and event architectures.. http://programmers.stackexchange.com/questions/146586/merits...

i was wondering if the 'style' of current mostly NUMA type server-hardware platforms, favor one approach over another. for example, when no more GHz improvements etc. are possible it seems that message-passing _may_ tend towards a better utilization of available resources than locking (which might cause hundreds of wasted cycles all over the place)