"I have never had a long-running node application that hasn't leaked memory. It's more a matter of if your application will be OOM killed in 2 days or 2 weeks. Debugging memory leaks in node is a nightmare"
I stopped reading after this. I'm all for using Elixir for high concurrency workloads, but this sounds like a skill issue.
https://github.com/vercel/next.js/pull/75877
memory leaks in the runtime and frameworks all the time.
This setTimeout leak crashed our prod machine multiple times until we rolled back.
I'm not sure how a memory leak in Next.js, a massive project with a "move fast and break things" attitude, reflects on Node.js.
My experience with Node.js (on the backend) and Next.js (since Next.js 10) has been pretty solid, albeit being conservative, only just migrated to Next.js 15, still on pages router.
I'm not saying Node.js is the best thing since sliced bread. Memory leaks in event driven, long-running processes are a thing. I think it might be more about finding a language/runtime that clicks with your mental model. I'm interested to see how Elixir pans out for you in the long run.
Thats one of my primary issue with the Node community.
When I wrote Go for a few months I was blown away by how many projects I came across that hadn't had a commit to their repo in 3-4 years but people were still recommending them, the author just marked their project as 'feature complete' and all they planned on doing was bugfixes. It was a breath of fresh air.
Churn is built so deeply into the JS ecosystem that things breaking on the way is inevitable.
It's partially my fault for liking to be on recent versions of things, but even on a LTS release of node they released a [build where utf+8 strings were broken](https://github.com/nodejs/node/issues/54543) and our builds were failing silently.
I stopped reading after this. I'm all for using Elixir for high concurrency workloads, but this sounds like a skill issue.
reply