Go 1.27 Interactive Tour

    (b Box[InType]) Map[OutType any](transformFunction func(InType) OutType) Box[OutType]

    def map[U](self, f: Callable[[T], U]) -> Box[U]

    def map[OutType](self, transform_function: Callable[[InType], OutType]) -> Box[OutType]

    public <OutType> Box<OutType> map(Function<InType, OutType> transformFunction)

    public <U> Box<U> map(Function<T, U> f)

I understand the desire to keep things concrete and avoid high level abstractions, but it's a decision not to automate stuff that can easily be automated. It runs counter to the basic instincts and purpose of our field/industry. That's why it never sticks.

I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.

    func (b: Box[T]).Map[U: any](f: func(T) -> U) -> Box[U]

But anyway I find this in Go much more bearable.

    (b IntBox) MapToStringBox(f func(int) string) StringBox
    (b IntBox) MapToBoolBox(f func(int) bool) BoolBox
    (b StringBox) MapToIntBox(f func(string) int) IntBox

The T, U, and f names are the cognitive load here, because they are meaningless variables. For a specific solution, those would have meaningful names that would make it easier to understand.

  Map method 
    of b (of type Box[T]) 
      that takes f 
      (of type function that takes value of type T and returns value of type U (which could be any type))
      and returns value of type Box[U]
  is defined as follows
    return Box[U]{v: f(b.v)}

  func[U any] b:Box[T].Map(f:func(T)->U)->Box[U]:
    return {v: f(b.v)}

  func[U any] Box[T].Map(f:func(T)->U)->Box[U]:
    return {v: f(this.v)}

  // maybe all of the types could be inferred from usage?
  func Box[].Map(f):
    return Box[]{v: f(this.v)}

There are 37000 programming languages, stop forcing every single one that gets popular to look like this.

    type IntBox struct { v int }
    type StrBox struct { v string }

    func (b IntBox) MapToStr(f func(int) string) StrBox {
        return StrBox{v: f(b.v)}
    }

It wasn't a great example because "Box" isn't really a useful type. But the point is that you no longer need to define a separate "MapToXXX" method for every type you might want to map to; now you can have just one type-generic "Map" method.

I think it's trying to show a mapping operation for a generic container where the container values are of one type and the mapping function is allowed to return a container with values of a different type.

