a "something 3 levels deep in your dependency tree is not Send error when trying to do something like tokio::spawn for <reasons>
tokio is quite bloaty, but also consider hiding sync behind async such as postgres (which started as pure sync crate) now just doing a block_on behind the scenes and forcing tokio on people that don’t even want async
combining IO wait tasks with CPU busy-wait tasks can be quite tricky. tokio::task::spawn_blocking works but you are forced to do it at the lowest granularity level
closures vs async vs async closures, nuff said
async traits vs sync traits
sync vs async code duplication
I could go on. Just like some commenters on the HN thread, I think removing async and forcing nice library abstractions on top of epoll/kqueue/io_uring would be a better way to go about this.
I’ve been there when C10k became a thing, I coded a Free Pascal networking non-blocking library lNet and added epoll and kqueue support to free pascal for that purpose. I understand non-blocking and IO wait issues, and I think async is wrong.
async is broken. Some basic examples:
Send
error when trying to do something liketokio::spawn
for <reasons>tokio
is quite bloaty, but also consider hiding sync behind async such aspostgres
(which started as pure sync crate) now just doing ablock_on
behind the scenes and forcing tokio on people that don’t even want asynctokio::task::spawn_blocking
works but you are forced to do it at the lowest granularity levelI could go on. Just like some commenters on the HN thread, I think removing async and forcing nice library abstractions on top of epoll/kqueue/io_uring would be a better way to go about this.
I’ve been there when C10k became a thing, I coded a Free Pascal networking non-blocking library lNet and added
epoll
andkqueue
support to free pascal for that purpose. I understand non-blocking and IO wait issues, and I think async is wrong.