> To overburden an analogy

Sorry. In the spirit of Go, you're not allowed to re-use this analogy; you're going to need to write another different one that can perform a similar function.

It's ok if you copy and paste some of the text from the first analogy and structure it similarly, though.

> Go takes a different approach to the same problem (in this analogy, getting from point A to point B).

Go doesn't take any approach to writing generic code at all.

That's the really disappointing part. I've read the thread where the designers talk about implementing generics, and they basically say that every language's implementation of generics sucks, and since they can't come up with a design that's perfect (no codegen duplication, but still all the perf of specialization), they're just gonna punt.

And then the code I've seen is littered with "interface {}".

That's a pretty big thing to give up, and I don't get the point. Something like F# gives you high level features (and green threads if you want) with fair perf, and Rust gives you a fair amount of language with C perf.

I think littered might be a bit strong. I'm writing a service in Go, and have yet to use interface{}. However, you might have to use it more when writing libraries.

That's false. Go has structural subtyping. It enables you to sort collections of things without actually writing a sorting algorithm. Seems like generic code to me.

It has interfaces to write generic code. It doesn't allow you to write your own generic data structures but it's not an issue because it has built-in dynamic arrays and dictionaries. You supposed to use built in data structures most of the time like with python or ruby.

This happens because almost every time there's someone who more or less asks what in the world generics are for since they can do everything they want to with Go's type system. Sure, it's possible, but it's missing the point.

I always saw it as the classical: why do you want a screwdriver to put the screw in place? The hammer should be good enough!

Well, sure, I guess you can pound a screw into things with a hammer but you're missing the point.

Or just build your furniture without using screws, like in Japanese carpentry. When people are already having a decent time building things using the tool, it looks pretty stupid to tell them they've done it all wrong for years in all the decent products they made.

Parametric polymorphism gives safety guarantees that you can't easily obtain without language support. For example if you have a function typed "forall a . a -> a" you know it has to be the identity function (or something that bypasses the typesystem, like infinite loops or a runtime exception).

And in Go since there is no parametric polymorphism you would end up writing either:

1) Methods with names that indicate the parameter types. 2) Method calls on objects to convert some internal struct data from one type to another. 3) Something I haven't thought of that doesn't involve losing a handle on your type.

So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a functional language as far as I can tell. So, yeah, it isn't as intellectually elegant, but it also isn't really that hard to deal with.

No you can't. The point of generics is that you don't need to specify the parameter types - the parameter type is also a parameter. This means that you can write type safe container operations like "map" and "filter".

The only way to write this kind of generic code in Go is to cast everything to `interface{}`, which can't be checked statically.

If you are still not convinced, one of the things you can do with generics is say "these two parameters have the same type". In Go the best you can do is say "these two parameters are subclasses of something", which is less precise.

Yeah I follow you. I am providing ways of trying to work around the lack of a higher level type class system. As a baseline, I would recommend not jumping outside golang's given type system just because it feels inconvenient for the programmer. That means you don't get to write a generic method for, for instance, all integers. Too bad :P This means the programmer does have to do more work, but the type system is always strictly enforced. That is better in my opinion.

Technically a coin should be enough to put a screw in place. winks depending on the size of the screw of course. :-)

Don't worry! All the screws have the same size and your coin is compatible. (Go's builtin data types which have generics)

You want to use different screws? You're on your own.

> To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels

Which would be just as bad as for a car, since the things that drive and guide a tank tread are wheels (drive wheels and road wheels.)