Java and Rust by Yishai Galatzer

Java is an established language, with advanced VMs, robust package libraries, mature frameworks, dynamic and reflective capabilities, a large tooling selection, and a sizeable developer ecosystem. Rust is a younger systems programming language that can have small memory footprint, low CPU utilization, offer low latencies and have small application sizes.

But how do these characteristics pan out in the real world?
How easy is it to take advantage of them?
Is one language “better” than the other?
Are they really so different?

In this talk we will take a journey with the two languages and we will review our experience in designing and building a sample application with the same requirements in both Rust and Java. We will compare the development experiences and how they each perform. We’ll share our thoughts and conclusions on where Rust and Java could be improved. And we’ll talk about how we see each being used in the future.

YISHAI GALATZER
Yishai Galatzer is a Director of Software Engineering at Amazon Web Services. Yishai's teams contribute to the Rust language and the JVM.

The JDK team is focused on the development of OpenJDK and the distribution of the Amazon Corretto project. The team focuses on contributing to the Long Term Supported releases of OpenJDK, as well as new investments in JIT Compilation, aarch64, The Shenandoah Garbage Collection project, and observability.

The Rust team works on the Rust language, the Rust compiler, Tokio (async Rust runtime), and supporting Rust at Amazon.

[sarge]

Very interesting. Another reminder that 'performance' is not the be-all-and-end-all, or rather it *can* be important, but not as important as making the code work right in the first place. All languages / tools / frameworks have their place, comparisons are often pointless if you're asking the wrong question.

[ybergik]

Another argument for choosing the right tool for the job. Writing my first microservice in Rust right now and the motivation is a need for memory efficiency (will be keeping a few million objects in memory serving as a cache) and predictable response times (no more GC pauses, which can get very long with that many objects) serving 50-100K requests/sec. If not for that, I wouldn't have bothered. That it's something new to learn, is both a bonus and a headache at times. It will take a lot of effort to become sufficiently productive in Rust that it can compete in development time if you are already proficient in C# or Java and ultimately that counts much more in 99% of the stuff we write because our time is much, much more valuable/expensive than hardware.

[felixa]

I am not too surprised that these languages ended up with the same performance for this challenge. Every language probably has a way to represent a bag of bytes and needs to optimize buffer copies. I would expect many implementations to be limited on some combination of the hardware and the syscalls. If we wanted to see a real performance difference, we would need to target mathematical computations or something that would stress allocations or cache lines. Then you could see how much the object overhead of Java compares against Rust's memory model.

[tintifax]

The dependencies comments around 30:30 struck a chord with me. One of my frustrations with Rust is how you need to find an external library for a lot of rather small, basic things - which leads to the usual agony of finding the right one. Is it well-tested, is it mature, is it under active development, is it "the library" that people are using nowadays or a remnant of the dark past of the language ecosystem that's still maintained but not used in new projects? This becomes even more important if you're writing a library yourself, i.e. you don't want to introduce transitive dependencies that people wouldn't want to pull in. I kind of like the batteries-included aspect of languages like Java (or Python, for that matter), despite its downsides.

I guess an alternative to a fat standard library could be something like a de-facto-standard library. Like the tidyverse in R or what Apache Commons and Guava did for Java (at least for some time).

[cheari]

One thing that's not mentioned at all is the developer experience of using the language itself. Sure, Rust has a higher learning curve, but there is a big pay off from that. You get a much more advanced type system, elimination of data races, fearless concurrency etc.

[jaysistar]

You're comparing libraries that wrap the OS I/O system calls, not languages. Rust outperforms Java in memory usage in all cases. It would also outperform Java in making system calls, which can be done without assistance from native C or Rust code in Rust. Yes, in Java, you can reduce heap allocation, but in Rust, you can allocate a block on the stack or the heap (it doesn't matter), and put an allocator on that block, and then use it as your allocator for your collection types. No garbage collector means more flexibilty, and no fighting with "stop the world" performance problems. Value types for aggregates instead of mandated reference types means that you can optimize your cacheline fills. That's not even an option in Java without completly throwing idomatic Java out the window to the point where it's painful to get anything done; you'd have to use arrays of primatives for all of your state, which Rust can do idiomatically, but Java can't put a class in (on top of) a array of primatives, but Rust can. I will say that library comparison is absoultly a valid and needed comparison, and, as you point out, these things can be fixed and optimized when brought to light, so, again, as you said, always measure.

[rochaaraujo]

I did few tests about file read and write, comparing Java and Rust. Guess what? Java was faster in a lot of cases, but of course, use a lot more memory than Rust.

[jaysistar]

With WASM, Rust has all of the advantages of the JVM, plus it has the ability to discard it for even more performance, not as an afterthought like AOT Java, but both having 1st class support.

[rolandinnamorato]

This extremely positive for Java and JVM. Rust requires 100x the effort to just save tens of megabytes of memory for the same performance.

[luckystrike]

ok, tokio sucks. can you compare rustix::io::splice() vs java nio?