If you can encode your request processing patterns in statically sized types, then you can get the same high-level memory allocation behavior on both platforms. Arguably Rust makes this a bit easier. (Though I have no idea how much of the concepts of mechanical sympathy made it to mainstream Java.)
replyIf you have some kind of super vague complicated patchwork of plugins that all contribute to processing, then the JVM seems to be the more convenient choice.
https://martinfowler.com/articles/mechanical-sympathy-princi...
Indirect evidence, but parts of AWS and cloudflare have been running Rust in production for close to a decade now and neither company looks to be itching to move services back to Java.
reply> other network services better than the JVM with its hot spot?
replyJVM hotspot optimization is just band-aid for something Rust does always everywhere naturally? Assuming that you use lifetimes etc properly and not going to Arc rampage.
Rust:
reply concat/string time: [77.801 ns 78.103 ns 78.430 ns]
change: [+0.0275% +0.3169% +0.6169%] (p = 0.03 < 0.05)
Change within noise threshold.
formatted/string time: [31.471 ns 31.569 ns 31.699 ns]
change: [+0.1277% +0.3915% +0.6788%] (p = 0.01 < 0.05).
Change within noise threshold.
Benchmarks.concat string avgt 15 8.632 ± 0.105 ns/op
Benchmarks.format string avgt 15 64.971 ± 1.406 ns/op
I would be careful with this benchmark even thought it shows JIT efficiency. This is a special case which might not really reflect realworld - string was static? What if you use random string?
replydeleted
reply