Hacker News new | ask | show | jobs
by p2detar 23 days ago
> as amazing or fast as Rust

For cli tools, game engines, etc. certainly so. But what about monoliths? Do we have enough data to say Rust handles long-running monolith apps exposing web and other network services better than the JVM with its hot spot? I haven’t come to any stats on that matter, yet.

3 comments

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.)

If 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.
> other network services better than the JVM with its hot spot?

JVM 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:

    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.
Java

    Benchmarks.concat      string  avgt   15   8.632 ± 0.105  ns/op
    Benchmarks.format      string  avgt   15  64.971 ± 1.406  ns/op
Java's string concat is faster than rust's offerings.
Java is probably able to bump allocate memory or something similar, where rust is using a general purpose allocator.

I guess if you are formatting strings constantly this is important, but you can also use a bump allocator in rust if you really wanted to.

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?
It is not a static string, the `param` argument gets passed in each time. I modified the above benchmark to add an int parameter in addition to the `param` argument from before. However now it's testing an itoa as well as it is dependent on the number of iterations the benchmark suite decides to run, so it is not as precise, but Java is still ahead.

Java:

    @Param({"string"})
    public String param;

    public int i = 0;

    @Benchmark
    public String concat() {
         return "prefix " + param + " " + i++ + " suffix";
     }

    Benchmark          (param)  Mode  Cnt   Score   Error  Units
    Benchmarks.concat   string  avgt   15  26.591 ± 0.242  ns/op
Rust:

    fn format2(state: &mut BenchState) -> String {
        let i = state.next_i();

        format!("prefix {} {} suffix", state.param, i)
    }


    format2                 time:   [51.923 ns 52.541 ns 53.466 ns]
    Found 10 outliers among 100 measurements (10.00%)
    4 (4.00%) high mild
    6 (6.00%) high severe