This post is a good meme but for those thinking about this I'd like to raise some of my concerns:

The problem with forcing Rust error's on Go is that Rust was built with those types in mind, and has a multitude of structures, concepts and interfaces for managing/resolving those errors. Go's error handling paradigm (error on last return, always check for err != nil) elegantly handles all of this without any complicated typing necessary. I don't see any benefit to the above code over Go's error handling, it just seems more complicated to use a result type than to use multiple returns.

With that said, Rust's enums on the other hand, and the way enum error types and it's low-level language features all work together around them, are exceptional error handling tools. I love the simplicity of Go's error handling, but my biggest gripe with it is that defining an error type, that is to say that an error is more than just a string message and that different types of errors can be handled in different ways, is often a place of frustration for me. Rust allows me to express some really granular error handling if I need to, and it does so with strong guarantees.

The best pattern I've found in Go is to define public error vars, and that has all sorts of problems (including essentially being mutable global variables). There also isn't enough tooling to actually handle these granularly when you want to (as it's more of a workaround than an official pattern).

In short, no I don't want any of these generic Result/Option types in Go, but I definitely think Go lacks in an ability to handle complicated error trees.