5 ms·

My real life use-case for generics in Go: API for client-side pagination

46 points by varankinv 4y ago

Traubenfuchs 4y ago
I am surpsised by the fact that in 2022 go developers are rediscovering and being fascinated by generics when any general introductory programming education with a type safe language should have exposed them to it. It feels like a massive step back in what you should expect the average developer to know about programming.
- vsnf 4y ago
  Without being too flippant, that is Go’s history in a nutshell.
  - Traubenfuchs 4y ago
    Do you know how Go handled collection classes in the past without generics? Where they just not typesafe, like a Java List<Object>?
    - christophilus 4y ago
      The native collections were generic already. They were a special case. Custom collections were either hand-rolled for a specific type, unsafe as in your example, or generated per type using a tool.
    - feffe 4y ago
      Built-in map and vector types are generic. E.g. map[int]*MyType Using interface{} is quite common in the absence of sum types (or inheritance with base class). I guess interface{} is like Object in Java. It's not worse than Python or other dynamic languages that many people are fine with. The run-time panics when asserting that a type is something it's not. E.g. https://go.dev/play/p/c4hx8HSiB8I https://go.dev/play/p/c4hx8HSiB8I That said, no, it's not optimal and could be better (IMHO).
      - foldr 4y ago
        >Built-in map and vector types are generic. I understand what people mean by this, but it's not true for any reasonable notion of 'generic'. Pre-generics Go no more has generic maps than C has generic arrays. Yes, you can declare a map or a slice of values of any given type, but you can't write a generic function that abstracts over these types. That's what is usually meant by 'generics'.
        erik_seaberg 4y ago
        There were three or four generic types and a few generic functions (close, len, cap, make, append, delete, x[y], <-, ==, for-range, select), they just didn’t let normal users define new ones without forking the compiler.
        foldr 4y ago
        I don’t think it makes sense to see built in operations on arrays and maps as generic functions. If 'len' was some kind of built-in generic function then you'd expect to be able to monomorphize it like this: func intLen(foo []int, lenfunc func ([]int) int) int { return lenfunc(foo) } intLen([]int{1,2,3}, len) There is just no sense in which Go 1.17 has “generic types” and (e.g.) C doesn’t. All statically typed languages allow you to define arrays of different types and use the same operators on these arrays. Go adds a handful of additional built in types (slices, maps, channels). The idea that some completely ordinary language features somehow constitute a crippled version of generics that has been 'turned off' for regular users seems to be an artefact of certain communities' hobbyhorsing over Go's (former) lack of generics.
        erik_seaberg 4y ago
        As a thing that takes an argument and returns a result, I would have expected len to be an ordinary function. That I don’t is only because I remember the disappointing state of the language at launch.
        maxiepoo 4y ago
    - KarlKode 4y ago
      The usual pattern was to use an empty interface (`var collection []interface{}`).
- kitd 4y ago
  I don't think they're particularly surprised or fascinated by generics. Just glad that they have finally appeared after years in the planning.
- saturn_vk 4y ago
  I always assumed most people were against it afraid of generics because they only had experience with dynamic typed languages and heard someone complain about c++ templates that one time.
- zarzavat 4y ago
  I’m sure that you can find similar articles for Haskell “My real world use-case for loops”. There’s a certain kind of programmer who delights in using languages that have something missing, for puristic reasons or the challenge[0]. And sometimes these languages develop religious dogma: not only can you program without loops: it’s better for you too! Like a fad diet. These diet languages attract other people who perhaps don’t have a broad experience with many paradigms and they believe everything that has been written about the evils of loops. Finally someone jury-rigs loops back into Haskell. Behold! The unlooped slowly open their eyes and shift out of their slumber. “It turns out loops are actually useful, huh.” [0] http://prog21.dadgum.com/38.html http://prog21.dadgum.com/38.html
  - formerly_proven 4y ago
    Linux ecosystem and C cough
  - youerbt 4y ago
    This is such a biased view. Java doesn't have functions and you have to work around that (by treating your classes as namespaces). Python doesn't have a type system and you have to deal with that (by using your brain, I guess). Sometimes it fits language design ("religious dogma" in the eyes of some), sometimes it simply didn't get implemented. Loops in Haskell are pretty common, tho. Perhaps you meant concept like for loop and this doesn't really fit.
