Migrating from Go to Rust

Post by rixed » Mon, May 25, 2026, 3:26 AM UTC

throwaway894345 wrote: post #109

ViewTrick1002 wrote: post #34

Earlier quoted context omitted.

They all convert seamlessly, and the enums make the branches explicit. Don't even need to check the documentation to find which errors supposedly exists like in Go with its errors.Is, errors.As, wrapping and what not. An easy rule before you make a knowledge based choice is Thiserror for libraries, helping you create the standard library error types and Anyhow for applications, easy strings you bubble up. Or just go…

I’ve repeatedly tried using Rust and the error handling has tripped me up every time and has been ~90% of the reason for moving a project back to another language. I’m sure I’m just holding it wrong, but what I run into usually goes something like this (mind you, I have read the Rust book): * Someone tells me to use enums for errors, in a comment like yours * I try writing the enums by hand, implementing the error tr…

Post by dnautics » Mon, May 25, 2026, 3:32 AM UTC

sheept wrote: post #156

dnautics wrote: post #136

Earlier quoted context omitted.

So, suppose it's a rust library -- you're locking me into whatever logging system the library author chooses? Maybe I'd like to consume the relevant data at the entry point and send it to a logging system of my choice.

A Rust library likely wouldn't be returning an opaque Box to begin with. Errors are part of a library's API—it's what allows consumers to handle them—so you'd define an enum of possible errors your library could produce and return that, which would be stored on the stack.

Post by mook » Mon, May 25, 2026, 3:44 AM UTC

boccko wrote: post #87

mikeocool wrote: post #65

Earlier quoted context omitted.

I was a big fan of go for a while. Though now that I have programmed more swift and rust recently, having a compiler that doesn’t protect against null pointer deferences or provide concurrency safety guarantees feels a little prehistoric. Though go certainly did a much better job than rust on the standard library front.

Standard library is something you have to maintain for all eternity, with identical API. It had been argued that some concurrency primitives like channels would have been better outside of std (for rust, to be clear). Once dependency management is solved, a small std is beneficial.

Post by yuriks » Mon, May 25, 2026, 3:54 AM UTC

dnautics wrote: post #163

sheept wrote: post #156

Earlier quoted context omitted.

A Rust library likely wouldn't be returning an opaque Box to begin with. Errors are part of a library's API—it's what allows consumers to handle them—so you'd define an enum of possible errors your library could produce and return that, which would be stored on the stack.

What about the data in the error payload?

  enum AllocError {
    SizeTooLarge { size: usize },
    // etc.
  }

Post by gitaarik » Mon, May 25, 2026, 3:57 AM UTC

corndoge wrote: post #52

awesome_dude wrote: post #33

Earlier quoted context omitted.

Package management is the bane of nearly every language/technology Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?) For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine) There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseud…

Nix solved it. Languages could choose to adopt Nix as their packaging system.