Java GC is -- in my experience -- every bit of the nightmare of node.js, if not more so. Even for those for whom this is their domain of expertise, "GC tuning" boils down to superstition, voodoo and witchcraft -- which are euphemisms for simply changing the GC algorithm until things seem to improve. These changes (in my experience) often move the problem around without solving it, and when deep in a nightmare Cassandra tuning exercise, one exasperated domain expert said to me: "Why would one ever write a database in a garbage collected language?!"

I think the question was profound (if accidentally so), and I agree with him: when performance and footprint matter, it is reasonable to expect software engineers to manage their resources in a predictable manner -- which excludes garbage collected environments.

Rust is a very interesting candidate for such environments, and I think the experience described here is quite helpful for those of us seriously contemplating the language.

> "GC tuning" boils down to superstition, voodoo and witchcraft -- which are euphemisms for simply changing the GC algorithm until things seem to improve

Then, that is what "tuning" usually means in engineering. See also "PID loop tuning".

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.

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.

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.

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?

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.