3 ms·

> "Smart programmers try to avoid complexity. So, they see the extra complexity in async/await and question why it is needed. This question is especially pertin

> "Smart programmers try to avoid complexity. So, they see the extra complexity in async/await and question why it is needed. This question is especially pertinent when considering that a reasonable alternative exists in OS threads." Hm, yes, but is that complexity really avoided if it's in the language/runtime? Sure, it's not in your code and it will probably have way more extensive testing and maybe also people that thought about the problem for months and you're just trying to implement Business feature #31514 and not reinventing the wheel, but as someone who has been bitten by specific implementations like the one in Quarkus (not a language, granted), I must say: Complexity is there to stay (and occasionally bite you), even if it's hidden!

delusional 3y ago
I tend to agree, but an important note is that I've never seen an async/await system that didn't ALSO interact with OS threads. Async await is not an alternative to OS threads but rather an additional layer.
- OtomotO 3y ago
  I have heard about them in embedded systems where there are no OS threads, because there is no OS, but there is Async tasks and a scheduler
  - mike_hearn 3y ago
    That just means there's an OS but it's one a bit like Win 3.1, with fully cooperative multitasking.
- IshKebab 3y ago
  You mean like the async/await systems in the two most popular languages in the world - JavaScript and Python? Async/await is definitely an alternative to user space threads, especially for IO bound tasks.
  - WorldMaker 3y ago
    Some of the Python schedulers today already use pools of OS Threads. There's definitely complications involving the GIL that makes Python ugly in true multi-threading, but Python has done a lot to mitigate it in the last few years and the rumors are GIL removal will happen sooner than a lot of people expect.
grumpyprole 3y ago
> Hm, yes, but is that complexity really avoided if it's in the language/runtime? Complexity can be abstracted away and this is still a worthwhile goal. Otherwise, we'd all still be studying Intel CPU documentation.
- OtomotO 3y ago
  It can and it should, but I disagree with the sentiment that when it's abstracted "away" it's not there anymore. You just don't see it. Abstraction doesn't change any fact about how the system actually works.

delusional 3y ago

I tend to agree, but an important note is that I've never seen an async/await system that didn't ALSO interact with OS threads. Async await is not an alternative to OS threads but rather an additional layer.

OtomotO 3y ago
I have heard about them in embedded systems where there are no OS threads, because there is no OS, but there is Async tasks and a scheduler
- mike_hearn 3y ago
  That just means there's an OS but it's one a bit like Win 3.1, with fully cooperative multitasking.
IshKebab 3y ago
You mean like the async/await systems in the two most popular languages in the world - JavaScript and Python? Async/await is definitely an alternative to user space threads, especially for IO bound tasks.
- WorldMaker 3y ago
  Some of the Python schedulers today already use pools of OS Threads. There's definitely complications involving the GIL that makes Python ugly in true multi-threading, but Python has done a lot to mitigate it in the last few years and the rumors are GIL removal will happen sooner than a lot of people expect.

grumpyprole 3y ago

> Hm, yes, but is that complexity really avoided if it's in the language/runtime? Complexity can be abstracted away and this is still a worthwhile goal. Otherwise, we'd all still be studying Intel CPU documentation.

OtomotO 3y ago
It can and it should, but I disagree with the sentiment that when it's abstracted "away" it's not there anymore. You just don't see it. Abstraction doesn't change any fact about how the system actually works.