- tchaffee 4y ago
  > what you should expect the average developer to know This sounds like unnecessary gatekeeping. By whose standards? Most of the web runs on JavaScript and PHP. With TypeScript the frontend is steadily moving towards more "type safety" (an ambiguous term). But the point is that most of the useful things on the web have been built using languages that take the opposite approach. And there is a good argument to be made that a dead simple learning curve (without having to learn about types for example) is how we ended up with so many webapps so quickly. Much of the early web was built by amateurs.
- Comevius 4y ago
  Anyone can learn how to write generic code, the trick is knowing the price of the particular implementation of generics and when to pay it. https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-...
  - Traubenfuchs 4y ago
    I guarantee you that less than 1% of users of generic languages have the knowledge to argue about this. Java devs are in a special position since all had to find out the hard way you can't acquire generic parameters at runtime due to type erasure. In Java generics are just syntactic sugar, but this gives them the lowest (none?) runtime overhead.
    - addaon 4y ago
      Type erasure definitely does not give the lowest runtime overhead most of the time, although (a) you can always find special cases and (b) it's great for code size, which sometimes is performance-determining at the system level due to caches. The huge thing that type erasure gives up compared to per-type instantiation is the ability to do per-type inlining and the further optimizations that enables.
      - erik_seaberg 4y ago
        Yeah, monomorphization of a method is probably cheaper and faster than boxing every argument and result. I expect value types to help a lot in JVM footprint.
- s-video 4y ago
  I majored in computer engineering and only touched embedded C and assembly (and MATLAB). I later picked up Go when I wanted to write code to run on regular computers. I never actually touched generics until they were being introduced to Go and I genuinely didn't realize what they could be used for.
  - gizmo686 4y ago
    Computer engineering and computer science are different fields. A computer science degree generally requires a semester of programming language theory, which likely includes talking about generics (along with a bunch of more obscure ideas). Having said that, when presented in a PL class, the main conclusion you will come to is that generics in OOP languages are somewhere between completly broken and very confusing. In practice this doesn't come up that often, because most developers instinctivly avoid thd theoretical pitfalls.
- LVB 4y ago
  I think think post isn’t about discovering or being fascinated by generics, but just demonstrating what they feel is a good use case. The general guidance I’ve heard (including from the Go team) is that generic code is not preferable and should be reserved for use cases that particularly benefit from it. Generics in Go are brand new so it is good to see many uses (and misuses) to help establish the best patterns.
- vlunkr 4y ago
  This is a pretty bad take on the article. When Ruby added pattern matching, I was excited and interested in it because I had seen it in other languages and wanted to see how it could work in Ruby. This is no different.
