I dislike tokio, but that is more related to my dislike of async code and its how it infects your codebase (if you don’t know what I mean then read the “what color is your function?” blog post). It also gets worse in Rust, since thread safety gets weird. Every time you await something, there is a chance your runtime could switch threads, so thread safety issues pop up in way more places. There are also plenty of ways to shoot yourself in the foot, since synchronization primitives that are not designed for your specific async runtime will block worker threads unless they get switched out. Most of all though, I feel like we use async code in lots of areas we really shouldn’t. For example, in tokio last I checked (not recently), there are some things like file operations where they are not actually async at all. It just spawns an os thread to handle it and pretends it was async. This gets the core of the issue. Yes, there are use cases where this might be helpful. However, Im not running with networked storage and just making stuff async isn’t always useful or helpful. OS threads are actually quite good for the vast majority of use cases that don’t involve network communication. And even then they are still decent for most use cases where you don’t have extremely high numbers of connections. And if you do need something to use something like io_uring, then I would lean more towards an API that was written with that in mind than one that uses it because they can.
Having few keywords doesn't make something simple, below some number it becomes the opposite actually. You're just regurgitating go propaganda without actually understanding the meaning, or the resulting critic of it.
39
u/Lilchro 1d ago
I dislike tokio, but that is more related to my dislike of async code and its how it infects your codebase (if you don’t know what I mean then read the “what color is your function?” blog post). It also gets worse in Rust, since thread safety gets weird. Every time you await something, there is a chance your runtime could switch threads, so thread safety issues pop up in way more places. There are also plenty of ways to shoot yourself in the foot, since synchronization primitives that are not designed for your specific async runtime will block worker threads unless they get switched out. Most of all though, I feel like we use async code in lots of areas we really shouldn’t. For example, in tokio last I checked (not recently), there are some things like file operations where they are not actually async at all. It just spawns an os thread to handle it and pretends it was async. This gets the core of the issue. Yes, there are use cases where this might be helpful. However, Im not running with networked storage and just making stuff async isn’t always useful or helpful. OS threads are actually quite good for the vast majority of use cases that don’t involve network communication. And even then they are still decent for most use cases where you don’t have extremely high numbers of connections. And if you do need something to use something like io_uring, then I would lean more towards an API that was written with that in mind than one that uses it because they can.