> In most async systems … you end up in a world where you chain a bunch of async functions together with no regard of back pressure.
yup. Back pressure doesn’t compose in the world of callbacks / async. It does compose if designed well in coroutine world (see: erlang).
> async/await is great but it encourages writing stuff that will behave catastrophically when overloaded.
yup. It’s very hard, in larger systems impossible, to do back pressure right with callbacks / async programming model.
This is how I assess software projects I look at. How fast is database is one thing. What does it do when I send it 2GiB of requests not reading responses? What happens when I open a bazillion connections to it? Will a previously established connections have priority over handling new connections?
yup. Back pressure doesn’t compose in the world of callbacks / async. It does compose if designed well in coroutine world (see: erlang).
> async/await is great but it encourages writing stuff that will behave catastrophically when overloaded.
yup. It’s very hard, in larger systems impossible, to do back pressure right with callbacks / async programming model.
This is how I assess software projects I look at. How fast is database is one thing. What does it do when I send it 2GiB of requests not reading responses? What happens when I open a bazillion connections to it? Will a previously established connections have priority over handling new connections?