FWIW I really don't like async in rust. It's improved significantly over the past couple years and it's nowhere near as bad as callback hell in Javascript but things still feel opaque. I've been toying around with a little monitoring agent (think Nagios or Sensu) to keep an eye on my defective LG fridge. So far I've managed to crash rustc twice. Trying to wrap my head around one library (that I was using incorrectly) I managed to "fork bomb" the damn thing and realize that I've little to no insight into the runtime. Try to find the current number of running tasks being managed by tokio…
The beauty of the rust async stuff is that you can move to a multi-threaded runtime as you desire with minimal effort.
> Try to find the current number of running tasks being managed by tokio…
As a heavy user of async Rust in production (at a couple places), resource leaks / lack of visibility into that has been a top issue.
In this area, tokio-console[1] is an exciting development. I have high hopes for it and adjacent tools in the future. (Instrumenting your app with tracing+opentelemetry stuff can help a lot, too).
Until those become featureful/mainstream enough, Go has the upper hand in terms of "figuring out what's going on in an async program at any given time".
> The beauty of the rust async stuff is that you can move to a multi-threaded runtime as you desire with minimal effort.
This is also a downside, having multi-thread be the default and not single-thread. It introduces some awkward / accidental trait bounds that are annoying to deal with if you want to do thread-per-core type of stuff IIRC.
The beauty of the rust async stuff is that you can move to a multi-threaded runtime as you desire with minimal effort.