Without generics, something along the lines of the following (with runnable example at https://go.dev/play/p/KHBI1uAhbO0):

  type MySlice []int

  // Map maps from a slice of ints to a slice of float64s.
  func (s MySlice) Map(f func(int) float64) []float64 {
     var out []float64
     for i := range s {
         out = append(out, f(s[i]))
     }
     return out
  }

https://www.gopherguides.com/articles/golang-generic-methods

(That uses an example that seems similar in spirit to the Interactive Tour's example, but with a more useful type of a Stack[T] and corresponding explanation seem clearer.)

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.

Without generics:

‘’’

type Stream[T any] struct{ ... }

func (s Stream[T]) MapInt(f func(T) int) Stream[int] { ... }

func (s Stream[T]) MapString(f func(T) string) Stream[string] { ... }

‘’’

Then later you need to map floats:

‘’’

func (s Stream[T]) MapFloat64(f func(T) float64) Stream[float64] { ... }

‘’’

Then later someone outside the package wants to map a custom type. Too bad! They’ll need to make some custom wrapper that doesn’t follow the pattern.

With the genetics approach the semantics are defined once and usable in all scenarios. You don’t need to keep adding methods; instead the caller can provide the mapping function. Common mapping functions could be pre defined for convenience.

java feels kinda unhinged the more that i look at it

    public static <T extends Comparable<? super T>> T max(Collection<? extends T> c)

    Map<String, List<Map<Integer, Optional<Pair<String, Function<? super List<? extends Comparable<?>>, ? extends Map<String, ?>>>>>>> config;

"The creatures outside looked from pig to man, and from man to pig, and from pig to man again; but already it was impossible to say which was which." ― George Orwell, Animal Farm

"For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.”

Personally I'm OK with this, I didn't see any of the (many) proposals as a definite improvement. They all had trade-offs.

[1] https://go.dev/blog/error-syntax

I kind of want to leave it there. But that will probably be looked on disfavorably.

I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading:

    val, err := whatever(...)
    if err != nil {
        // handle error
    }
    // use val

    val := whatever(...)
    if err, isErr := val.Error(); isErr {
        // handle error
    }
    realVal := val.Value()
    // use realVal

There's also no win in trying to offer a monadic interface like

    finalVal := whatever(...).OnVal(func (val Value) opt.Option[Result] {
        // use val
    })

Really the solution is, install golangci-lint, turn on errcheck [1], use a pre-commit hook to make it a commit failure if golangci-lint fires, and that pretty much covers the problem in practice.

One of the problems with Option/Result/etc. advocacy... not the pattern itself, the advocacy... is that it is generally are presented, implicitly or explicitly, as if the alternative is C, with its errno and the need to not just check an error value, but remember to go actively seeking out errors constantly, making it easy to forget. But by modern standards, that's completely pathological.

If we rate error handling techniques on a scale from 1 to 10 (best), C here is a 1, and standard Option is maybe an 8 or a 9. The way Go does it is maybe a 6; it is completely true that you can neglect to handle an error (see errcheck comment in previous paragraph), but it is in your face that an error is possible, and that's really most of the problem. Putting Option/Result/etc. is not always a "go from 1 to 9" result. "Go from 6 to 8" is a much less impressive proposition, and the other inconveniences that come with it in Go tend to overwhelm the gain. I use errcheck all the time, and even in the Before Times when I was writing it all by hand it really didn't fire all that often. Especially if I exclude test code. In an AI era this hardly rates at all. AI never neglects the error.

Whether it does the right thing with it, now... that's another story entirely.

Read those error handling clauses if you're writing Go with AI. I really don't like what I've seen AIs do with them by default. What I've seen out of AI has been very thoughtless. Nominally correct in some weak sense, but thoughtless.

[1]: https://golangci-lint.run/docs/linters/configuration/#errche...

I feel the sumtype/emum/routine demanders should yell a little harder so Go team can find their purpose again.

Lib boost will have conquered every language by then!!! :D

Jokes aside, generics are unusable in a lot of languages due to their syntax choices. In Go we kinda have the problem that there's no real templating and no real macros, so they're even harder to use.

But I agree somewhat, generics feels to me like an anti pattern in Go.

Also, the way the Go core/stdlib is written, it makes generics so unnecessarily painful to debug. Why they decided to have definitions like "~C" or "~[]S" is beyond me. No human knows what the resulting compile time error means. They should have named these things "Comparable" or "Slicable" or whatever is more expressive. Just stop with this stupid single letter shit.

Seriously, that's all it was. Just Ian alone proposed and rejected a half dozen of his own different approaches to generics. Finally a language + implementation plan came together that people all liked.

Nobody was ever opposed to generics that I saw.

> In his landmark book The Art of Computer Programming, legendary computer scientist Donald Knuth noted that although the first binary search algorithm was published by John Mauchly in 1946, the first bug-free version was not published until 1962—taking a staggering 16 years to get right.

The Go ecosystem was a delicate, special thing. It was a wholesale rejection of the malignant consultancy takeover of programming that had festered and spread for the previous 15 years. Introducing generics was a grievous error, and they just keep making it worse.

It used to be you could look at any Go code from any author and pretty much instantly understand it completely. That’s no longer the case.

It used to be you would work on a problem, just writing the code from top to bottom. No time wasted fiddling with abstractions you’ll never use. You’d grumble about it, but succumbing to the temptation was impossible. That’s no longer the case.

Yes. Everyone else knows that they were always expected to be included at some point, as told when Go was first announced to the world: https://www.youtube.com/watch?v=rKnDgT73v8s&t=3267s

> So what changed?

Philip Wadler, of Haskell fame, decided to help? This was well publicized on HN at the time.

> I’m not buying the “it took us 20 years to understand how to do it correctly” argument

If I recall correctly, Pike suggested that they never would have been able to come to that understanding without the outside help. I can understand why you are surprised that it took 20 years for someone with the right expertise to show up. You can get the sense in the above announcement that even the Go team thought that open sourcing the project would attract the right talent far, far earlier. But, now that we have hindsight, we can see that all the experts on HN who could have been the missing positive contributor were too busy complaining that Go didn't have generics. There wasn't enough time left for them to lend a hand. There are only so many hours in the day.

The original maintainers moved on to other projects and the new community maintainers came to a consensus through the proposal and governance process.

At runtime, there are only List[int], List[string], etc. List[T] is not a thing anymore.