My real life use-case for generics in Go: API for client-side pagination
vladimir.varank.in
My real life use-case for generics in Go: API for client-side pagination
1–10 of 30 posts
Re: My real life use-case for generics in Go: API for client-side pagination
#2I 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.
Re: My real life use-case for generics in Go: API for client-side pagination
#3I 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.
Without being too flippant, that is Go’s history in a nutshell.
Re: My real life use-case for generics in Go: API for client-side pagination
#4I 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.
I don't think they're particularly surprised or fascinated by generics. Just glad that they have finally appeared after years in the planning.
Re: My real life use-case for generics in Go: API for client-side pagination
#5I 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.
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.
Re: My real life use-case for generics in Go: API for client-side pagination
#6I 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.
Without being too flippant, that is Go’s history in a nutshell.
Do you know how Go handled collection classes in the past without generics?
Where they just not typesafe, like a Java List?
Re: My real life use-case for generics in Go: API for client-side pagination
#7Earlier quoted context omitted.
Without being too flippant, that is Go’s history in a nutshell.
Do you know how Go handled collection classes in the past without generics? Where they just not typesafe, like a Java List ?
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.
Re: My real life use-case for generics in Go: API for client-side pagination
#8I 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.
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.”
Re: My real life use-case for generics in Go: API for client-side pagination
#9I 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.
> 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.
Re: My real life use-case for generics in Go: API for client-side pagination
#10Earlier quoted context omitted.
Without being too flippant, that is Go’s history in a nutshell.
Do you know how Go handled collection classes in the past without generics? Where they just not typesafe, like a Java List ?
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
That said, no, it's not optimal and could be better (IMHO).