The best ideas are always worth defending.Brendan wrote:it's just sometimes I feel like I'm defending rather than explaining
Hmmm... When I was talking about benefits for developers, I meant giving them the ability to leverage the hardware more efficiently. IMO, convenience is a separate issue, and libraries can help here. They can't take away the concept that something asynchronous is going on, but they can make it convenient to do things asynchronously (e.g. -- "futures" could easily use your non-blocking messaging under the hood).It probably has more to do with the main benefits being for users rather than developers. For example, the asynchronous messaging makes things harder for developers, not easier, because it forces them to minimize thread blocking rather than providing them with the possibility of being lazy and using something like "fopen()" without thinking about it. Of course things like libraries don't help with this - sometimes it seems that as long as it works no-one cares how it works.
Those programmers stuck in a single-threaded world will be in for a nasty shock now that everything is going multi-core. I hope they all read this eventually...Don't get me wrong here - there are a lot of very good programmers who actually would use something like thread pools and "futures" support, but there are also plenty of programmers who've never written anything that uses more than one single threaded process. For your profession, I'd expect that your colleagues would be the former rather than the latter, but I wouldn't consider your colleagues to be a good statistical sample.
