I have both production systems (ircrelay.com) and well-used client software (packer.io) written in Go, so I'd like to comment on this from both perspectives, server-side and desktop-side.

First off, both from the get-go have been extremely reliable. IRCRelay has a custom IRC router that is able to route IRC connections to their proper bouncer server, then just stream the contents to and from. This server was written once, and has been running in production for over a year without a single downtime incident or crash incident.

Likewise, Packer reliability has been astounding, even to me. It really rarely crashes, and when it does it is because I'm usually skirting around the type system of Go (casting).

The PRIMARY reason Go is so reliable is also a reason many people hate go: you _have_ to handle every error. There are no exceptions, you know if a line of code can fail or not, and you have to handle it. This leads to a lot of "if err != nil" checks, and it can be really, really annoying sometimes. But the truth is: once you get that thing into production, it is never going to crash. Never. MAYBE nil slice access, but that's about it. Note the compiler doesn't actively enforce this, but it is Go best practice to handle every error.

(Pedantics: yes, you can assign errors to "_" variables to ignore them or just not accept any return values, but this is very actively discouraged in Go and it is one of those you're-doing-it-wrong kind of things)

Also: a compiler. Coming from Ruby, having a compiler is just amazing. Obviously compilers have been around forever and Go's isn't special in any way. But after living in a dynamic language heavy environment for many years, I can't imagine going back to not having a compiler. It just makes writing new features, refactoring old ones, etc. all just so easy. It catches all the bone-head mistakes that cause a majority of crashes in code I previously wrote.

Another reason: Testing is heavily encouraged and baked right into the official build tool. This makes it so easy to write tests that you always do. It isn't really an opt-in thing, because it is one of those things you just DO if you write Go. This makes it so that even with explicit error checking and the type system, you're fairly certain your logic is reasonably correct as well.

And finally, you're statically compiling your applications. Once they're running, no external dependencies can mess that up. Dependency management from _source_ form is a problem with Go, one that is actively acknowledge and being worked on. But once that program is compiled, it is safe forever as long as you run it on a proper kernel.

So my experience is anecdotal, but there are real language features and community ideologies at play here that make Go a really stable language to write programs in.

> The PRIMARY reason Go is so reliable is also a reason many people hate go: you _have_ to handle every error. There are no exceptions, you know if a line of code can fail or not, and you have to handle it.

> Pedantics: yes, you can assign errors to "_" variables to ignore them, but this is very actively discouraged in Go and it is one of those you're-doing-it-wrong kind of things

The _ thing is fine because it's visible, but what's potentially insidious is the compiler having no complaints about:

    func DoIt() error {
        return errors.New("No")
    }

    func main() {
        DoIt()
    }

---

For non-gophers: The reason this doesn't come up all the time is that functions often return multiple values, at least one of which you actively need, at which point you are forced to do something with any error that comes along for the ride.

True, but I consider this the same idea. If you look up the API of a method and see an "error" return type, it is your responsibility to handle it, and you're very encouraged to do so.

I'd love it if "go vet" or something complained about implicitly discarded errors. If you mean to ignore an error, you can always assign to _.

(Still would be cool if the Gophers put something like it in the std distro.)