What does HackerNews think of exhaustive?

Check exhaustiveness of switch statements of enum-like constants.

Language: Go

#70 in Go
#7 in TypeScript
Easily handled by adding a linter. Like you pointed out, that's an easy place to make mistakes, and this regularly catches them for us https://github.com/nishanths/exhaustive
This is an analyzer that will catch this: https://github.com/nishanths/exhaustive

I believe it's in golangci-lint.

>> the main thing missing from Go is ADT's. After using these in Rust and Swift, a programming language doesn't really feel complete without them

What are the differences between an ADT (plus pattern matching i’d reckon?) in Rust/Swift vs the equiv in Go (tagged interfaces + switch statement)?

One has exhaustive matching at compile time, the other has a default clause (non exhaustive matching), although there’s an important nub here with respect to developer experience; it would be idiomatic in Go to use static analysis tooling (e.g. Rob Pike is on record saying that various checks - inc this one - don’t belong in the compiler and should live in go vet). I’ve been playing with Go in a side project and using golint-ci which invokes https://github.com/nishanths/exhaustive - net result, in both go and rust, i get a red line of text annotated at the switch in vscode if i miss a case.

Taking a step back, there isn’t a problem you can solve with one that you can’t solve with the other, or is there?

To take a step further back, why incomplete?

There are linters available that help you do the "just trust me to" part.

Edit: https://github.com/nishanths/exhaustive is available in golangci-lint