Thoughts on Go vs. Rust vs. Zig

Post by dxxvi » Sat, Dec 06, 2025, 9:22 AM UTC

therein wrote: post #213

dxxvi wrote: post #210

Earlier quoted context omitted.

> It's exceedingly rare to see any sort of global mutable state I know a bit of Rust, so you don't need to explain in details. How to use a local cache or db connection pool in Rust (both of them, IMO, are the right use case of global mutable state)?

Why does that have to be global? You can still pass it around. If you don't want to clobber registers, you can still put it in a struct. I don't imagine you are trying to avoid the overhead of dereferencing a pointer.

Post by Yoric » Sat, Dec 06, 2025, 10:59 AM UTC

throwaway894345 wrote: post #466

Yoric wrote: post #28

Earlier quoted context omitted.

FWIW `fmt.Errorf("opening file %s: %w", filePath, err)` is pretty much equivalent to calling `err.with_context(|| format!("opening file {}", path))?` with anyhow. What `thiserror` or manually implementing `Error` buys you is the ability to actually do something about higher-level errors. In Rust design, not doing so in a public facing API is indeed considered bad practice. In Go, nobody seems to care about that, whic…

> In Go, nobody seems to care about that, which of course makes code easier to write, but catching errors quickly becomes stringly typed. In Go we just use errors.Is() or errors.As() to check for specific error values or types (respectively). It’s not stringly typed. > If you wish to make sure it's not a breaking change, mark your enum as `#[non_exhaustive]`. Not terribly elegant, but that's exactly what this is for.…

Post by Yoric » Sat, Dec 06, 2025, 2:15 PM UTC

dmoy wrote: post #396

Yoric wrote: post #28

Earlier quoted context omitted.

FWIW `fmt.Errorf("opening file %s: %w", filePath, err)` is pretty much equivalent to calling `err.with_context(|| format!("opening file {}", path))?` with anyhow. What `thiserror` or manually implementing `Error` buys you is the ability to actually do something about higher-level errors. In Rust design, not doing so in a public facing API is indeed considered bad practice. In Go, nobody seems to care about that, whic…

> In Rust design, not doing so in a public facing API is indeed considered bad practice. In Go, nobody seems to care about that, which of course makes code easier to write, but catching errors quickly becomes stringly typed. Yes, it's possible to do it correctly in Go, but it's ridiculously complicated, and I don't think I've ever seen any third-party library do it correctly. Yea this is exactly what I'm talking abou…

Post by oconnor663 » Sat, Dec 06, 2025, 5:39 PM UTC

throwawaymaths wrote: post #142

andsoitis wrote: post #139

Earlier quoted context omitted.

> so does the rust compiler check for race conditions between threads at compile time? My understanding is that Rust prevents data races, but not all race conditions. You can still get a logical race where operations interleave in unexpected ways. Rust can’t detect that, because it’s not a memory-safety issue. So you can still get deadlocks, starvation, lost wakeups, ordering bugs, etc., but Rust gives you: - No data…

and you can have good races too (where the order doesnt matter)

Post by vips7L » Sat, Dec 06, 2025, 6:16 PM UTC

gf000 wrote: post #562

vips7L wrote: post #556

Earlier quoted context omitted.

Nah man. They could make checked exceptions less boiler platey. Simple things like Swift’s try! Or try?, and making the try construct an expression would go a long way to increase checked error usage and therefore correctness. We don’t even need to solve the lambda problem. We just need to make it easy to deal with checked exceptions. Right now you have a minimum 5 lines of boiler plate to escape them.

Making it an expression would indeed by nice - I do like that in Kotlin, though it's still not particularly short there (but given that there are not really checked throws there, it's easy to just have a lambda for that). I believe there was a proposal to incorporate it into the switch expression? That may make it slightly too complex though, with null handling and pattern matching.

    A a;
    try {
      a = someThrowingFn();
    } catch (AException ex) {
      throw new IllegalStateException(ex); // not possible
    }

    var a = try! someThrowingFn();

    var a = switch (someThrowingFn()) {
        case A anA -> anA;
        case throws AException ex -> throw new IllegalStateException(ex);
    }