Comment by polishdude20

1 day ago

Wait, what's wrong with it? For all the stuff I've written in Typescript it's been great. And the event loop of JS performs very well as well.

> the event loop of JS performs very well as well

that's the very opposite of my experience! Or rather it does perform, in the sense that I don't think there's much margin for improvement, but the very concept of single-threaded server that switches context on IO is so flawed and painful.

    - Any vaguely CPU-intensive operation is a risk for latency to shoot up across every request.
    - You can never trust your monitoring: if I see that latency for an endpoint spiked, is it because something did happen to this endpoint OR an unrelated request hogged the CPU OR because the metric collection itself was CPU-starved
    - CPU profiling of a request is near-impossible because all requests are handling in a single thread
    - It doesn't play nicely _at all_ with k8s CPU resource management

I spent many hours looking at various dashboards, trying to guess whether what I was looking at was a cause or a symptom or just noise. Any hypothesis of what is going wrong needs to take into account the weirdness and side-effects of the event loop. As much as I love the Typescript language, operating Node is a nightmare.

  • I saw the same issues with my servers.

    I'm thinking about porting to Bun, as it's web server module is implemented in Zig.

    Could have the benefit of using TypeScript without the issues of Node.js' HTTP module.