[kmeisthax]

To be clear, this is (mainly) about the enshittification of WASI, not WASM. If you're writing code to run in a web browser you will never interact with WASI. It is unfortunate to see WASI fall victim to the software componentry / IDL meme, but I doubt we're going to see that be an issue in browser WASM.

The part that actually pertains to WASM - async/await - exists because everything in a browser lives in Someone Else's Single Threaded Event Loop. Writing code that lives in an event loop is pure pain, and async/await exists solely to fix this problem. The billion dollar mistake is not adding async/await to programming languages, it's single-threaded event loops. Anyone talking about C10K or non-blocking I/O in regards to async/await is probably missing the point, because aside from one stubbornly single-threaded programming language[0] you can launch threads to handle reading or writing data and sockets.

[0] JavaScript. It's always JavaScript.

If you were thinking Python, you're wrong. Even with the GIL, Python supports threads, and concurrent I/O is one of the few reasons why they're useful.

[pjmlp]

You definitely will, because this is the approach that is also being taken by runtimes like Dart, Kotlin among others.

[worik]

> Writing code that lives in an event loop is pure pain,

Do you think?

I find explicit event loops pleasurable.

Does that make me a freak?

[coxley]

They're pleasurable when you're the only author. They become a minefield unless every contributor is diligent, which happens very often.

[curioussavage]

Yup. Somebody is going to write something that hogs cpu without yielding to the loop or queues up an absurd number of tasks waiting to be executed which effectively has a similar effect. All of a sudden latencies are high. Depending on how tracing is done it can appear like certain io operations are the culprit if you just go off of traces.

P99 latency for every route on your web server will be fixed at the max time any individual unit takes to execute before yielding plus loop overhead and its own time. This can drastically increase it for many routes.

Meanwhile some genius insists that our app is “io bound” so the single threaded async runtime must be a perfect fit.

Apart from just being generally faster at least with go I know that when somebody screws up there should be n other threads still executing tasks.