Comment by unscaled | Hacker News Reader

Comment by unscaled | Hacker News Reader

Parent Full thread

While Java can outperform Go in some cases, the situation is very much the opposite when it comes to Rust.

I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (within the same edition) or Go (within the same major version) break less than that.

As far as runtime compatibility goes, Rust and Go apps ship with the runtime. This can be better or worse for you, depending on what is your upgrade story, but I don't see a clear winner here. What I would give to Java over Rust is that you will have far fewer dependencies to take care of if you need to upgrade. But the same goes for Go.

For observability, I feel that with Rust you have a bit less that you need to observe (no GC to worry about). Tokio tracing is great, but observability requires a bit more effort. The go observability story is far worse. So Java probably has an edge here, but not something that ever felt like a game changer. My impression is that for most of the enterprise shops that love Java, observability means collecting unstructured log files through NFS and trying to find a needle in the haystack with primitive tools, but I've been out of touch with this world for a couple of years.

Productivity is something that is dead if you are AI-heavy. Sure, many shops are still wary about AI, and I totally get why, but this is a battle that's already been lost. Without AI, I would say I was about 3 to 4 times more productive in Rust than I was in Java, but ramping up that productivity took at least 1 year of practice. It's not time most companies are willing to spend. With AI, this doesn't matter anymore, for better or worse.

I'm not arguing that Java is not chosen often for greenfield projects. It's clearly extremely popular in many circles, especially outside startups and big tech. But I think the reason Java is chosen have little to do with the reasons you've mentioned above and more with organizational preferences.

> I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (within the same edition) or Go (within the same major version) break less than that.

Java also breaks very few things. Breaking binary compatibility is a no-go since it's a core promise of the platform. The only thing in the surface language that has ever been changed is the meaning of the underscore as an identifier, as well as the behavior of == in upcoming Project Valhalla.

> As far as runtime compatibility goes, Rust and Go apps ship with the runtime.

Java applications can also be shipped together with the runtime.

> Productivity is something that is dead if you are AI-heavy.

Nevertheless, making constructs available to express intent more clearly should also help LLMs to not go off the rails.

> the situation is very much the opposite when it comes to Rust.

It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant. This is for pretty fundamental constraints of low-level language that I mention in another comment here, and this performance problem with large programs written in low-level languages was well known before Java even existed. The JVM was designed, at least in part, to address it.

One of the things that drew me to Java (from years of C++, even though I still work in C++ when I work on the JVM) is precisely how it addresses those performance issues we ran into with C++ five years into a project.

> As far as runtime compatibility goes, Rust and Go apps ship with the runtime. This can be better or worse for you, depending on what is your upgrade story, but I don't see a clear winner here.

I wasn't talking about "runtime compatibility" but of overall version compatibility. Java has an unmatched compatibility record - not perfect, but better than anything else (with at least a medium-sized standard library).

> For observability, I feel that with Rust you have a bit less that you need to observe (no GC to worry about).

Memory management is very often a bigger issue without a GC than with a moving GC. Time and again we see Rust or C++ programs spend 30-50% on memory management.

> Productivity is something that is dead if you are AI-heavy.

Really? Have you had AI write a good medium-sized (say 100-500 KLOC) program or maintain one over a long period of time without very close reviews? The only people I've seen who don't know about the ticking time-bomb agents leave in the codebase are the people who don't look.

> With AI, this doesn't matter anymore, for better or worse.

You may be talking about small programs. I agree that for small programs, low-level languages can offer excellent performance, and AI can be okayish, and you can get some observability you can live with, but I'm talking about large programs.

> But I think the reason Java is chosen have little to do with the reasons you've mentioned above and more with organizational preferences.

Those organisational preferences are due to a long record of delivering on the things I mentioned. Java has an exceptionally low "regret factor", i.e. people who regret choosing it five, ten, or fifteen years into a project (which is when the problems usually start).

> They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant.

Generally, efficient memory management is orthogonal to object oriented design. Meaning, as your complexity grows and your business logic changes, it often means the optimal memory management changes because the lifecycle and relationship between objects change.

For a web server for instance, you have both request/response as well as various transactional memory requirements. In Java, the role of the garbage collector is to adapt to whatever the best memory policy is based on runtime behavior, rather than statically defined rules. One could say that the evolutionary and revolutionary changes in garbage collectors as well as the multitude of tuning parameters comes from this being a really hard task.

If you have a services architecture, the runtime advantages of Java go down significantly.

> I wasn't talking about "runtime compatibility" but of overall version compatibility. Java has an unmatched compatibility record.

I would say both matter significantly more again in a monolithic architecture. It matters a lot more when you are trying to deploy your software into a single application server, or trying to avoid version incompatibilities when integrating large amounts of code into a single executable.

> Time and again we see Rust or C++ programs spend 30-50% on memory management.

I've seen plenty of Java applications spend 30 seconds or longer because they had to do a full garbage collection back in the day. I even had one customer who maxed out Java to utilize all the memory in their server and hit a 13 minute production pause due to otherwise unoptimized GC (promoting many temporary transactional objects to the mature generation until it eventually exhausted memory).

The different strategies for memory management (static vs dynamic) ultimately still require recognizing, diagnosing and correcting issues. GC provides unique challenges because the tuning mechanism is decoupled from the actual code. GC challenges can also often go undiagnosed until staging/production workloads hit them, precisely because they are dynamic behaviors.

> I've seen plenty of Java applications spend 30 seconds or longer because they had to do a full garbage collection back in the day

Java's current GCs are quite different from the earlier revisions. ZGC for instance guarantees < 1ms pause times even for TB heaps as far as I'm aware.

> Time and again we see Rust or C++ programs spend 30-50% on memory management.

30-50% of what?

Oh, sorry, missed a few words. Their CPU time.

Gotcha, that bit makes more sense now. That's quite the statistic!

I’m curious where you have seen this.

It's quite common in concurrent services that non-experts write. But the more interesting cases are things like Moka. In a simple evaluation (and, of course, not much can be extrapolated from any benchmark) Java's old Caffeine library had lower latencies in all percentiles at twice the throughput as Moka (at 90% cache hit rate), as the latter spent 41% of CPU (on top of the cost of malloc/free) on epoch based reclamation.

> and, of course, not much can be extrapolated from any benchmark

Right, so one case (which I certainly believe is possible) is very different from “time and time again.”

By time and time again I meant concurrent services that are written by people who are not experts at low-level programming. The irony is that they don't see "CPU spent on memory management" as they do in Java not because there's less of it - quite often it's much, much more - but because it's simply not measured and reported.

As for the caching test, it's just technically interesting, because the JVM was designed to address the performance issues we suffered from in large C++ programs (all the JVM engineers are, of course, C++ people), both due to compilation and to memory management, and we regularly compare both our compilation and memory management algorithms to other approaches, and it just so happens that last week one of our GC engineers compared Caffeine to Moka and saw how CPU-intensive the memory management work is compared to ZGC (he was particularly interested in this because caching is one of the more challenging workloads for generational moving GCs because a cache deals with many old objects, whereas generational GCs tend to focus more on young objects, and he wanted to make sure that our GCs help reduce the high memory-management overheads associated with low-level languages even in this challenging scenario).

Reply on news.ycombinator.com