Hacker News Reader

Language maturity is not a one-dimensional problem and it's also not equal to the age of the language.

To name just two ways in which I consider Rust more mature than Java:

* It has a lot of fundamentals that are based on more academic languages which have explored some specific PLT space for a long time and let it mature. The fruits of that are now in Rust (many aspects of its type system for example).

* Rust's community has an almost absurd ability (contrasted with most other languages) to focus on specific core libraries and tooling. For example serde[1], the Rust serialization library, is well-understood, simple, mature and supported in basically every Rust library out there.

The second point is extremely impressive when contrasted with the state of things in Java-land, where you often have many different solutions for the same problems. Sometimes even the well-known and used ones are of very questionable quality[2].

[1]: https://serde.rs/ [2]: https://github.com/FasterXML/jackson-databind/pull/1423

Jackson's status as the de facto Java standard for reading and writing JSON really reflects poorly on the Java community. Too often the biggest, hairiest solutions get anointed as the safe "best practices" choice for all new development when really they should only be used if you know specific reasons why they will pull their weight relative to simpler solutions. Jackson is an 800lb gorilla with an impressive arsenal of features, but there's no way in hell it should be the default choice for a simple greenfield CRUD application.

Without turning this into a long tangent subthread.. could you point to some support for this? The comparisons I've seen are more nuanced.[1]

[1] https://blog.takipi.com/the-ultimate-json-library-json-simpl...

That's a performance comparison that ignores all other aspects such as simplicity, readability, and ease of maintenance. It also shows Jackson coming in last for parsing small files.

The type system has no relationship to language maturity. It's just a different type system with different trade-offs.

Your second point is invalidated by the blog itself: "Many libraries are still early".

One thing that we've been hearing for a while is that even if you can tune a GC, it still takes up significantly more memory than the equivalent Rust program. GCs can be memory hungry. Sometimes, you care a lot about RSS. It just depends.

GC still brings its own set of problems like Finalizers and the like.

GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear.

> GCs also tend to have cliffs where you hit some unknown threshold when they start thrashing where deterministic release of memory tends to be much more linear.

I've experienced this, having previously worked on Java services.

It can be quite a pain and can throw a wrench into your understanding of how you intended to scale.

Rust might immature, but it's rock solid. I don't think lack of maturity of the core language is a reason not to use it in production anymore. Lack of available libraries may be an issue, but if it's not then Rust seems like a pretty goos choice to me.

>Reading between the lines here, they didn't go with a more mature language like Java because they were worried GC tuning would be a problem?

The post says GC was already a problem in their old system.

Their old Nodejs system. Java GC tuning is more robust and well understood. So I'm wondering if it was truly a case of "Java GC is going to be a nightmare, let's take on a very early stage language with lots of unknown risks instead." Or if perhaps there's some champing at the bit to adopt a hot new language for its own sake.

FWIW, I'm excited for Rust and also Swift for exactly these reasons. I just want to see hard justifications for using them in production this early.

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.

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".

Lot of companies pick x.y.z because it's fancy not because it's the best solution. ofc Java would have been a great solution here.

Java still has GC overhead and higher resource consumption in general, when compared to rust or C++