Here's a question for you: what if the Go team add user-defined generic types to the language, and people start demanding HKTs? What then? Do you implement them and hope nobody asks for dependent types? Where do you draw the line?
back
4 comments
The Slippery Slope is also a fallacy, and this exemplifies why.
Java didn't have generics. Then they didn't have lambdas. Now they're even redoing the classpath! Have they gone nuts?
No, they've been evolving, and they've kept on adding features as it was opportune and useful to do so. If tomorrow's programming paradigms depend on HKTs and dependent types, then, yes, Go might want to add them. Today's programmers are just about starting to understand what a dependent type even is, so you're suggesting to include them in Go in order to ridicule the potential inclusion of generics. This is a fallacy, because generics and dependent types are years, decades, apart. And generics are very much part of how several generations of programmers have learned, and expect to be able to program.
If your language stops changing, your language is already dead. Yet another point of similarity between natural and programming languages.
I didn't mean to ridicule anything. My point is that there are multiple evolution vectors for programming languages, and generics->HKT->DT->? is just one of them. It's quite possible that in the foreseeable future the biggest winnings might come from tooling/libraries/ecosystem rather than the type system. (Of course, those are mostly orthogonal.)
Well, it's a soristic problem, but there are some clear heuristics:
1) tons of people have asked for Generics, few have asked for HKTs.
2) C++, C# and Java, programming languages with millions of users and extremely battle tested have Generics, no mainstream language at that level offers HKTs.
3) As a result of (2) a ton more people are familiar with Generics than HKTs, and so the latter are much less probable to be requested.
And of course, if they do add Generics, and people ask for HKTs, they should consider what they do about that then and there, not now.
No reason to never make a step towards somewhere just because you might (or will) be asked to also take a further one.
Except if they believe that they are already at some optimal point (which is my case I think).
What about all those people who came to Go from Python, JavaScript, Ruby and whatnot? They are mostly content with the current status quo, generics would just make the learning cliff steeper for them. And according to the Go devs, more people come to Go from Python than from, say, C++. So perhaps it makes sense to stay at that level, at least for now?
All I'm saying is this doesn't seems like a simple equation to me. There are many possible solutions to the problem of building large, correct, maintainable, performant programs - and neither of the existing ones looks like a surefire winner given all the limitations.
People who came to Go from Python, JavaScript, and Ruby will likely have had a steepish learning curve getting used to pointers in Go. I hadn't used pointers since programming in C++ in 1995 when I switched to Go, and it took a bit of time to get used to remembering that extra detail.
In fact, because I used Clojure just before switching to Go, I found not having immutable variables harder to get into the habit of more than anything else. I actually first used Go because I needed to write something that manipulated bits in memory reliably, and couldn't be bothered going back to Java.
Indeed, not many developers have moved from C++ to Go, though there are a few from Java who might miss generics. Here is some recent data on this:
https://golangnews.com/stories/1490-results-of-the-gopher-la...
This is probably a self-fulfilling cycle to some extent... the people using go are by definition willing to tolerate the lack of generics, while those for whom it's a dealbreaker won't be represented. If go did introduce generics, it might start appealing to other types of developers.
Personally, I love most things about go, but its utter clumsiness at iteration and data transformation relegate it to a fairly limited number of use cases in my mind.
I agree containers are the one area this is a painful lack at present. Perhaps they'll look again at this in a Go 2 if they ever get round to that.
I do also really value the lack of change in the language though, it is important and rare that it is stable and not accreting features every year (compare with rust or c++).
> What about all those people who came to Go from Python, JavaScript, Ruby and whatnot? They are mostly content with the current status quo,
As a counter-example, I'm not sure this is true.
The argument works against any language feature, not just generics.
As a aside, why not add HKTs straight with generics? The problem the Go implementors have with generics seem to be about run-time representation (boxing or unboxed), but no additional run-time issues arise from HKTs. The main issues of HKTs are that type inference becomes harder. Haskell's approach of eschewing type-inference at the kind level (because it's undeciable anyway) but giving unkinded type variables the kind * seems to be a run-away success.
> What then?
Irrelevant. Go already has parametric functions like append, it just doesn't allow user defined ones. append isn't enough when a programmer needs to remembers 10+ tricks to make up for the lack of generics :