> it's also probably better than the "Pretend this error didn't happen" type error handling that programmers write when they are forced to handler the 80% of po

> it's also probably better than the "Pretend this error didn't happen" type error handling that programmers write when they are forced to handler the 80% of possible errors that will never occur. It’s interesting that Go programs don’t have either of these problems. Not necessarily because of technical controls, but because of a strong culture of “handle your errors” that adapts programmers to actually think about how their program should behave when things don’t go exactly as planned. > And if you need a high-reliability system where 500 errors aren't acceptable, then Go is the wrong language, period. Its static type system is a joke and it doesn't provide any real formal verification beyond that. This is a false dichotomy. You don’t have to choose between 500ing on a client error or never-ever throwing 500s. You could use 500s as they were intended—to signal server issues. And while it’s true that Go’s type system doesn’t cover ~5% of cases (and that’s generous), surely it’s better than Python’s which covers zero? (Yes, I know about Mypy and no it’s not yet suitable for a production system).