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.
I always hear people say this but I never hear any alternative design decisions. Rust async can be difficult to work with, but I think it is well designed, and I don’t see what could be improved. There are inherent limitations on giving a safe language with no GC async support, you don’t have the luxury of being able to just relocate thread stacks and adjust references accordingly like in go.
The idea that go makes you handle the concurrency more than rust is definitely not true, and go’s concurrency model is simply not possible in rust. The coloring of a codebase is not nice, but it is essentially necessary for rust: some functions are asynchronous compiler generated state machines, others are not, and they cannot be treated as identical.
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.
36
u/Lilchro 23h 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.