[Jare]

> I write Go all day every day and have since before Go 1.0, and I see this troll/complaint at least 100x on hacker news for each time I have to do it once in real life

I suspect that there is as much trolling in people who complain about generics, as there is survivor bias in those who reply they haven't needed them in X years of go. If you felt that you needed them, you wouldn't have lasted long using go!

[voidlogic]

Those are fair points. I also think major part of the issue here is all the folks that try to write Java/C++/Python,etc in Go, rather than Go in Go. People install Go, write something in Go, paying no mind to go idioms, and complain. It happens on the Go mailing list all the time.

[NateDad]

I truly don't see many people talking about leaving go after getting frustrated with no generics. If this were survivor bias, where are the casualties?

[Jare]

I assume most people who complain about Go's lack of generics have at least tried the language. It doesn't take long to run into your first interface{} and subsequent typecast. So, if you define "leaving Go" as "not switching to it", there are many. :)

[NateDad]

It seems like quite a leap of faith to assume a significant portion of people complaining about something on the internet have actually tried it. Most complaints about Go tend to show the opposite. For example "it doesn't take long to run into your first interface{}"... what? Sure it does. If you're attempting to write Go like Go (and not trying to write Go like Java/C#/Haskell/whatever) then you can code for a very long time without hitting your first interface{}.

[Jare]

Don't get me wrong, I'm not saying that interface{} is a terrible thing. I spent a decade writing assembly language and then just as much in C and C++ before templates were usable, I know generics are far from essential and that a little controlled type unsafety is not a huge problem in practice. But:

> you can code for a very long time without hitting your first interface{}

Negroni, a popular and self-appointedly idiomatic library: https://github.com/codegangsta/negroni/blob/master/negroni_t...

    func expect(t *testing.T, a interface{}, b interface{})
    func refute(t *testing.T, a interface{}, b interface{})

Ok, that's just for testing - it's not unusual to have to go off path to be able to test your code. How about Google's own standardized idiom for production code? https://blog.golang.org/context

    Value(key interface{}) interface{}

Or Go's own standard library? http://golang.org/pkg/encoding/json/

    func Marshal(v interface{}) ([]byte, error)
    func MarshalIndent(v interface{}, prefix, indent string) ([]byte, error)
    func Unmarshal(data []byte, v interface{}) error

No, it does not take such a long time.

[NateDad]

The context example is the only one of these that is really a valid example - and that is not something you would normally run into. I've never seen that idiom in code outside of google, so I wouldn't even call it idiomatic, regardless of the fact that it's posted on the Go blog. I'm actually sort of surprised they even posted it there.

The JSON package is handling automatic marshalling of objects to and from a textual format - of course it has to be outside the scope of normal code.

When I said "you can code for a very long time without hitting your first interface{}", I meant in code you write. It's very rare to need interface{} in your own code. Some very specialized packages (like JSON) need it, and yes, sometimes helper functions for testing need it. But for regular production code? No. If you find yourself reaching for interface{} more than extremely rarely in your code, you're probably doing something wrong.