2 ms·

> It's a welcome relief from the likes of Python where you only see (and consequently think about) the happy path. This is definitely a big driver of our 500s i

> It's a welcome relief from the likes of Python where you only see (and consequently think about) the happy path. This is definitely a big driver of our 500s in our production Python services. While there are many who are genuinely aggrieved by the number of keystrokes, I think a lot of people are annoyed at error handling in Go simply because you have to think about error handling. Okay, so let's say you're using Python. You get some 500s in production, but if you're written things in a clean fashion, they provide clear error messages and you can fix them quickly. 500 is error handling--not ideal, but 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. 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.

weberc2 8y ago
> 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).

weberc2 8y ago

> 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).