[flashmob]

Type system is pretty cool in go. Particularly how the interfaces work, you don't have to explicitly declare that your object /type implements an interface, it automatically figures it out.

Lack of genetics makes the code easier to read. Much better with interfaces. Check this out http://blog.jonathanoliver.com/golang-has-generics/

[kerkeslager]

Duck typing is admittedly nice.

The article you linked is deeply confused. He complains about a complicated generic type that he never encountered, and it's not clear if he's even used generics at all. He also says that if he needs to reuse something later he'll just implement an interface (huh?).

[Silhouette]

Check this out http://blog.jonathanoliver.com/golang-has-generics/

I'm afraid that's not a well-informed article. The assumption that the main use case for generics is collections is very limiting, for example. That might have been one of the original motivations, but today generic types are widely used for countless data structures and algorithms, and even modelling entire patterns of computation in languages like Haskell. They let you prove a lot more useful properties than just not inadvertently trying to pull a foo out of a set of bars.

[rbehrends]

> Check this out http://blog.jonathanoliver.com/golang-has-generics/

The author makes the common mistake of assuming that subtype polymorphism can be a full replacement for parametric polymorphism. It isn't, and neither is parametric polymorphism a replacement for subtype polymorphism.

[hokkos]

The blog author cannot even mocks generics right, in C# the string type in not a generic type. He recognize generics are good for map, list, but it is ok that users can't declare their own without explanations, only vague caricatures. Go community is all about choice-supportive bias (aka post-purchase rationalization).

[cannabis_sam]

Check this out: https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

Particularly this:

>Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.

>What it says is that he finds writing containers like lists of ints and maps of strings an unbearable burden. I find that an odd claim. I spend very little of my programming time struggling with those issues, even in languages without generic types.

>But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.

>Programmers who come to Go from C++ and Java miss the idea of programming with types, particularly inheritance and subclassing and all that. Perhaps I'm a philistine about types but I've never found that model particularly expressive

(He then continues to rant about inheritance, without mentioning generics again.)

So basically, Go does not have Generics and one of the creators justified it by conflating subtype polymorphism, parametric polymorphism and ad-hoc polymorphism (inheritance, generics and interfaces in oop terms).

I happen to agree with Rob Pike that inheritance is a bad way to model things in most cases, but that's a non-sequitur argument against generics.

I also think his arguments about composition is weak, especially compared to how function composition works in Haskell. The Doug McIlroy-quote he pulls out fits great with point-free style haskell, and parametric polymorphism/generics is extremely useful for this.

(To be fair, he has since said that it is a weakness that might change: https://blog.golang.org/slices )

[puobelle]

https://www.reddit.com/r/programmingcirclejerk/comments/6m7g...