[haolez]

Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple.

However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

[btilly]

Which interfaces-based solution?

The one used by sort is a hack that only works for some of the things that you would want to do.

The one where you use introspection performs badly and isn't typesafe.

The tree implementation in the article cannot be done in a safe and performant way in Go today.

[haolez]

The one mentioned in the article.

It's not a hack: it's a runtime equivalent that requires that your type implements some interface.

[btilly]

It is a hack. The article lists a whole series of things that are standard in other languages that you can't do in go. Here are some examples:

  Find smallest/largest element in slice
  Find average/standard deviation of slice
  Compute union/intersection of maps
  Find shortest path in node/edge graph
  Apply transformation function to slice/map, returning new slice/map

And here are data structures that other languages have but go does not:

  Sets
  Self-balancing trees, with efficient insertion and traversal in sorted order
  Multimaps, with multiple instances of a key
  Concurrent hash maps, supporting parallel insertions and lookups with no single lock

If it were not a hack, then go would not have these limitations.

[majewsky]

> Multimaps, with multiple instances of a key

Isn't this just map[Key][]Value? The standard library uses these in several places, e.g. url.Values and http.Header, with assorted utility functions.

[btilly]

You should send that feedback to the author of the article. I literally just cut and pasted those lists.

[silasdavis]

Probably yes: https://medium.com/@arschles/go-experience-report-generics-i...

Many smaller projects would benefit too. I would like to build a typesafe tree for an efficient sorted map, and to be able mergsort over multiple trees of different types. It would allow some extremely useful channel combinators for doing rather common things like safely shutting down a service with some background processing. Often these things leak and a often I find myself spawning more go routines just to map between types or to stop generic interface types infecting the rest of the API.

[jerf]

I have been vigorously pro-generics since the beginning, and this is the reason why: I want generic data structures. Arrays&slices and maps are great, and they really are the 90/10 solution a lot of the time, which is precisely why putting direct support into your syntax for the two of them is so very, very popular, but that other 10 comes up.

Plus, there are some generic data structures that will really work well in Go, like, for instance, an immutable tree. Granted, it'll still take some care to use properly in Go as it does not have "const" or anything like it, but it can still be done. The problem I have is not with accidental mutation, but that I just don't want to sit there and implement the immutable tree code. (Trees are great, but they're really tedious to write in the best of times, and nightmares to debug in the worst.)

I'm not terribly interested in trying to jam functional programming into Go; I may make light use of map/filter/reduce but even if this was fully implemented it would still be a fairly unpleasant experience (function that return "a value and an error" aren't much fun to map and can't hardly "chain" at all). But I've missed being able to just grab a particular data structure a few times.

[silasdavis]

I agree with the 90/10. An example of something I use in its non type safe generic form that would benefit: https://github.com/eapache/channels

[noncoml]

Generics and Interfaces solve different problems

[ci5er]

Yes - but don't they get contangled?

How would you re-orthoganize the problem statement? (Statements, actually)

[dotaheor]

Yes, I think. Now, the kubernetes project uses too many code generators, which makes it is to extend.

[saturn_vk]

I take it you've never actually read the K8s source code.

[YawningAngel]

Kubernetes is a transpiled Java project, so yeah, Java-like features would definitely make it easier :P

I think idiomatic golang works pretty well without generics in most cases, the big problem for me is that functional programming is essentially impossible without them.

[yureka]

Can you provide some resources on what makes you think Kubernetes is a transpiled Java project?

That's definitely not the case from what I know/understand...

[tuvan]

There is a talk about it you can find here: https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...

[snazz]

It was originally written in Java and lots of its Go code is a strange mix of the two (Java-like idioms in Go). This might be where the term "Gova" came from.

[pjmlp]

The original team used Java, and the actual team rewrote it in Go.

[jjtheblunt]

https://en.wikipedia.org/wiki/Kubernetes says original Kubernetes was all C++.

[eshyong]

If you read the article more closely, it says that Borg was written in C++. If you watch the video linked by @tuvan below, you'll hear the speaker (who is a contributor) mention that the original authors of Kubernetes wrote the first version in Java, which was rewritten in Go.

[archy_]

Agreed on keeping the status quo, adding generics makes it really easy to write bad code and increases mental overhead. Simplicity is what we should be going for, not having generics should've been kept as a selling point.

[silasdavis]

This may be practical from the point of view of 'top level applications' in Go. But there is a lot of murk in pure Go implementations of databases, and datastructure heavy libraries that could be avoided and lead to better testing and less duplication. If you find it simpler to avoid generics that ought to be possible under this design.