[latronic_notron]

> they also remove the rails that keeps Go code pretty consistent

But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all.

> For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative

Why would generics break that? Funcional programming and type-safety/polymorphism are orthogonal concepts. IIRC, generics were introduced in Barbara Liskov's CLU language, which is imperative.

It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

[weberc2]

> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)

Even if I were making a positive assertion like "generics costs more than it gains", that would be a pragmatic viewpoint even if it's incorrect. But I'm not even making that assertion, I'm merely unsure and would like to be persuaded otherwise (and I find people with experience on both sides of the fence to be more credible than those without that experience).

> Why would generics break that?

Because "generics" as a feature suffices to support multi-paradigm programming. It explodes the solution space, creating many solutions for problems that Go's type system is perfectly capable of dealing with (~97% of the problem space in practice according to my experience) while permitting new solutions that Go's type system must currently punt on (~3%). We should be able to roughly agree on this even if we disagree about the degree to which multiple solutions is a problem relative to the advantage of the additional type safety.

[latronic_notron]

> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)

That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you specifically!

> Because "generics" as a feature suffices to support multi-paradigm programming.

I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is.

In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional.

Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO.

My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}.

[1] http://aquaraga.github.io/functional-programming/golang/2016...

[weberc2]

On a phone, so sorry in advance for terse response. Agreed that the language would be simpler in some sense with generics; I don’t think it would be more readable due to aforementioned increase in expressivity. Interesting point about first class functions, and while I largely agree, the variation in Go code is still small and constrained which is my point. :)

[yawaramin]

You don't find the existing Go code using the built-in generics (arrays, dictionaries, channels) readable? You find that its expressiveness makes it too complex?

[weberc2]

Sorry if I haven’t articulated my position very well: the property I care about is consistency of code throughout the ecosystem which exist due to the constraints such as the absense of user-defined generics. Hopefully that’s a little clearer, and makes it obvious why “a few built in genetics” is fundamentally different than user-defines generics.