3 ms·
> Yes, when you replace the words async/await with meaningless concepts I do not care about such as color My issue is that in some contexts the cost of the fun
by enragedcacti 2y ago
> Yes, when you replace the words async/await with meaningless concepts I do not care about such as color
My issue is that in some contexts the cost of the function is effectively meaningless. A lot of python scripting falls into this category, where performance is not a concern or there is nothing useful to accomplish in the process while waiting for I/O. At that point any async up the stack is just forcing the user to deal with implementation details they shouldn't need to care about.
I can appreciate that it enforces good design decisions in some contexts, but marking that up as a pro feels like tasking the interpreter with doing the job of a linter.
- pxeger1 2y agoAnother key thing is that in many languages, you can (and will often enough in practice for it to be a concern) do I/O outside of an async function, using the equivalent blocking API. So in those languages, async does not act as a useful “this function is expensive/impure” marker.
- colejohnson66 2y agoThat's because many languages start without async/await. So, sync overloads stay for eternity for backwards compatibility. If I could design a language from scratch, I'd argue for async/await OOTB. For example, the Microsoft Midori team did "async everything" in their C# derivative.[0] [0]: https://joeduffyblog.com/2015/11/19/asynchronous-everything/ https://joeduffyblog.com/2015/11/19/asynchronous-everything/