I continually find this particular point useful and enlightening. (Joel's whole corpus of stuff is worth a read. At the risk of causing a hacker news "joel stor

I continually find this particular point useful and enlightening. (Joel's whole corpus of stuff is worth a read. At the risk of causing a hacker news "joel storm" of submissions, check out the pricing/segmentation piece: http://www.joelonsoftware.com/articles/CamelsandRubberDuckies.html http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...) For example, after discussing the subject of promises (in the sense of the tool to manage and abstract asynchronous program flow) with a colleague, it occurred to me that the reason we care about async behaviour is that a "function call" is a leaky abstraction, in that it takes a variable amount of time. We think of a function call as "doing X, Y and Z". The fact that it takes time to do it, blocking our 'thread of execution' causes us the problem that we can solve with the overhead of async programming (or threading, or...) (By 'function call' I'm glossing over system call, library call, embedded cpu-eating loop.) From this perspective, you can see that an alternative to working around the leak is plugging (some of) the leaks - which is the approach golang takes, by shuffling around threads of execution to avoid them being stalled by blocking system calls. That perspective is useful to me and helps me understand why I think I prefer the golang approach, "more robust abstraction".