My real life use-case for generics in Go: API for client-side pagination
vladimir.varank.in
vladimir.varank.in
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.)
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.
https://planetscale.com/blog/generics-can-make-your-go-code-...
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.
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.
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.”
Loops in Haskell are pretty common, tho. Perhaps you meant concept like for loop and this doesn't really fit.
cough
Where they just not typesafe, like a Java List<Object>?
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).
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'.
This is how built in collection types work in pretty much all statically typed languages. For example, here is an array of ints in C:
int foo[] = { 1, 2, 3 };
> any new type created by a mere programmer has to be monomorphic.
Collections in (pre-Generics) Go are monomorphic. []foo and []bar are as different as foo and bar. That is why, for example, the first argument of sort.Slice has type 'any' (https://cs.opensource.google/go/go/+/go1.18.2:src/sort/slice...)
But was the built-in append function generic pre generics? I think it is?
func intLen(foo []int, lenfunc func ([]int) int) int {
return lenfunc(foo)
}
intLen([]int{1,2,3}, len)
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.