On the duality of operating system structures
blog.acolyer.org
blog.acolyer.org
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
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.
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.
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.
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.
*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.