- jerf 4y ago
  The thing that people who are agog about people actually liking Go should understand is "any general introductory programming education with a type safe language should have exposed them to it" is completely correct. To the best of my knowledge, nobody is learning Go as their first and only language at school. Very few people are learning it as their only language, certainly not enough to account for its growth by any means. Therefore: You have a model of the world. Your model of the world is making the busted prediction that Go shouldn't be useful for anything and nobody should like it. Instead of cutting to the assumption that "Oh, all the people who like Go must just be stupid and ignorant" to fix it up, maybe you should consider updating your model with something else. I doubt there's more than 5% of Go users who have literally never used a language with generics and are somehow unaware of them. It certainly doesn't cover me, I've used Haskell quite a bit and can easily find the generics of other languages quite lacking without trying too hard. (One thing I can tell you is all y'all agog folk really underestimate just how many of the use cases for "generics" was covered by "interfaces". Quite a lot of the "generic" use cases that leap to mind that aren't data structures parameterized by types are covered by interfaces. Even some of the "data structures parameterized by types" use cases are covered by interfaces too, just with less compiler assistance. To my mind, Go didn't "get generics" in 1.18, it merely added in the remaining 25% or so. This isn't the whole story, but it's a fair bit of it.)
wejick 4y ago
Not the best case to use generic as I'm thinking of composing a common pager struct within each kind of data would do, but in a bit different ergonomics.

46 points by varankinv 4y ago

I am surpsised by the fact that in 2022 go developers are rediscovering and being fascinated by generics when any general introductory programming education with a type safe language should have exposed them to it. It feels like a massive step back in what you should expect the average developer to know about programming.

vsnf 4y ago
Without being too flippant, that is Go’s history in a nutshell.
- Traubenfuchs 4y ago
  Do you know how Go handled collection classes in the past without generics? Where they just not typesafe, like a Java List<Object>?
  - christophilus 4y ago
    The native collections were generic already. They were a special case. Custom collections were either hand-rolled for a specific type, unsafe as in your example, or generated per type using a tool.
  - feffe 4y ago
    Built-in map and vector types are generic. E.g. map[int]*MyType Using interface{} is quite common in the absence of sum types (or inheritance with base class). I guess interface{} is like Object in Java. It's not worse than Python or other dynamic languages that many people are fine with. The run-time panics when asserting that a type is something it's not. E.g. https://go.dev/play/p/c4hx8HSiB8I https://go.dev/play/p/c4hx8HSiB8I That said, no, it's not optimal and could be better (IMHO).
    - foldr 4y ago
      >Built-in map and vector types are generic. I understand what people mean by this, but it's not true for any reasonable notion of 'generic'. Pre-generics Go no more has generic maps than C has generic arrays. Yes, you can declare a map or a slice of values of any given type, but you can't write a generic function that abstracts over these types. That's what is usually meant by 'generics'.
      - erik_seaberg 4y ago
        There were three or four generic types and a few generic functions (close, len, cap, make, append, delete, x[y], <-, ==, for-range, select), they just didn’t let normal users define new ones without forking the compiler.
        foldr 4y ago
        I don’t think it makes sense to see built in operations on arrays and maps as generic functions. If 'len' was some kind of built-in generic function then you'd expect to be able to monomorphize it like this: func intLen(foo []int, lenfunc func ([]int) int) int { return lenfunc(foo) } intLen([]int{1,2,3}, len) There is just no sense in which Go 1.17 has “generic types” and (e.g.) C doesn’t. All statically typed languages allow you to define arrays of different types and use the same operators on these arrays. Go adds a handful of additional built in types (slices, maps, channels). The idea that some completely ordinary language features somehow constitute a crippled version of generics that has been 'turned off' for regular users seems to be an artefact of certain communities' hobbyhorsing over Go's (former) lack of generics.
        erik_seaberg 4y ago
        As a thing that takes an argument and returns a result, I would have expected len to be an ordinary function. That I don’t is only because I remember the disappointing state of the language at launch.
      - maxiepoo 4y ago
  - KarlKode 4y ago
    The usual pattern was to use an empty interface (`var collection []interface{}`).
kitd 4y ago
I don't think they're particularly surprised or fascinated by generics. Just glad that they have finally appeared after years in the planning.
saturn_vk 4y ago
I always assumed most people were against it afraid of generics because they only had experience with dynamic typed languages and heard someone complain about c++ templates that one time.
zarzavat 4y ago
I’m sure that you can find similar articles for Haskell “My real world use-case for loops”. There’s a certain kind of programmer who delights in using languages that have something missing, for puristic reasons or the challenge[0]. And sometimes these languages develop religious dogma: not only can you program without loops: it’s better for you too! Like a fad diet. These diet languages attract other people who perhaps don’t have a broad experience with many paradigms and they believe everything that has been written about the evils of loops. Finally someone jury-rigs loops back into Haskell. Behold! The unlooped slowly open their eyes and shift out of their slumber. “It turns out loops are actually useful, huh.” [0] http://prog21.dadgum.com/38.html http://prog21.dadgum.com/38.html
- formerly_proven 4y ago
  Linux ecosystem and C cough
- youerbt 4y ago
  This is such a biased view. Java doesn't have functions and you have to work around that (by treating your classes as namespaces). Python doesn't have a type system and you have to deal with that (by using your brain, I guess). Sometimes it fits language design ("religious dogma" in the eyes of some), sometimes it simply didn't get implemented. Loops in Haskell are pretty common, tho. Perhaps you meant concept like for loop and this doesn't really fit.
tchaffee 4y ago
> what you should expect the average developer to know This sounds like unnecessary gatekeeping. By whose standards? Most of the web runs on JavaScript and PHP. With TypeScript the frontend is steadily moving towards more "type safety" (an ambiguous term). But the point is that most of the useful things on the web have been built using languages that take the opposite approach. And there is a good argument to be made that a dead simple learning curve (without having to learn about types for example) is how we ended up with so many webapps so quickly. Much of the early web was built by amateurs.
Comevius 4y ago
Anyone can learn how to write generic code, the trick is knowing the price of the particular implementation of generics and when to pay it. https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-...
- Traubenfuchs 4y ago
  I guarantee you that less than 1% of users of generic languages have the knowledge to argue about this. Java devs are in a special position since all had to find out the hard way you can't acquire generic parameters at runtime due to type erasure. In Java generics are just syntactic sugar, but this gives them the lowest (none?) runtime overhead.
  - addaon 4y ago
    Type erasure definitely does not give the lowest runtime overhead most of the time, although (a) you can always find special cases and (b) it's great for code size, which sometimes is performance-determining at the system level due to caches. The huge thing that type erasure gives up compared to per-type instantiation is the ability to do per-type inlining and the further optimizations that enables.
    - erik_seaberg 4y ago
      Yeah, monomorphization of a method is probably cheaper and faster than boxing every argument and result. I expect value types to help a lot in JVM footprint.
s-video 4y ago
I majored in computer engineering and only touched embedded C and assembly (and MATLAB). I later picked up Go when I wanted to write code to run on regular computers. I never actually touched generics until they were being introduced to Go and I genuinely didn't realize what they could be used for.
- gizmo686 4y ago
  Computer engineering and computer science are different fields. A computer science degree generally requires a semester of programming language theory, which likely includes talking about generics (along with a bunch of more obscure ideas). Having said that, when presented in a PL class, the main conclusion you will come to is that generics in OOP languages are somewhere between completly broken and very confusing. In practice this doesn't come up that often, because most developers instinctivly avoid thd theoretical pitfalls.
LVB 4y ago
I think think post isn’t about discovering or being fascinated by generics, but just demonstrating what they feel is a good use case. The general guidance I’ve heard (including from the Go team) is that generic code is not preferable and should be reserved for use cases that particularly benefit from it. Generics in Go are brand new so it is good to see many uses (and misuses) to help establish the best patterns.
vlunkr 4y ago
This is a pretty bad take on the article. When Ruby added pattern matching, I was excited and interested in it because I had seen it in other languages and wanted to see how it could work in Ruby. This is no different.
jerf 4y ago
The thing that people who are agog about people actually liking Go should understand is "any general introductory programming education with a type safe language should have exposed them to it" is completely correct. To the best of my knowledge, nobody is learning Go as their first and only language at school. Very few people are learning it as their only language, certainly not enough to account for its growth by any means. Therefore: You have a model of the world. Your model of the world is making the busted prediction that Go shouldn't be useful for anything and nobody should like it. Instead of cutting to the assumption that "Oh, all the people who like Go must just be stupid and ignorant" to fix it up, maybe you should consider updating your model with something else. I doubt there's more than 5% of Go users who have literally never used a language with generics and are somehow unaware of them. It certainly doesn't cover me, I've used Haskell quite a bit and can easily find the generics of other languages quite lacking without trying too hard. (One thing I can tell you is all y'all agog folk really underestimate just how many of the use cases for "generics" was covered by "interfaces". Quite a lot of the "generic" use cases that leap to mind that aren't data structures parameterized by types are covered by interfaces. Even some of the "data structures parameterized by types" use cases are covered by interfaces too, just with less compiler assistance. To my mind, Go didn't "get generics" in 1.18, it merely added in the remaining 25% or so. This isn't the whole story, but it's a fair bit of it.)

wejick 4y ago

Not the best case to use generic as I'm thinking of composing a common pager struct within each kind of data would do, but in a bit different ergonomics.