4 ms·

Essentially every language provides some form of generics. Even Go 1.0 had `append` (a polymorphic function) and `map[K]V` (a polymorphic type). What Go 1.0 did

Essentially every language provides some form of generics. Even Go 1.0 had `append` (a polymorphic function) and `map[K]V` (a polymorphic type). What Go 1.0 didn't have was user-defined generics. I am still of the (unorthodox) opinion that adding more built-in generics would have been a better solution than opening the door to arbitrary user-defined generics. Providing a generic `sort`, `reverse`, and a few others would cover 90% of the cases mentioned in every "Go needs generics!!" article.

HL33tibCe7 4y ago
Which other built-in generics should have been added?
dhagz 4y ago
Honestly, I enjoy the current answer to this (which was around long before Go's generics) - there is the `sort` package, which provides a lot of baseline sorting functions for built-in types, and then a function that takes a slice of `interface{}/any` and a function to sort the elements of that slice.
kaba0 4y ago
The problem is that there is no mechanism that can deal with the remaining 10%. You either copy-paste code, add overhead or use some macros. For languages that are not well-suited for the last option we can see how “well” it turned out in case of C, where everyone has their own data structure lib, or use goddamn linked lists in a supposedly performant low-level language.
- jstimpfle 4y ago
  Generic solutions are certainly not "the remaining 10%".
- nemo1618 4y ago
  I think the idea that a languages ought to cover 100% of possible usecases has done far more harm than good. It's a ridiculously high bar. We should aim for more "Pareto-optimized" languages -- languages that address 80% of the problem space with 20% the complexity.
eternalban 4y ago
Yes to reverse, but how would a builtin sort generically address comparability?
eweise 4y ago
What's wrong with opening the door to user-defined generics?
lawn 4y ago
> Providing a generic `sort`, `reverse`, and a few others would cover 90% of the cases mentioned in every "Go needs generics!!" article. That's only because the articles would be too long otherwise. When I worked in a language without user defined generics I missed them all the time, and now when I work with Rust I use them all the time.
ragingglow 4y ago
I completely disagree. Putting builtins on some special pedestal and demoting user-defined classes and functions is always a mistake IMO. I also don't see how this is a reasonable approach even in the cases you mention. If map is polymorphic, but I can't define polymorphic classes myself, it seems impossible to define classes that can hold arbitrary maps. So I can't even wrap map. Also, if I'm reading https://go.dev/tour/moretypes/15 https://go.dev/tour/moretypes/15 correctly, append is a variadic function and not a polymorphic function. That's something very different.
- turminal 4y ago
  > Also, if I'm reading https://go.dev/tour/moretypes/15 https://go.dev/tour/moretypes/15 correctly, append is a variadic function and not a polymorphic function. That's something very different. It is both variadic and polymorphic. > Putting builtins on some special pedestal and demoting user-defined classes and functions is always a mistake IMO. There is a line of thought in programming language design that claims everything should be user defined, but too much customization of everything inevitably leads to a lot of fragmentation, subtle incompatibilities and lots of ways to solve the same simple problem. Avoiding all of these issues is an important part of go's reasoning behind some of their design choices and the proposed idea could probably fit that quite well.
jerf 4y ago
"What Go 1.0 didn't have was user-defined generics." If you sit down and carefully write out the use cases for generics, which extend well beyond "parameterized data types", you'll note that Go interfaces cover a lot of them reasonably well, which is how it has been a viable language for versions 1.0 - 1.17. While this is an unpopular opinion, I don't really consider 1.18 to have "added" generics so much as completed them. (As evidence, consider how important "interfaces" still are in generics, and I can attest from personal experience with helping people that there's a lot of people who try to fire "generics" at a problem when they just need interfaces.) I say this in support of the original post. Otherwise one must reconcile how Go could be successful "without generics"; my suggested resolution is that it shipped with "bad" or "incomplete" (more charitably) generics rather than no generics. Compare programming in Go with programming in C and the differences become very clear. There's a reason so many people were able to smoothly transition their code bases from Python to Go, for instance, which a view of Go in which it literally has "no" generics finds hard to account for. You need more than just "maps" and "slices" to do that successfully.

HL33tibCe7 4y ago

Which other built-in generics should have been added?

dhagz 4y ago

Honestly, I enjoy the current answer to this (which was around long before Go's generics) - there is the `sort` package, which provides a lot of baseline sorting functions for built-in types, and then a function that takes a slice of `interface{}/any` and a function to sort the elements of that slice.

kaba0 4y ago

The problem is that there is no mechanism that can deal with the remaining 10%. You either copy-paste code, add overhead or use some macros. For languages that are not well-suited for the last option we can see how “well” it turned out in case of C, where everyone has their own data structure lib, or use goddamn linked lists in a supposedly performant low-level language.

jstimpfle 4y ago
Generic solutions are certainly not "the remaining 10%".
nemo1618 4y ago
I think the idea that a languages ought to cover 100% of possible usecases has done far more harm than good. It's a ridiculously high bar. We should aim for more "Pareto-optimized" languages -- languages that address 80% of the problem space with 20% the complexity.

eternalban 4y ago

Yes to reverse, but how would a builtin sort generically address comparability?

eweise 4y ago

What's wrong with opening the door to user-defined generics?

lawn 4y ago

> Providing a generic `sort`, `reverse`, and a few others would cover 90% of the cases mentioned in every "Go needs generics!!" article. That's only because the articles would be too long otherwise. When I worked in a language without user defined generics I missed them all the time, and now when I work with Rust I use them all the time.

ragingglow 4y ago

I completely disagree. Putting builtins on some special pedestal and demoting user-defined classes and functions is always a mistake IMO. I also don't see how this is a reasonable approach even in the cases you mention. If map is polymorphic, but I can't define polymorphic classes myself, it seems impossible to define classes that can hold arbitrary maps. So I can't even wrap map. Also, if I'm reading https://go.dev/tour/moretypes/15 https://go.dev/tour/moretypes/15 correctly, append is a variadic function and not a polymorphic function. That's something very different.

turminal 4y ago
> Also, if I'm reading https://go.dev/tour/moretypes/15 https://go.dev/tour/moretypes/15 correctly, append is a variadic function and not a polymorphic function. That's something very different. It is both variadic and polymorphic. > Putting builtins on some special pedestal and demoting user-defined classes and functions is always a mistake IMO. There is a line of thought in programming language design that claims everything should be user defined, but too much customization of everything inevitably leads to a lot of fragmentation, subtle incompatibilities and lots of ways to solve the same simple problem. Avoiding all of these issues is an important part of go's reasoning behind some of their design choices and the proposed idea could probably fit that quite well.

jerf 4y ago

"What Go 1.0 didn't have was user-defined generics." If you sit down and carefully write out the use cases for generics, which extend well beyond "parameterized data types", you'll note that Go interfaces cover a lot of them reasonably well, which is how it has been a viable language for versions 1.0 - 1.17. While this is an unpopular opinion, I don't really consider 1.18 to have "added" generics so much as completed them. (As evidence, consider how important "interfaces" still are in generics, and I can attest from personal experience with helping people that there's a lot of people who try to fire "generics" at a problem when they just need interfaces.) I say this in support of the original post. Otherwise one must reconcile how Go could be successful "without generics"; my suggested resolution is that it shipped with "bad" or "incomplete" (more charitably) generics rather than no generics. Compare programming in Go with programming in C and the differences become very clear. There's a reason so many people were able to smoothly transition their code bases from Python to Go, for instance, which a view of Go in which it literally has "no" generics finds hard to account for. You need more than just "maps" and "slices" to do that successfully.