[seangrogg]

Problem: We're running into an issue with the garbage collector which, given the nature of the task, is not actually adding any value.

Potential solution 1: Replace with code that doesn't have garbage collector overhead in the first place

Potential solution 2: Replace with code that has different, robust garbage collector

I get where you're coming from, but even I would be inclined to choose solution 1 in this case. That they chose Rust instead of C++ is their own business, but that they chose either of those over Java just seems sensible to me.

[abalone]

That's not really a fair summary. The issue is that less mature language have lots of other issues that come along with the good. Just in this article they noted immature libraries, difficulties with async that kept them from migrating fully off of node.js, and difficulties with error handling. So you have to weigh those in the comparison, not just focus on the one major benefit.

[seangrogg]

They were able to resolve a performance-critical issue that was problematic to a critical part of their application by basically writing a script rather than needing to refactor their code base.

They can benefit further by choosing something more performance-oriented than Node.js, sure. But they weren't having issues with their whole application failing - just a specific piece. When you want to expand your driveway your first thought shouldn't be what materials you want to build your new house in.

[w4tson]

Interesting, I got the impression that the problem was being restricted to a single thread. “being single-threaded, couldn’t process operations in parallel”.

Wonder what the article would have said in a parallel universe where the problem was migrated to something like the Akka framework on the JVM?

[seangrogg]

I'd imagine that if they had switched from Node.js to Akka they likely would've solved some of their issues dealing with single-threading - while I like Node.js I think the point where performance matters more than feature iteration it should be refactored into something that suits your domain better.

That being said, they mention being turned on to low resource usage specifically because of garbage collection issues and resource overhead. While the JVM is lighter than the Node.js runtime when considered across multiple cores I think that's just going to give them more runway to tackle the underlying problem they were still having.