10 ms·
> It, to me, is Go's third biggest wart. Out of curiosity, what are the first two?
by saghm 6y ago
> It, to me, is Go's third biggest wart.
Out of curiosity, what are the first two?
- j-james 6y agoLack of generics and clumsy error handling would be my guess.
- BobbyJo 6y agoIn 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 agoHow much do your colleagues (ab)use goto statements that Go provides? :)
- tirrex 6y agoC++ has goto, Java has “break <label>“, nobody uses it but you see a lot of generics abuse.
- saturn_vk 6y agoWhat can be classified as generics abuse in Java?
- masklinn 6y agoUsing java is abusive towards generics, they didn't deserve that?
- BobbyJo 6y agoUsing 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 agoI’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 agoI've literally never seen them. Not even once.
- latch 6y agoI 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 agoDo 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 agoF# 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 agoOne 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 agoCan‘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 agoYes, it is odd to pass the address of a local variable from the enclosing scope like this to a go routine.
- masklinn 6y agoWell 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 agogosec[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 agoEasily enough fixed by item := item (that is, shadow the variable with something new that won't be overwritten)
- shp0ngle 6y agoNot him. For me it's: 1. context.Context and putting everything under the sun there, untyped (which is a design fault, not just "people using it wrong") 2. reusing the looping variable in for loop 2.5. general awkwardness of go templating (I plan to write whole article about this, but too lazy to actually write it)
- pcl 6y agoI struggle with context.Context as well. It really comes across as a design cop-out. The language makes a big deal about memory management and data structure ownership, and as a result it’s sorta a pain to send stuff around on the stack, both at initialization and runtime. As a casual golang user, the context mess feels like an escape hatch to help with those problems. I’d prefer some GC compromises built into the language itself instead.
- throwaway894345 6y agoI'm confused about how a "GC compromise" would help with having to pass things around the stack. It sounds like you just want a request-scoped global or something, but I don't know what that has to do with the GC? FWIW, I think request-scoped globals are terrible and is among the many things I hated about Flask. I think generics will largely solve this problem by allowing us to write generic middleware with a type-safe context and probably even functions to compose the middleware and automatically propagate the context variables.
- pcl 6y agocontext.Context is used in a number of situations, including for a "don't call it a request-scoped global". And whatever, web frameworks always end up with one of those. Would love to see languages do better, but ok. My concern with its use in golang is that so much seems to get jammed into it. My experience with it is that it ends up being a holding pen for all the things that other systems do with initialization-time dependency injection / resource lookup sorts of things, but replaced with "oh just pass `ctx` as an argument everywhere". From what I've seen of Go, it looks like that happens because of the state management idiomatic constraints of the language, which in turn seem GC-related. In a garbage-collected language, I'd put a bunch of context-y things into some sort of request executor datastructure, the web framework would manage the initialization and retention of that, and request handlers would operate against those intialized data structures. That doesn't line up all that well with idiomatic Go, and so we end up needing to hide those sorts of things somewhere else. Enter context-abuse. Of course, there are plenty of use cases where those sorts of patterns aren't relevant. Right tool for the job and whatnot. Again, I'm a casual golang user at best -- I bet I'm missing some newer / better approaches, and would love to learn more about what they are.
- nemothekid 6y agoFirst, I consider warts of the language to be things that are side effects of the way the language is designed. This means that I would have loved for Go to have non-nullable types, Pike didn't bless Go with that feature. Same for generics and the other popular criticisms. That said the other 2 are 1. Error handling. Not only is `if err == nil` (or my preferred `if _, err := foo(); err == nil`) a lot of noise, errors are completely opaque and might as well be strings. 2. Dependency management. It was a mess for a long time, go modules fixed a lot of issues in it's own way but still has problems (e.g. the "v2" workaround). My theory is they expected everyone, in some way, to "self-host" their modules (like how Java would have com.google.foo.bar, eventually everyone else would have "http://go.company/package http://go.company/package", but GitHub became central repository of software for everyone and linking directly to packages was no longer sound).
- tgv 6y ago#1 has improved a bit lately, but I did get some mileage out of making my own type which carries an optional HTTP status, a severity level, the core error and an optional payload; and it implements Error(). It allows for easy logging, and can be used to return to the http client with a variety of messages.
- tptacek 6y agoErrors in Go have been queryable chains since 1.13; it's pretty seamless with `%w`. Rust has the `?` shorthand, which is very convenient, but also the annoyance of type matching errors, particularly across different libraries, to the point where third-party error handling libraries like `anyhow` are pretty important. Leaving nil itself out of the picture (obviously, I'd rather Go had Option types), I don't know that either language has a definitive edge here. Errors in modern Go are definitely not just strings. Before wrapped errors in Go, this would have been an easier case to make against the language.
- tsimionescu 6y agoMost errors in Go are still just strings, potentially with some comparison possible witht sentinel values like in the "io" package. As and Is give some nice tools, but its still up to documentation to decide which one to use, and different packages have different conventions for returning error types vs error values.