Public opinion on Generics in Go 1.18?

In Go 1.18, Generics are being introduced. What is community reaction on this, in what ways generics can be useful ? Is it something which go really requires ?

My honest opinion?

Finally go becomes mature and I might consider it even when it is not a client’s requirement…

3 Likes

I don’t like writing code like this

func keysMapT1(m map[string]T1) []string {
  keys := make([]string, 0, len(m))
  for k := range m {
    keys = append(keys, k)
  }
  return keys
}
func keysMapT2(m map[string]T2) []string {
  keys := make([]string, 0, len(m))
  for k := range m {
    keys = append(keys, k)
  }
  return keys
}
func keysMapT3(m map[string]T3) []string {
  keys := make([]string, 0, len(m))
  for k := range m {
    keys = append(keys, k)
  }
  return keys
}
5 Likes

Hi @aryanmaurya1,

Generics a.k.a type parameters are useful for

  • container types that shall store data but not process it (lists, trees, etc)
  • generic functions that do the same processing for differnent data types (see @mje’s keysMapTn() functions for an example of a problem that type parameters solve)

Generics are a useful addition for any statically typed language but if the design is not done right, generics can negatively impact either the programmers experience, runtime speed, compile speed, or any combination of these. That’s why it took so long for generics to arrive at Go. The Go team was very careful to avoid all the traps that bad generics designs contain.

See e.g. this article - Why Generics? - The Go Programming Language - especially section “Benefits and costs”.

7 Likes

Generics is an amazing bit of work.

They listened to the Community: this was the number 1 requested feature in developer surveys.

They did not rush ahead with half baked ideas, they waited until they had a design they were happy with.

They sought out Community and Accademic feedback. As a result of the feedback from the Feathweight Go study, they removed Contracts and replaced them with more generalised interfaces.

And they got the whole thing working to a very high standard in a year of work.

Impressive work by the Go team!

4 Likes

Are you sure Generic is not https://xyproblem.info/ ?

I hope the Go author did not get Amnesia :slight_smile:

It’s definitely not an XY problem. Lack of generics results in code duplication or hard-to-read workarounds. This is a real problem, not only a perceived one.

This being said, generics have a very specific use case and should not be applied to cases where they don’t belong to. (That is, avoiding the hammer-and-nail fallacy.)

1 Like

Why wait years? I can understand 1 or 2, but years?

Because there are a million ways of designing generics wrong. The recent years were not years of waiting but years of hard work for the Go team to arrive at a solid design that is closer to the user, as well as efficient at compile time and run time.

1 Like

Yeah, that’s the argument made after generics arrived, not during the discussion that diminished people who support Go Generic in the early days :smiley:

https://research.swtch.com/generic

I don’t see where this discussion is going to. What point are you trying to prove?

3 Likes

I personally came from languages with generics and I missed them at first but eventually found myself not missing them as much as I thought I would. The tradeoff of extreme simplicity with go has been more than worth it in my experience. There are cases where generics will help me in my day-to-day work and they are a welcome addition to the language. However, in my opinion and experience, there are fewer cases than proponents of generics might lead you to believe and they’re not an absolute game-changer. Because the complex parts of my code aren’t usually generic; they’re highly specific.

So, my take is: it’s awesome and I love that Go is maturing and moving forward. The core team has taken an approach where they don’t add things to the language at a rapid pace, but when they do they generally aren’t half-baked. I personally love that, but everything with language design is a series of tradeoffs (actually, wait, everything in life is a series of tradeoffs!).

When I was writing 100% .NET code my coworkers would have friendly competitions to see who could use the most new language features because they were coming out so quickly it was hard to keep up. Eventually, I had to ask myself “is this ACTUALLY that useful if I have to challenge myself to use this new feature?”. In some cases yes (LINQ for example and the ability to project into anonymous types is incredibly useful/powerful/ergonomic and a straight up win with no drawbacks other than compiler complexity), in others maybe not. I still love what the .NET Core team is doing, and I think it’s healthy to have languages that evolve more quickly for people who prefer that. But for what I’m building right now, Go has been working incredibly well.

One thing I think we can all agree on: the biggest “win” here is that we won’t have to listen to people complain about the lack of generics anymore.

3 Likes

Haha, absolutely! Although people who want to complain always find something to complain about. Go has enough features NOT (and intentionally so). There will always be someone saying, “If Go only had X…”

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.