4 ms·

> async-style programming usually coincides with first-class functions and closures, and those are painful in Rust. Are they, though? The example the author g

> async-style programming usually coincides with first-class functions and closures, and those are painful in Rust. Are they, though? The example the author gives in the article tries to write a multithreaded program as if it is a singlethreaded one. Of course that is going to be painful, whether you're trying to use futures/promises or you're using callbacks. If you want to use multiple threads safely (i.e. at all) you need to use the right structures for the job - smart pointers, mutexes, etc. This is independent of language really, even dynamically typed languages like Ruby still have mutexes for when you want to use multiple threads (though they do take control away from the programmer in the form of things like global interpreter locks). If you don't actually want to deal with the complexities of multithreading, then don't use it. For example there are a good number of languages/runtimes that only expose a single-threaded event loop to the programmer (even though they may use thread pools in the background). But I don't think "ergonomic" should necessarily mean "abstract away every single detail" or "things should Just Work even though one is straight-up not approaching the problem correctly".

throwaway17_17 6y ago
It is my understanding that the entire point of the async/await sugar in any language is to explicitly take away the appearance of multithreading/concurrency/parallelism in code. I often see the argument for async/await syntax as being made in the following way, it is not natural or feasible to reason about concurrent and multithreaded code, programmers need to be able to reason about all code as though it were a linear list of instructions no matter what is going on with the implementation, therefore, we need the async/await syntax to enable linear, straight line code appearance for programmer benefit. While I do not agree that doing so is at all a good thing, it is the most prevelant argument I have seen in justifying async/await style sugar. If I am right and this is the primary motivation for adding this to a language, your comment is in direct opposition to the entire point of such constructs. Using this reasoning, I think the author was doing as suggested and writing multithreaded code as though it was just a non threaded imperative program. Note: I don’t really disagree with your view, but it seems that view is in the minority.

throwaway17_17 6y ago

It is my understanding that the entire point of the async/await sugar in any language is to explicitly take away the appearance of multithreading/concurrency/parallelism in code. I often see the argument for async/await syntax as being made in the following way, it is not natural or feasible to reason about concurrent and multithreaded code, programmers need to be able to reason about all code as though it were a linear list of instructions no matter what is going on with the implementation, therefore, we need the async/await syntax to enable linear, straight line code appearance for programmer benefit. While I do not agree that doing so is at all a good thing, it is the most prevelant argument I have seen in justifying async/await style sugar. If I am right and this is the primary motivation for adding this to a language, your comment is in direct opposition to the entire point of such constructs. Using this reasoning, I think the author was doing as suggested and writing multithreaded code as though it was just a non threaded imperative program. Note: I don’t really disagree with your view, but it seems that view is in the minority.