Show HN: A utility for running exhaustiveness checks on “sum types” in Go
I think that switching on types in Go is gererally a total anti-pattern.<p>In case you need to handle errors, in the end the type doesn&#x27;t matter at all for you. You are interested what the implications of the error are, so the library exposing the error should just expose functions like isTemporal(e error) bool. In case you need to inform the user about the exact error, no problem, the returned error has the Error() function which shows the message, no matter the type, use that.<p>In case you&#x27;re not matching errors, then you shouldn&#x27;t worry about the type. The function returns an interface because all that should matter to you is that interface with its common behavior.<p>Otherwise you&#x27;re just fighting the language, which doesn&#x27;t make any sense, as you can just switch to Rust then.<p>EDIT: Though I&#x27;m really happy that people make more tools for analyzing Go code. Good job!