The asynchronous APIs that have emerged for Rust to date are too convoluted. I have squinted at several examples as this work has evolved and found myself mystified to some extent. With more effort I know I could at least utilize them competently, if not fully grasp the details.
Several widely used languages have invented or adopted straightforward and easily understood mechanisms for asynchronous programming; solutions that do not mystify or involve extraordinary effort. This reality sets an expectation and from what I've seen Rust Futures and Tokio don't deliver a competitive answer.
Also, I believe the protracted development of these APIs is a symptom of a problem. The blog post suggests that Rust is not suited to asynchronous programming ("a language that isn’t really designed for it.") I bet there is some truth to that and that the long struggle these APIs have had is a consequence of this. There may have to be some language level accommodation.
There is some fundamental thing wrong here and the problem needs a rethink. This cannot be the way.
1 comment
[ 2.7 ms ] story [ 10.7 ms ] threadSeveral widely used languages have invented or adopted straightforward and easily understood mechanisms for asynchronous programming; solutions that do not mystify or involve extraordinary effort. This reality sets an expectation and from what I've seen Rust Futures and Tokio don't deliver a competitive answer.
Also, I believe the protracted development of these APIs is a symptom of a problem. The blog post suggests that Rust is not suited to asynchronous programming ("a language that isn’t really designed for it.") I bet there is some truth to that and that the long struggle these APIs have had is a consequence of this. There may have to be some language level accommodation.
There is some fundamental thing wrong here and the problem needs a rethink. This cannot be the way.