Migrating from Go to Rust

Post by rowanG077 » Mon, May 25, 2026, 7:59 PM UTC

bottlepalm wrote: post #235

solumunus wrote: post #221

Earlier quoted context omitted.

The benefit is if you lean heavily on types then successful compilation is a massive indicator in the feedback loop. Using stop hooks to ensure successful compilation after every iteration is a game changer. Go also has compilation of course but because the type system is so much more robust in Rust the compilation guarantees so much more about the behaviour of your program. You end up just code reviewing the shape a…

Code compiling is really the lowest bar of code validation, and doesn't say much of anything of the code running correctly. AI will pump out the most convoluted, over engineered, and at the same time sloppy code if you let it - and it will all compile fine.

Post by za3faran » Mon, May 25, 2026, 8:06 PM UTC

nicce wrote: post #385

za3faran wrote: post #359

Earlier quoted context omitted.

Rust: concat/string time: [77.801 ns 78.103 ns 78.430 ns] change: [+0.0275% +0.3169% +0.6169%] (p = 0.03 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.

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?

    @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

    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

Post by Hendrikto » Mon, May 25, 2026, 8:09 PM UTC

kubb wrote: post #247

tptacek wrote: post #74

This is a weird document that is simultaneously trying to serve as a migration guide and an advocacy document for Rust. Ultimately, if you have to ask , the Rust vs. Go consideration boils down almost completely to "do you want a managed runtime or not". A generation of Rust programmers has convinced itself that "managed runtime" is bad, that not having one is an important feature. But that's obviously false: there a…

It feels like you’re upset because your favorite language has objective flaws that people are pointing out. You’re also trying to minimize people’s lived experiences and pleading with them to stop pointing the flaws out. Sure, Go is better than Python in some things. But developers deserve the best. We deserve not to have to deal with Go’s quirks, idiosyncrasies and design mistakes.

Post by LtWorf » Mon, May 25, 2026, 8:19 PM UTC

awesome_dude wrote: post #455

LtWorf wrote: post #255

Earlier quoted context omitted.

Same as in go, a language designed several decades later.

Funny - you said Go was worse - now you're saying Go's the same...

Post by afdbcreid » Mon, May 25, 2026, 8:30 PM UTC

cdud3 wrote: post #283

Certhas wrote: post #214

Earlier quoted context omitted.

It's the same logic for human and for AI code: In Rust the compiler catches many bugs so you don't have to. If the LLM gives you safe code you know there are entire classes of things you don't have to review for. That said, I agree with you. My experience is that LLMs are great if you are highly competent in the domain in which you let them work. And it's probably easier to be competent in Go than in Rust.

I found it's the opposite. Thanks to LLM's whole classes of problems otherwise solved by using Rust are gone. It's now more important that the generated code is easy to read.