You're getting into the Turing tar-pit. There's nothing you can do in Rust you can't also do in Go, technically. Hell, you can do it all in Brainfuck too, if you so desire.
The big thing, though, is ADTs. Being able to say "the value is one of 3 possible values" is a lot easier than saying "here are three values, you should use the non-zero one".
I am fully aware of that. My question is, what specific technical problems are caused by Go not having {feature_goes_here}.
> The big thing, though, is ADTs
Except it isn't a big thing, because for the few use cases where an ADT is actually, really, really, REALLY required, they can be expressed in Go using existing language features.
Quote:
"It seems that Go can do just fine without adding variant types, due to the challenges mentioned in the beginning of the post and the ease with which the major use-cases can be implemented using existing language features."
End Quote
On the one hand, yes, this is more verbose. On the other hand, these use cases are simply not frequent enough to justify making the languages syntax and type system more complex.
Again: Yes, Go lacks many features of other languages. That is on purpose. The language is made to be simple, as in "easy to learn, easy to read, easy to refactor, easy to generate, easy to maintain large bodies of code".
That link shows the Go type system's lack of expressiveness. You have to manually include things like the default case. Rust's compiler will do exhaustiveness checking for you, and you can't just forget about it.
Also, it's not about ADT's being required. They're preferred, and Go's type system suffers for their lack. Go is a living, breathing example of the blub paradox in action.
> That link shows the Go type system's lack of expressiveness.
And I ask again what that is supposed to mean in technical terms, and what specific problems would be prevented if Go's type system was "more expressive".
> They're preferred
I am fully aware that for every given language feature, there are people who prefer that feature. And many languages reacted to that by including everything and the kitchen sink. That made many languages very "expressive", but that expressiveness comes at a cost: It also made the languages themselves become bigger and more complex.
Go isn't about having as many features as possible though. Quite the opposite, it's about having as many features as necessary, and as few as possible. Why? Because it keeps the language small and easy to learn and the code easy to read and maintain.
And to me (and judging by the sucess of Go I am not alone in this), that is a lot more important than a bit more "expressiveness" in things that one may come across every now and then.
What it means in technical terms is what I just told you: Rust's compiler will not let you forget to handle an enum variant. Go's compiler can't do that because the type system can't handle it.
> Go's compiler can't do that because the type system can't handle it
Correct. And that isn't a disdvantage.
The fact that Go's type system "cannot handle that" directly in it's type system (functionally, the language itself can handle that easily enough, as shown by the article I linked above) is a choice, which results in a simpler language.
And I still haven't seen any specific problems that would be prevented if Go included this feature directly in the type system. I have, however, seen a lot of extra syntax that Go doesn't need to support in its compiler, Go students don't have to learn, and Go devs don't have to worry about.
> 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.
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
> 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.
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.
> 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.
You're getting into the Turing tar-pit. There's nothing you can do in Rust you can't also do in Go, technically. Hell, you can do it all in Brainfuck too, if you so desire.
The big thing, though, is ADTs. Being able to say "the value is one of 3 possible values" is a lot easier than saying "here are three values, you should use the non-zero one".