3 ms·

OT but this... > I strongly believe that async is the new billion dollar mistake of the 2020's: a design aberration that wasted so much developers time that it

by worik 2y ago

OT but this... > I strongly believe that async is the new billion dollar mistake of the 2020's: a design aberration that wasted so much developers time that it had cost billions of dollars to companies. Yes. Nicely put

mbStavola 2y ago
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?
amw-zero 2y ago
What does this even mean, how can you do any form of modern computation without async?
- MrDarcy 2y ago
  async / await as they exist in JavaScript, Python, and Rust aren’t the only way to execute tasks concurrently.
  - amw-zero 2y ago
    That’s what I’m asking - did the comment mean that the async/await pattern is bad, or that asynchronous programming in general is bad?
    - worik 2y ago
      asynchronous programming is the bee's knees, and my preferred mode Asyc/await pretends to be synchronous and gets all tied in horrible knots when the sunk costs mount Writing IO without blocking has always been second nature to me
  - eureka-belief 2y ago
    But they are a darn convenient mental model if you’re just trying to do some basic async. The alternatives are harder to wrap your head around. Unless I’m missing some other cool pattern.
    - worik 2y ago
      > Unless I’m missing some other cool pattern. Explicit state machines
aixpert 2y ago
Wait they promised to not adopt the cancerous function coloring approach in wasm. Please tell me they didn't follow the dark path of JS
- leucippe 2y ago
  The plan is to support async without function colouring. I recommend this talk by Luke Wagner on async plans in WASI 0.3 (https://youtu.be/y3x4-nQeXxc https://youtu.be/y3x4-nQeXxc) for background on how it will work. To summarise, from an API perspective, the caller and callee won't know if the other is async or not. When calling async from non-async, an event loop is inserted at link-time and it blocks.* When calling non-async from async, the callee will get suspended if it tries to do blocking IO. That still leaves the problem of long-running compute without IO in a non-async context, but at least you're not wasting CPU time in that scenario. * If the host runtime already has an event loop, I assume the callee will get added to that.

by worik 2y ago

mbStavola 2y ago

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?

amw-zero 2y ago

What does this even mean, how can you do any form of modern computation without async?

MrDarcy 2y ago
async / await as they exist in JavaScript, Python, and Rust aren’t the only way to execute tasks concurrently.
- amw-zero 2y ago
  That’s what I’m asking - did the comment mean that the async/await pattern is bad, or that asynchronous programming in general is bad?
  - worik 2y ago
    asynchronous programming is the bee's knees, and my preferred mode Asyc/await pretends to be synchronous and gets all tied in horrible knots when the sunk costs mount Writing IO without blocking has always been second nature to me
- eureka-belief 2y ago
  But they are a darn convenient mental model if you’re just trying to do some basic async. The alternatives are harder to wrap your head around. Unless I’m missing some other cool pattern.
  - worik 2y ago
    > Unless I’m missing some other cool pattern. Explicit state machines

aixpert 2y ago

Wait they promised to not adopt the cancerous function coloring approach in wasm. Please tell me they didn't follow the dark path of JS

leucippe 2y ago
The plan is to support async without function colouring. I recommend this talk by Luke Wagner on async plans in WASI 0.3 (https://youtu.be/y3x4-nQeXxc https://youtu.be/y3x4-nQeXxc) for background on how it will work. To summarise, from an API perspective, the caller and callee won't know if the other is async or not. When calling async from non-async, an event loop is inserted at link-time and it blocks.* When calling non-async from async, the callee will get suspended if it tries to do blocking IO. That still leaves the problem of long-running compute without IO in a non-async context, but at least you're not wasting CPU time in that scenario. * If the host runtime already has an event loop, I assume the callee will get added to that.