4 ms·

Completely disagree. Async as a paradigm has probably created billions of dollars in that it's allowed many many many developers to reasonably scale beyond wha

Completely disagree. Async as a paradigm has probably created billions of dollars in that it's allowed many many many developers to reasonably scale beyond what they could've otherwise.

anakaine 2y ago
Agree wholesale. I've got a complex data reader built on a single server that receives tens of thousands of requests a day, and most tend to happen in a few hour window. Async was super important to scale to user requests by allowing non-blocking calls to not get captured behind blocking ones.
- tommiegannert 2y ago
  I think GP is arguing that green threads e.g. in Go is a better way to structure the same thing.
  - worik 2y ago
    No. I had a nasty experience with Typescript's async/await and I am annoyed I find async/await very confusing. It as one thing pretending to be another I prefer my paradigms simple and straight Async await is deceptively simple but very wiggly. Not straight at all. Loads of magic fairy dust obscuring what's really happening It is helpful until it isn't and then it's very unhelpful
prerok 2y ago
And I disagree with your disagreement :) Just some background first: one of the billion dollar mistakes is the null pointer which is a special value to be assigned to any type. It was inherent in the first high (today considered low) level languages. Those languages (C most importantly, then Java and nowadays even Go) enabled many more programmers to create programs and they likely would not have been able to, had they been forced to write assembly. So, it's a billion dollar mistake within a trillion dollar revenue. The async now solves a similar practical problem but in the space of prallelism (or concurrency, in some cases). A different approach might have given us the same result, but a different implementation that might be just as approachable. Optionals and Results have given us a better way than to have nulls, and maybe golang style channels could have given us a better way to handle async?

Completely disagree. Async as a paradigm has probably created billions of dollars in that it's allowed many many many developers to reasonably scale beyond what they could've otherwise.

anakaine 2y ago

Agree wholesale. I've got a complex data reader built on a single server that receives tens of thousands of requests a day, and most tend to happen in a few hour window. Async was super important to scale to user requests by allowing non-blocking calls to not get captured behind blocking ones.

tommiegannert 2y ago
I think GP is arguing that green threads e.g. in Go is a better way to structure the same thing.
- worik 2y ago
  No. I had a nasty experience with Typescript's async/await and I am annoyed I find async/await very confusing. It as one thing pretending to be another I prefer my paradigms simple and straight Async await is deceptively simple but very wiggly. Not straight at all. Loads of magic fairy dust obscuring what's really happening It is helpful until it isn't and then it's very unhelpful

prerok 2y ago

And I disagree with your disagreement :) Just some background first: one of the billion dollar mistakes is the null pointer which is a special value to be assigned to any type. It was inherent in the first high (today considered low) level languages. Those languages (C most importantly, then Java and nowadays even Go) enabled many more programmers to create programs and they likely would not have been able to, had they been forced to write assembly. So, it's a billion dollar mistake within a trillion dollar revenue. The async now solves a similar practical problem but in the space of prallelism (or concurrency, in some cases). A different approach might have given us the same result, but a different implementation that might be just as approachable. Optionals and Results have given us a better way than to have nulls, and maybe golang style channels could have given us a better way to handle async?