2 ms·

I find the focus on Rust vs Java a bit weird. Yes Rust is faster than Java, I sure hope it is. But the interesting thing is that Rust is better at optimizing th

by Zababa 5y ago

I find the focus on Rust vs Java a bit weird. Yes Rust is faster than Java, I sure hope it is. But the interesting thing is that Rust is better at optimizing the overhead of Option. > The most ugly and error-prone solution turned out to be the fastest: primitive types and magic values. That's often the case in "older" languages. ES6 iterators on arrays are usually twice as slow as a simple "for" loop. Which usually means that by targetting ES5 or lower, you get a free optimization by Babel/tsc!

tialaramex 5y ago
This is a failure of optimisation though. In the NonZeroU64 case Rust can literally do the same trick with magic values ... in the machine code, the magic value is zero, a NonZeroU64 can't be zero and so Rust will squeeze None into that value of the register. The programmer and their colleagues both reading and writing the code don't need to understand how this trick works, don't need to be aware of magic values, and if some day the code needs a full u64 and a NonZeroU64 isn't good enough, they just change it and sure, it might be a little slower because the optimisation wasn't available, but it still works as expected because magic values were just an optimisation not part of the program logic.
- Zababa 5y ago
  It is, but Java has been having trouble optimizing things like that since forever. Project Valhalla is still in development. Pointer chasing and boxing is the reality of Java today.
pornel 5y ago
Both languages are used in high-performance servers (where you know Ruby or Python won’t cut it). HotSpot has a reputation of being close to a Sufficiently Smart Compiler, so it’s interesting to see where its limits are, compared to lower-level language constructs.
- Zababa 5y ago
  My mental model would be, from lowest to highest peformance, something like Ruby/Python < JavaScript < Java/C# < Go < C++/Rust. From what I understand, Java is a huge improvement over Python, Ruby and even JS, but is still not the same as Rust, C++ or even Go. Still, those are rough indicators, and not absolute truth. Yon can usually go really far before being stopped by the absolute strict limit of a language. For example, here's a post about Discord switching from Go to Rust with great success https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to..., and here's another about how CockroachDB optimizes Go https://www.cockroachlabs.com/blog/how-to-optimize-garbage-collection-in-go/ https://www.cockroachlabs.com/blog/how-to-optimize-garbage-c.... In the same vein, there's Shopify AOTing Ruby using Sorbet and LLVM https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-compiler https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp.... All of that to say that I'm not surprised that Rust has better defaults compared to Java, as Rust is supposed to be faster, and option types are a code Rust language feature, while they are a relatively recent addition to Java.
- pjmlp 5y ago
  With the small difference that Rust lacks 25 years of libraries for every kind of enterprise use case, battle tested in production. Beating Java with optional values is nice, but meaningless.

by Zababa 5y ago

tialaramex 5y ago

This is a failure of optimisation though. In the NonZeroU64 case Rust can literally do the same trick with magic values ... in the machine code, the magic value is zero, a NonZeroU64 can't be zero and so Rust will squeeze None into that value of the register. The programmer and their colleagues both reading and writing the code don't need to understand how this trick works, don't need to be aware of magic values, and if some day the code needs a full u64 and a NonZeroU64 isn't good enough, they just change it and sure, it might be a little slower because the optimisation wasn't available, but it still works as expected because magic values were just an optimisation not part of the program logic.

Zababa 5y ago
It is, but Java has been having trouble optimizing things like that since forever. Project Valhalla is still in development. Pointer chasing and boxing is the reality of Java today.

pornel 5y ago

Both languages are used in high-performance servers (where you know Ruby or Python won’t cut it). HotSpot has a reputation of being close to a Sufficiently Smart Compiler, so it’s interesting to see where its limits are, compared to lower-level language constructs.

Zababa 5y ago
My mental model would be, from lowest to highest peformance, something like Ruby/Python < JavaScript < Java/C# < Go < C++/Rust. From what I understand, Java is a huge improvement over Python, Ruby and even JS, but is still not the same as Rust, C++ or even Go. Still, those are rough indicators, and not absolute truth. Yon can usually go really far before being stopped by the absolute strict limit of a language. For example, here's a post about Discord switching from Go to Rust with great success https://discord.com/blog/why-discord-is-switching-from-go-to-rust https://discord.com/blog/why-discord-is-switching-from-go-to..., and here's another about how CockroachDB optimizes Go https://www.cockroachlabs.com/blog/how-to-optimize-garbage-collection-in-go/ https://www.cockroachlabs.com/blog/how-to-optimize-garbage-c.... In the same vein, there's Shopify AOTing Ruby using Sorbet and LLVM https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-compiler https://sorbet.org/blog/2021/07/30/open-sourcing-sorbet-comp.... All of that to say that I'm not surprised that Rust has better defaults compared to Java, as Rust is supposed to be faster, and option types are a code Rust language feature, while they are a relatively recent addition to Java.
pjmlp 5y ago
With the small difference that Rust lacks 25 years of libraries for every kind of enterprise use case, battle tested in production. Beating Java with optional values is nice, but meaningless.