> The one tiny drawback is that the globals have to be variables instead of constants, but that’s one of those problems that really only exists in the theoretic

> The one tiny drawback is that the globals have to be variables instead of constants, but that’s one of those problems that really only exists in the theoretical realm. I’ve never seen a bug from someone overwriting a global variable like this Same goes for the original problem. I’ve heard a lot of people complain about Go’s enum types accepting hard coded values, it’s a conceptual problem, sure, but is it a real problem in practice? It’s not something I would ever do by accident. I don’t find my self passing random hard coded values to methods. I would have to look up the actual expected enum value, at which point I would think “I should make this a constant” at which point it fails to compile and I find the enum. Even then, in reality I would have noticed the type and the enum long before that. Hard coded values in and of themselves are a code smell. Like sure, in theory a typo could compile, but it seems like a hard mistake for a non-malicious developer to make.