[originally posted 4/26/2017]
I’m completely convinced that blocking primitives are the devil. And if there was any doubt I’m totally convinced that normal everyday engineers can work in a world with no blocking primitives just fine.
When I worked on Midori about 6 years ago we struggled with the notion that everything was asynchronous. Initially, using c#, the notation was very cumbersome because you had to stick a delegate every damn place. This was improved somewhat by the simplified delegate syntax in later versions of C# but it was still crazy how many nested delegates you could end up making.
To make this better we came up with this wonky await syntax. I’m not sure if it has historical origins before Midori but that’s where I first saw it. We started working on that compiler to add needed primitives and we called it M#. The cool thing is that most of that work found it’s way back into C#, maybe somewhat altered. Someone like Joe Duffy could tell you more accurately.
Still, with all of this with struggled with the notion that nobody was ever gonna understand this stuff. It was too damn hard to figure it all out. “Normal” programmers aren’t gonna want to deal with it.
How wrong we were.
The best thing about working in this environment is that with no blocking primitives much of the most stupid stuff just can’t happen. Nobody can ruin your life simply by calling GetMessage because that blocks and there are no blocking methods. You can’t write code in that style at all. And it’s so good for web servers and for UIs.
More performance problems have been created by the ability of code to do crazy stuff (like read the damn disk) synchronously in a callback that has NO BUSINESS doing anything like that.
The other great thing about this setup is that it’s totally obvious which methods might do I/O or some such. They are all marked async. SO HELPFUL.
The Win32 API is just a total #headdesk on this score. Long live continuations and no blocking. I wish they had spent more time teaching us this stuff in school.