Java and Rust by Yishai Galatzer
Вставка
- Опубліковано 12 жов 2022
- 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. - Наука та технологія
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.
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.
I think things will improve in java once Valhalla and Lilliput are completed. there wouldn't be that much of memory difference after that. Java is great for readability as well.
But still I think it will remain behind rust in terms of memory.
Isn't it the same with any new language? After writing this one you would be able to write othes much faster.
Languages aren't tools, they're mediums. With toki pona you may be able to comunicate, but details will be difficult. If you use lojban, you can say exactly what you want, no more and no less, and include as many or as few details as you want. Java is like toki pona, and Rust is like lojban.
Shouldn't you be comparing the value of your time against the value of your product consumers' time rather than hardware?
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.
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.
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).
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.
I knew it was William! 🤣
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.
A language is nothing without its ecosystem of packages etc. Comparing just the “languages” would be a rather academic exercise, arguably you could just compare syntax and that’d be comparing languages; that would completely ignore the compiler or interpreter etc. So it’s fair to say he’s comparing the languages; because there is no Java without the JVM and there’s no Rust without its packages etc etc
@@beatraad There may be no Java without the JVM, but there actually is Rust without its packages, just like there's C with no packages. You manipulate memory locations with numbers crafted through bit and arithmetic operations. Arduino works well even with no libraries, so language comparisons do matter.
If you let it warm up, JIT will convert often run bytecode to machine code, and in some instances will even outperform Rust because it knows what's going on at runtime.
@@justADeniIf you make a seperate allocation for every part of a single data structure, then you'll never get the cache to perform well no matter how much you JIT compile it. Java is just a terrible language. Also, JITs do the same thing that a compiler does, but with less information (executable byte code vs. static single assignment form), not more.
This extremely positive for Java and JVM. Rust requires 100x the effort to just save tens of megabytes of memory for the same performance.
Yeap. Modern Java JIT compilers are awesome. In many cases they are outperforming any given AOT compiler including those of C/C++ and Rust. V8 for JS is also a good example.
ok, tokio sucks. can you compare rustix::io::splice() vs java nio?