3 ms·
That is a very positive article and it matches my experience, the only bleak outlook is: "async has a relatively high complexity cost for us due to the 'static
by weinzierl 1y ago
That is a very positive article and it matches my experience, the only bleak outlook is:
"async has a relatively high complexity cost for us due to the 'static bound (cc), cancellation-safety, and restrictions relating to traits and dyn. These currently seem insoluble. Bifurcation between sync and async primitives and ecosystem idiosyncrasies further increase the async tax. Effects-inspired solutions seem unpromising."
"Pre-1.0 Rust had a solution: libgreen. It achieved concurrency in user-space without this bifurcation, but at significant performance, portability and maintenance cost and so was removed. With increased engineering bandwidth this may be worth revisiting. Again the language simplicity would be worth it. (One day I’ll create a PoC of zero-cost wrapping of std::{fs, net} plus fiber::{spawn, select} using generator!)"
- davidhyde 1y ago> “async has a relatively high complexity cost for us due to the 'static bound (cc)” I stand to be corrected but I believe that this is design choice of the Tokio async runtime and not a Rust design choice. For example, the Embassy async runtime does not have this bound but then you have to handle pinning yourself. Also, the static bound is supposed to lower the complexity cost, not raise it.