I'm not the strongest Go programmer, so maybe my inexperience leads me to still disagree with the ergonomics of "if err != nil" over something like a formal `Re

I'm not the strongest Go programmer, so maybe my inexperience leads me to still disagree with the ergonomics of "if err != nil" over something like a formal `Result`/`Either` type à la Rust/Haskell/..., but this is a decent bog post. I think using a more structured capital-R Result type, combined with match/case makes for better structured code, and I can't help but think that `err != nil` is a bit of a smell left over from Go's initial decision to avoid doing generics (all of which is alluded to in the writeup). I do disagree with the author using a trivial example to demonstrate that `err != nil` isn't that bad, since most code you'll work with isn't trivial. the errnil pattern obviously isn't enough of a problem to deter many companies, which I've always been interested in, since to me it always seemed like a brittle and awkward error handling mechanism. All that aside, `blog.verygoodsoftwarenotvirus.ru` is an excellent domain name.