Unfortunately for the same reason it lacks many other modern features introduced by CLU and Standard ML in the mid-70's, language designers don't want to overburn Go developers with PhD level concepts.
Algebraic data types (more technically sum types) are very much not “PhD level concepts”, despite the name. They’re just what C developers would call “tagged unions”.
I sympathise with the idea but I do think they put the line in the sand too close. Go that had generics and sum types from the start would be my near-perfect GC-ed language
Not having generics was never a fixed decision. The FAQ said since day one that they "may well be added at some point" and that "The topic remains open", so there was no "walking back".
By the way, not having ADTs is not a fixed decision either.
You seem to mistake the fact that the Go team is in no rush to add things to the language as a general rejection of these things.
It doesn't matter. What does is Go 1.0 shipped without generics. That single decision immutably affected the entire language. Now that generics have been retrofitted, the issues are clear as day:
- Awkward transition period between a stdlib with and without generics: [1]
- Completely different APIs for built-in data structures (slices, maps) and generic ones
- Lack of obvious follow-up features that would have been there at 1.0 if generics were added, e.g. iterators
They took the time to do it properly with input from experts on type systems (e.g Phil Wadler). The result is probably much better than what we'd have if the Go developers had quickly thrown together an implementation of generics 10-15 years ago. For example, the resulting type system is known to be sound.
Where did you get the information that the Go team never wanted Generics, even the hype around having generics yet the stats shows 50% of Go developers wasn’t interested in it
>Where did you get the information that the Go team never wanted Generics
By them acting as if they never wanting Generics, not having Generics from day zero, delaying their implementation for a decade with BS excuses, pretending they are some kind of unsurmountable problem....
They were literally pressureed into getting them in, after years of resistance, when they recognized the mess they've made
And over that period, not a single person put forward a viable and fully worked-up proposal for how generics should work in Go. It's almost as if programming languages aren't developed by anonymous people complaining on the internet.
>And over that period, not a single person put forward a viable and fully worked-up proposal for how generics should work in Go.
That was the official excuse (while each and every proposal coming in was shot down, just to get.a sub par, half-thought, Generics implementation, full of sui generis and NIH details implementation.
It's not rocket science, there are 100s of languages with Generics, including languages with many orders of magnitude more than the adoption Go has.
Also generics is mostly stuff that make libraries more convenient, not average user code. It also reduces bugs where otherwise interface{} and type checking would be used.
If you compare the amount of attention, language bashing, dedication and sweat being put in it I should expect the survey to show at least 75% adoption
I am not sure this is true. Every single go project I have seen at work has pkg/ and internal/
If anything, I wish people would have main.go be a bit longer so I can see the main bones of the application but people always like to a := app(conf) ; a.run()