[EnergyAmy]

> specific problems that would be prevented if Go included this feature directly in the type system

I keep telling you the specific problem that would be prevented. You can't forget to handle an enum variant. That is a specific problem that is prevented in Rust, but not Go. And no, the language doesn't "handle that easily enough".

Update an enum in Rust with a new variant? Your code won't compile until you've updated everywhere that matches against it. Do something similar using the technique you linked in Go? Good luck, hope you don't introduce any bugs by forgetting to handle it somewhere.

[derekperkins]

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

[usrbinbash]

> And no, the language doesn't "handle that easily enough".

Yes, the language handles it easily enough. ADTs, despite being the single most used example of "what Go doesn't have" since the language got generics, are not very common outside of the ML-derived-language world.

If they occur at all, they are usually used in a few very specific places. An example are AST types that are used in exactly the part of the parser handling that type.

[EnergyAmy]

They're used all over the place where they're available. More languages are incorporating them exactly because of how useful they are.

I expect much like generics, we'll get some new version of Go eventually that half-asses ADTs, with much fanfare celebrating how they were totally always going to do it, they just needed to perfect it.

[usrbinbash]

> More languages are incorporating them exactly because of how useful they are

No, more languages are incorporating them, because most languages operate under the assumption that "more-is-better" is a good design maxime, also known as the "everything-and-the-kitchen-sink" method.

Resulting in exactly the opposite of what Go is, with extreme success, doing.

Fun fact: That methodology in other langages is what made Go's success possible in the first place.

> I expect much like generics, we'll get some new version of Go eventually

I expect the exact opposite, precisely because of generics. Because it has been some time now since they were implemented, and lo and behold: They are rarely used in most codebases, because as it turns out, the people saying "Outside of some collection-types, generics are almost never required" were right in the first place.