5 ms·

Lack of generics and clumsy error handling would be my guess.

BobbyJo 6y ago
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.
- somezero 6y ago
  How much do your colleagues (ab)use goto statements that Go provides? :)
  - tirrex 6y ago
    C++ has goto, Java has “break <label>“, nobody uses it but you see a lot of generics abuse.
    - saturn_vk 6y ago
      What can be classified as generics abuse in Java?
      - masklinn 6y ago
        Using java is abusive towards generics, they didn't deserve that?
      - BobbyJo 6y ago
        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.
    - calessian 6y ago
      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.
  - BobbyJo 6y ago
    I've literally never seen them. Not even once.
latch 6y ago
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.
- kodah 6y ago
  > 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.
  - wizhi 6y ago
    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.
  - christophilus 6y ago
    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.
TheDong 6y ago
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 https://play.golang.org/p/mouvT1BkpNJ
- mimischi 6y ago
  Can‘t this be fixed by changing bits to be passed by value? https://play.golang.org/p/srAyKZN2NTH https://play.golang.org/p/srAyKZN2NTH
  - thwarted 6y ago
    Yes, it is odd to pass the address of a local variable from the enclosing scope like this to a go routine.
    - masklinn 6y ago
      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 https://play.golang.org/p/40FRmvhifBl I assume GGP's contrived example is to show the underlying mechanics of the issue.
- zimpenfish 6y ago
  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 https://github.com/securego/gosec
- JulianMorrison 6y ago
  Easily enough fixed by item := item (that is, shadow the variable with something new that won't be overwritten)

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.

somezero 6y ago
How much do your colleagues (ab)use goto statements that Go provides? :)
- tirrex 6y ago
  C++ has goto, Java has “break <label>“, nobody uses it but you see a lot of generics abuse.
  - saturn_vk 6y ago
    What can be classified as generics abuse in Java?
    - masklinn 6y ago
      Using java is abusive towards generics, they didn't deserve that?
    - BobbyJo 6y ago
      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.
  - calessian 6y ago
    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.
- BobbyJo 6y ago
  I've literally never seen them. Not even once.

latch 6y ago

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.

kodah 6y ago
> 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.
- wizhi 6y ago
  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.
- christophilus 6y ago
  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.

TheDong 6y ago

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 https://play.golang.org/p/mouvT1BkpNJ

mimischi 6y ago
Can‘t this be fixed by changing bits to be passed by value? https://play.golang.org/p/srAyKZN2NTH https://play.golang.org/p/srAyKZN2NTH
- thwarted 6y ago
  Yes, it is odd to pass the address of a local variable from the enclosing scope like this to a go routine.
  - masklinn 6y ago
    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 https://play.golang.org/p/40FRmvhifBl I assume GGP's contrived example is to show the underlying mechanics of the issue.
zimpenfish 6y ago
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 https://github.com/securego/gosec
JulianMorrison 6y ago
Easily enough fixed by item := item (that is, shadow the variable with something new that won't be overwritten)