This seems like a straw man. I don't think anyone has claimed Go's type system has novel features.
> the reason it took so long was because it came out of an environment with actors (including a part of the community) pushing against the feature.
The reason it took so long is because it simply wasn't the biggest fish to fry. Generics are a massive feature, and there were a lot of other opportunities to deliver more value for considerably less work. Of course, there was a healthy amount of pushback against rushing generics, considering generics must interact with every other feature in the type system even if those features aren't novel.
Frankly, people make too big a deal about generics. It will be a neat quality of life improvement for certain kinds of code, and a lot of additional code will enter the ecosystem which is gratuitously abstract. Builds will probably get a fair bit slower on average while still being fast relative to most other languages. Frankly, no type system feature will ever impact a language as significantly as things like tooling quality, ecosystem, runtime performance, static+native compilation, iteration loop time, learning curve, etc.
> Frankly, people make too big a deal about generics.
Different strokes for different folks, but I think generics are a huge deal. They make libraries so much more ergonomic and reduce toil generally. It's a case of dealing with many, many small papercuts over a long period of time rather than a big-bang sort of thing.
> tooling quality
I'm a huge proponent of tools, so much so that I worked on programming language tools for 5 years. My perspective is that tools are there to optimize an existing experience, but reach a local maxima in the overall experience because they're limited by language semantics. When you improve language semantics, tools get to improve experience again. That's why it's so important to do language design in a way that strongly considers the tooling experience, and a big reason why you see so much love for languages like TypeScript and C#. They work hand in hand. And generics are an example of how semantics can push tools to be better.
When I think about tooling, I'm thinking about things like build systems and dependency managers. In Go, I don't need to script my own build system like I would do in C, C++, Java, etc. Similarly, reproducible package management works out of the box--I don't need to try in vain to get the right versions of the right dependencies installed to the right locations like I do in C and C++ (and Python, to a lesser extent). Moreover, Go produces native static binaries out of the box by default--I don't have to cobble together a bunch of configuration in every one of my projects only to have it broken by the odd transitive dependency which can't be statically compiled (well, this is probably the case in some Go packages, but I contend that it's far rarer than in the Java, Python, Rust, etc worlds--certainly I've never run into this in my decade with Go). Further still, in Go, I don't have to write CI pipelines to build and publish code packages nor documentation packages.
And then there is the toil reduced by having good performance. I have about 15 years of experience with Python, and almost invariably there's some hot path in the code which needs something between Python's level of performance and Go's level of performance. Unlike Go, Python affords relatively little headroom for optimization--you can't easily parallelize anything or pull some allocation out of a tight loop for a 10x performance gain. Usually this looks like rearchitecting your codebase so that "rewrite the hotpath in C/multiprocessing/etc" is attainable and on top of that you're probably implying significant changes to your build system and/or runtime environment as well as a load of maintainability problems associated with anything that touches the language/process boundary.
By comparison, I think the gains from generics are relatively small.
> I'm thinking about things like build systems and dependency managers.
Ah, that's a different kind of tooling. This matters, but there are loads of developers out there who care just as much (if not more) about IDE tooling and other things that assist in the writing and refactoring of source code itself. Features like generics open up new ways to make this tooling better.
It's also worth pointing out that you can have your cake and eat it too. .NET and Rust are fine examples of having great build/package management tooling, runtime performance, compiler performance (.NET far more than Rust), artifact management, and so on. And great IDE tooling in different environments.
Yes, I agree that IDE tooling is nice and that it doesn’t conflict with having good build tooling; my only point is that, given the choice between good tooling and generics (or any type system feature), I would choose the tooling hands down every single time.
I was speaking about evaluating languages, especially existing ones. If you pick a language based on type system without considering other factors, you’ll end up in a bad place. If you pick a language with good tooling/ecosystem and a mediocre type system, you’ll still be in a pretty good place. As far as I know, there aren’t many general purpose languages with good type systems and tooling.
"Frankly, people make too big a deal about generics."
I think there's a lot of confusion brought in from languages where generics are a bigger deal than they are in Go, because when generics came in to those languages it was like turning on a light.
However, if you map out the problem space of "what did generics solve in those languages", rather than obsessing about the solution, what you find is that Go's interfaces, combined with the structural typing ("static duck typing" basically, rather than having to explicitly declare conformance at declaration time) covered quite a bit of the problem space. And that's what matters, whether the problem space is covered, not whether the problem space was covered in exactly the same way as some other language.
People who either have never programmed in Go, or only spent long enough with it to try to program "(Not Go) in Go" (e.g., "Javascript in Go"), and didn't learn how to use the tools Go has to cover the problem space, end up vastly overestimating their utility in Go, and vastly overestimating the sort of problems you can't use Go to solve. They're like "How can you program in a language that doesn't cover the 'generics' problem space?", and the answer is, "You're actually right, I couldn't! But I can use Go, because it actually does cover quite a bit of the problem space, just in a different way than what you're demanding." Interfaces DO NOT cover all the space, I would never dream of claiming otherwise, but they cover a lot of the space. There's even some problems where I've found Go simply outright the best solution because of some particular thing I can use interfaces to solve.
I'll actually kind of miss the "How can I do this without generics in Go?" questions on /r/golang. They're fun, and with the exception of "data structures", generally I didn't just come up with "a" solution, but with a good solution.
I'm currently working on a process that has to manipulate collection of data and its really aggravating to invent custom functions to do basic manipulations such as groupby, maps, filter, etc. It basically feels like java back in the early 2000s.
I agree that you didn't tamper with the quote, but you clearly weren't rebutting it either. Rather, you were rebutting the idea that Go's type system contains novel features, which the author didn't allege.
The author did allege that the implementation took a long time _because_ the Go type system is "untraditional", which made the task at hand challenging.
While it's not clear what one might mean by a "traditional" type system, I'm claiming that the solutions to the problem of implementing generics in Go were well-known (not novel), and therefore the difficulty of coming up with them doesn't justify the long time it took to develop the feature.
You're mistaken here. "non-traditional" doesn't mean "novel", it just means "something that isn't traditional". For example, eating cereal for dinner is non-traditional, but that doesn't mean no one has done it before.
That's a bit of a stretch... If someone made a language that directly copied Haskell's type system, I'd 100% call it a non-traditional type system, but there would be nothing novel about it.
> the reason it took so long was because it came out of an environment with actors (including a part of the community) pushing against the feature.
The reason it took so long is because it simply wasn't the biggest fish to fry. Generics are a massive feature, and there were a lot of other opportunities to deliver more value for considerably less work. Of course, there was a healthy amount of pushback against rushing generics, considering generics must interact with every other feature in the type system even if those features aren't novel.
Frankly, people make too big a deal about generics. It will be a neat quality of life improvement for certain kinds of code, and a lot of additional code will enter the ecosystem which is gratuitously abstract. Builds will probably get a fair bit slower on average while still being fast relative to most other languages. Frankly, no type system feature will ever impact a language as significantly as things like tooling quality, ecosystem, runtime performance, static+native compilation, iteration loop time, learning curve, etc.