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.

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

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.