> What's the benefit of the result type here Only to be consistent with the more general case: func tryToGetSomething() Result<Something> {...} Or perhap

> What's the benefit of the result type here Only to be consistent with the more general case: func tryToGetSomething() Result<Something> {...} Or perhaps you mean why not: func CopyFile() Result<error> {...} Yeah, sure. I don't care. I'm just tired of typing and wading through if (err != nil) { return err } all day long. Go has generics, so why not magic the e r r o r into place and save the species a few billion keystrokes? > I honestly also don't see how retrofitting it wouldn't be trivial. I'm not the first to propose this. Others have and the naysayers are legion, citing one corner case after another. I argue that the corner cases aren't worth solving, perfect being the enemy of good. The complier is free to bail on whatever outlier gymnastics someone might try. > One could probably even write a preprocessor for that. I (and many others) abhor the concept of a precompiler/macrowhatever for Go (although some have resorted to them for reasons.) Go is supposed to be a fast and self contained; embiggening the tool chain with more stuff is the opposite of the intent of Go. > it will lead to less explicit error messages f := os.Open(savegamepath) ?("Couldn't load savegame: %s", err) f := os.Open(savegamepath) ?{decorateAndReturnError(err) {...}} Or similar perhaps. Error handling is common. It's worth bending the rules a bit for a gain in concision. A little pragmatism would go a long way here.