3 ms·

It depends on what you mean with „best result“. Async functions in Rust are not about improving ergonomics compared to classical threading. They are strictly wo

It depends on what you mean with „best result“. Async functions in Rust are not about improving ergonomics compared to classical threading. They are strictly worse. They are a tool which can be used to lower the amount of OS threads used by a n application- by multiplexing multiple logical tasks in one thread. Callbacks and state machines are other options for that - but those are even harder to get right. If your application requires that from an efficiency point of view async programming might be a good option. If not threads are fine.

necovek 5y ago
Sure, the definition of the "best result" is the question. In short, "the best approach" to me is one that: 1. Is suitable for all sorts of concurrency 2. Has a low memory overhead and low switching costs like the async functions today 3. Is the most "ergonomic" (leading to fewest bugs, easiest debugging and easiest maintenance): yeah, this one is not too well defined either, which is why I would measure developer satisfaction and things like defect rates to establish which one is it, not that this makes it any easier to define :) 4. Provides "enough" safety and encapsulation without impacting performance (much) If 4 has a huge cost, perhaps go with special-cased "async isolated" concurrency primitives when you need added safety in addition to "async", and if the cost is low, allow not paying it anyway with the inverse ("async unsafe"): basically, different defaults depending on what's realistically achievable and nature of the language. I think that ideal lies somewhere near the "non-cooperative multitasking" async programming approach, but I am not sure, and I haven't played with enough recent developments in programming languages either to know if any one of them gets close. But having thought through it a bit with this comment, I think my main gripe is how your (developer's) decision of the concurrency tool (threads, async/await, callbacks, green threads...) affects your syntax simultaneously (eg. why should awaiting a compute-intensive task be problematic? that's an implementation detail a developer should not have to worry about if all else is equal).

necovek 5y ago

Sure, the definition of the "best result" is the question. In short, "the best approach" to me is one that: 1. Is suitable for all sorts of concurrency 2. Has a low memory overhead and low switching costs like the async functions today 3. Is the most "ergonomic" (leading to fewest bugs, easiest debugging and easiest maintenance): yeah, this one is not too well defined either, which is why I would measure developer satisfaction and things like defect rates to establish which one is it, not that this makes it any easier to define :) 4. Provides "enough" safety and encapsulation without impacting performance (much) If 4 has a huge cost, perhaps go with special-cased "async isolated" concurrency primitives when you need added safety in addition to "async", and if the cost is low, allow not paying it anyway with the inverse ("async unsafe"): basically, different defaults depending on what's realistically achievable and nature of the language. I think that ideal lies somewhere near the "non-cooperative multitasking" async programming approach, but I am not sure, and I haven't played with enough recent developments in programming languages either to know if any one of them gets close. But having thought through it a bit with this comment, I think my main gripe is how your (developer's) decision of the concurrency tool (threads, async/await, callbacks, green threads...) affects your syntax simultaneously (eg. why should awaiting a compute-intensive task be problematic? that's an implementation detail a developer should not have to worry about if all else is equal).