Go 1.27 Interactive Tour

And to answer the second half of your request, here is that exact same code as above, but now using the 1.27 generic methods feature (with a runnable example using tip at https://go.dev/play/p/1YK62tGetsm?v=gotip):

  // Map maps from a slice containing type In to a slice containing type Out.
  func (s MySlice[In]) Map[Out any](f func(In) Out) []Out {
      var out []Out
      for i := range s {
          out = append(out, f(s[i]))
      }
      return out
  }

In short, you could always have methods on a generic type since Go first introduced generics in Go 1.18, but with 1.27, the methods on the generic type can also introduce their own additional type parameters.

(Previously, you could achieve the same net effect with a top-level generic function, but then the code would not be grouped as nicely as hanging it off of the type, and arguably it now can have slightly better ergonomics in some cases. You can see more of the rationale from Robert Griesemer at https://github.com/golang/go/issues/77273.)

Many comments on generic methods. Perhaps this example will help understand a hopefully not-too-objectionable case of using them in practice.

The math/rand/v2 package has a number of functions which return random numbers of a certain type:

    i := rand.Int32()  // a random signed 32-bit integer (type int32)
    j := rand.Uint64() // a random unsigned 64-bit integer (type uint64)

It has functions which return a number within a range:

    in := rand.Int32N(10)   // a random int32 in the range [0,10)
    jn := rand.Uint64N(100) // a random uint64 in the range [0,100)

It also has a generic function, rand.N, where the return type is set by a type parameter. The definition of rand.Int32N (for comparison) and rand.N are:

    func Int32N(n int32) int32
    func N[Int intType] (n Int) Int

Adding some spaces to make the common elements align (apologies if my formatting gets mangled), that's:

    func Int32N               (n int32) int32
    func N      [Int intType] (n Int  ) Int

As you can see, the generic function N has the same signature as the non-generic Int32N, except the type it operates on is set by a type parameter (named "Int"). The type parameter has a constraint, intType, which is a private type defined in the math/rand package. (There's nothing magic about this constraint, it's just a list of all the integer types in the language, and you can write it yourself if you want to. It's a separate type to keep the function signature of N from becoming too large, and it's internal to math/rand because it doesn't need to be part of the public package API.)

The nice thing about rand.N is that it lets you write something like this:

    // d is a random time.Duration in the range [0, 10 minutes)
    d := rand.N(10 * time.Minute)

Without generics, you'd instead write this as the following, which is a lot more noise:

    d := time.Duration(rand.Int64N(int64(10 * time.Minute)))

The generic rand.N has a more confusing type signature and a lot more language complexity behind it, but the code using it is simpler and easier to read. We think that's a good tradeoff, but of course not everyone will agree.

All the functions I've mentioned so far use a default random number source. Each of them also exists as a method of the rand.Rand type, which generates numbers from a user-provided randomness source. For example:

    rng := rand.New(rand.NewChaCha8(seed))
    a := rng.Uint64()
    b := rng.Uint64N(100)

There is one exception, though: Until Go 1.27, there was no Rand.N method, because we did not support generic methods. (A generic type could have methods, but those methods could not be further type parameterized.)

In Go 1.27, there is now a Rand.N method:

    // Using a ChaCha8-based source with a defined seed,
    // generate a duration in the range [0, 10 minutes).
    rng := rand.New(rand.NewChaCha8(seed))
    d := rng.Duration(10 * time.Minute)

This method's signature is:

    func (r *Rand) N[Int intType](n Int) Int

Comparing function vs. method and generic vs. concrete:

    func           Int32N               (n int32) int32 // function
    func           N      [Int intType] (n Int  ) Int   // generic function
    func (r *Rand) Int32N               (n int32) int32 // method
    func (r *Rand) N      [Int intType] (n Int)   Int   // generic method

In this case, generic methods permit us to fix a small wart in the package API. This example isn't the motivating reason for adding generic methods, but I think it serves as an example of how adding them makes the language a bit simpler and more consistent. In Go, methods are just a type of function. Previously, you could write a type-parameterized function, but you couldn't write a type-parameterized method. That's an inconsistency that you need to remember. Now you can write type-parameterized functions or methods, using a consistent syntax for either.

Type-parameterized methods don't participate in interface satisfaction, so this change isn't without its own subtleties. Discussing the tradeoffs there would double the length of this post, and weighing them is why it took so long for us to decide to add generic methods.

Another possibility is that people will use generic methods to write unreadably complex code. My personal opinion is that nothing will stop people from writing unreadably complex code if they want to; the fix to complexity is to not do that.

To what? What would you use instead, things like this seem common place in languages made in the last decade.

This is the kind of shit why they probably didn't want generics in the language.

This is like building a very crude general-ish DSL inside the language. Because the tools are intentionally limited (as to limit the scope of the feature), the result looks ugly. Also, like with C++ templates, people find exploits to do what the designers didn't want them to, with even more elaborate workarounds.

I liked Go before generics. It had a clear identity. If you wanted to get cute, you could use go generate and generate code. They should've made that much more convenient and ergonomic, if they wanted to make the language more powerful (and the nice thing is that it still sits outside of the language).

I think the point Go was making is that these complex things generally have little use in application code, and 99% of the time they're there for people who want to show how smart they are, at the expense of code readability, and accessibility.

No need to insult JavaScript. In two out of three times the "JavaScript" written will be something like:

    interface Box { value: T }

    function map(input: Box, func: (value: T) => U): Box {
        return { value: func(input.value) }
    }