Go 1.27 Interactive Tour

Post by LukeShu » Sun, Aug 02, 2026, 3:33 PM UTC

YesThatTom2 wrote: post #131

"The best way to teach something new is to compare it to something the audience already understands." Could someone take the example, reduce it to a non-generic version for two types I DO understand, then show that with the new feature I can collapse them into the Box/Map example in the doc? I have 10+ years of Go experience and I can't make heads or tails of "(b Box[T]) Map[U any](f func(T) U) Box[U]"

    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)}
    }

Post by typical182 » Sun, Aug 02, 2026, 3:46 PM UTC

YesThatTom2 wrote: post #131

"The best way to teach something new is to compare it to something the audience already understands." Could someone take the example, reduce it to a non-generic version for two types I DO understand, then show that with the new feature I can collapse them into the Box/Map example in the doc? I have 10+ years of Go experience and I can't make heads or tails of "(b Box[T]) Map[U any](f func(T) U) Box[U]"

  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
  }

Post by foldr » Sun, Aug 02, 2026, 4:02 PM UTC

whateveracct wrote: post #154

foldr wrote: post #115

Earlier quoted context omitted.

Go lets you constrain type parameters with interfaces. To do anything analagous in SML you have to use functors, which is substantially less convenient. I think people who refer to ML's parametric polymorphism in this context must really be thinking of parametric polymorphism in OCaml or Haskell.

You just do dictionary passing.

Post by wannabe44 » Sun, Aug 02, 2026, 4:33 PM UTC

zerr wrote: post #118

baalimago wrote: post #42

This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)

Post by wannabe44 » Sun, Aug 02, 2026, 4:36 PM UTC

scotty79 wrote: post #88

baalimago wrote: post #42

This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.

> (b Box[T]) Map[U any](f func(T) U) Box[U] 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…