I tend to feel, just error handling in general. Its not even something I'd care so much about, if it didn't seem like everyone else felt like the way Go does er

I tend to feel, just error handling in general. Its not even something I'd care so much about, if it didn't seem like everyone else felt like the way Go does errors is great. You can't/shouldn't do custom error types, even though its an enticing sexy interface, because of things related to the massive nil/nil mistake you've covered. We had errors-as-values in popular, large languages (Javascript callbacks?), and by the mid-10s everyone recognized that they're kinda whatever, mostly just a different way of doing the same thing less conveniently, and that community got rid of them (as a side-effect of the more general push to get rid of callback hell, but certainly no effort was made to keep errors-as-values around). We say "being forced to handle errors is great in Go", but (1) you don't have to handle them, you just have to acknowledge them with `_`, and (2) Java has had checked exceptions for years, and everyone also recognizes that those are ish. And, as you say, Go has two fundamentally different kinds of errors functions can throw (what color is your function?), except the facilities for handling panics are essentially a goto (which, I love pointing out lest we all forget, go also has literal goto). Sure, working code shouldn't panic; but all that asserts is that Go wasn't designed to be fault tolerant. To be clear, I don't feel as much passion for hating on Ruby, because I don't use Ruby. I use Go. I don't wish to hate on the language for the purpose of hate; I wish that more people would agree that the situation is quite poor, rather than good, and that we could make meaningful positive change to the language.