Even if it’s a silly bug to make, it really annoys me a lot knowing you could change an enum value. Is it so hard for Go to support consts of any-type?
1) I don't need you to prevent me from mutating this variable, just trust me to not mutate it.
2) I don't need you to ensure I handle every case of this enum, just trust me to update all the relevant code whenever I add a new case.
3) I don't need you to prevent me from reading the result without checking the error, just trust me to always handle errors.
4) I don't need you to track nullability in the type system, just trust me not to dereference null pointers.
5) I don't need you to let me hide the default constructor, just trust me to always use the smart constructor that establishes the invariants that I need.
6) Until recently: I don't need you to let me abstract away this type, just trust me to keep all the copies of the function/type in sync.
This philosophy may make sense for a low-level language like C, but not for a high-level language for building applications, services, etc. It amazes me that people voluntarily give up the guarantees of other languages in favor of Go for these use cases. It's almost as if the language wants bugs to slip into your code.
Even for a low level language like C it really doesn't, it makes the implementation easier but all the things you mention (and more) are useful both to ensure the foundations are solid (security, correctness) and to make it fast: the weak type system and feeble guarantees of C are why compilers lean so much on UBs to infer constraints they can then optimise based on.
Edit: https://github.com/nishanths/exhaustive is available in golangci-lint
That's wrong, otherwise dynamically typed languages like Python wouldn't be so popular.
Python with types, on the other hand, is pretty great for catching bugs before runtime.
At least they accepted some Oberon-2 influence as well.