In practice, those have honestly been the two largest assets to me. No generics means not worrying about a coworker going off the rails and creating a library where it's not needed (me being that coworker often in my past), and clumsy error handling means factoring said error handling into your APIs, making you much more deliberate about where and how errors are eaten. Having used Java extensively, those two 'warts' have honestly saved me a lot of heartache.

How much do your colleagues (ab)use goto statements that Go provides? :)

C++ has goto, Java has “break <label>“, nobody uses it but you see a lot of generics abuse.

I’ve seen break label a handful of times for nested loops. Whether that was the best choice is of course always up for debate. It’s definitively possible to replace and not a necessary language feature.

Maybe it’s a good thing it’s not widely known, generics are trivial to discover.

What can be classified as generics abuse in Java?

Using generics anywhere only a single type is ever used. The ambiguity really just hurts readability and creates a landmine for future engineers that think other types can be used willy-nilly and things will behave as they should. Especially if some optimizations get done underneath that assume or asserts some set of types, but doesn't enforce them at the API level.

Using java is abusive towards generics, they didn't deserve that?

I've literally never seen them. Not even once.

One of them has to be the for loop reusing value thing.

    func processItem(item *string) {
      if item == nil {
        fmt.Println("nil item")
        return
      }
      fmt.Println(*item)
    }
    
    stuffToProcess := []string{"one", "two"}
    wg := sync.WaitGroup{}
    for _, item := range stuffToProcess {
      wg.Add(1)
      go func(s *string) {
        time.Sleep(1 * time.Millisecond)
        processItem(s)
        wg.Done()
      }(&item)
    }
    wg.Wait()
    // What do I print?

Playground here: https://play.golang.org/p/mouvT1BkpNJ

gosec[1] will warn you about this, at least.

    [reuse.go:26] - G601 (CWE-118): Implicit memory aliasing in for loop. (Confidence: MEDIUM, Severity: MEDIUM)
    25:    wg.Done()
  > 26:   }(&item)
    27:  }

[1] https://github.com/securego/gosec

Easily enough fixed by item := item (that is, shadow the variable with something new that won't be overwritten)

Can‘t this be fixed by changing bits to be passed by value?

https://play.golang.org/p/srAyKZN2NTH

Yes, it is odd to pass the address of a local variable from the enclosing scope like this to a go routine.

Well that's true in the sense that usually you'd just close over it, which is the classic broken case of closing over a mutable binding: https://play.golang.org/p/40FRmvhifBl

I assume GGP's contrived example is to show the underlying mechanics of the issue.

I think these two rightfully get highlighted, but I've found it difficult to organize complex Go code (though clearly some people manage), which I think is now my biggest issue with the language.

It's inability to deal with cyclic references, the lack of overloading, the lack of package-level visibility and the lack of static functions all contribute to a lot of ceremony.

You end up with functions like newUserWithPassword and NewRole (casing intentional), instead of User::new() and Role::new()

You could just have a NewUser that takes a NewUserOpts which exposes a fluent interface. But again, a lot of ceremony.

You can use a package per type, but still no overloading, and you'll need a 3rd package to bridge the two if the reference each other.

> It's inability to deal with cyclic references, the lack of overloading, the lack of package-level visibility and the lack of static functions all contribute to a lot of ceremony.

After 4 years of Go, this is usually a design thing. Once I figured out how to separate and isolate domains of interest better, I stopped running into these issues entirely. My code, in and outside of Go, is much better for it. I also learned that much of "thread-safe" programming is taught this way, which makes sense.

F# has similar constraints, and gets similar complaints, and yet advocates (like I) think it’s a feature, not a bug. Most problems can be decomplected, and I like that Go enforces this particular constraint.

Do you possibly have any example projects you would be willing to share?

I've been getting into Go for the past couple of months, but I still struggle with this.