4 ms·
Does the author not know what a "leaky abstraction" is? The first time they referred to memory leaks I thought is a clever joke nested in a jab a hypothetical c
by sqeaky 2y ago
Does the author not know what a "leaky abstraction" is? The first time they referred to memory leaks I thought is a clever joke nested in a jab a hypothetical coder who didn't know, but then in the end they double down in a clearly non-joking way. Then even make a chart showing that calling a normal function from an async function is trivial, that is the opposite of a leaky abstraction.
An abstraction is a "leaky abstraction" when it forces some external condition or behavior onto code (ex: calling code that uses the network doesn't work when the network is disconnected). In this case the hurdles of calling async code from normal code, and this author tries to hand waive that with talk of dependencies.
There are real benefit and drawbacks to async code and styles. Even if I don't think it is a good abstraction I want to discuss it on the real engineering terms of its actual merits and drawbacks. This article is talking past the engineering decisions and seems like it didn't mean to.
maybe I am just being a pedantic jerk.
- lalaithion 2y agoWhat I think this comes down to, is that in Rust: It is easy but dangerous to call a non-async function from an async function (since the non-async function could block, forcing all your async code to block on this function). It is hard but safe to call an async function from a non-async function. Note that this is language specific; if Rust had “async”, “pure”, and “blocking” as three different function colors, then we would have a very different design. Or, for example, in JavaScript: It is easy and safe to call a non-async function from an async function, since JavaScript exposes no blocking primitives. It is impossible to call an async function from a non-async function, since there is no way to block on the result.