Almost 40% of respondents either use generics or want to use generics. That's a pretty quick uptake given the decade of loud, prominent voices shouting that go didn't need and shouldn't have generics.
[deleted]
Go Developer Survey 2022 Q2 Results
61–70 of 186 posts
Re: Go Developer Survey 2022 Q2 Results
#62Almost 40% of respondents either use generics or want to use generics. That's a pretty quick uptake given the decade of loud, prominent voices shouting that go didn't need and shouldn't have generics.
> loud, prominent voices shouting that go didn't need and shouldn't have generics
The party line has always[1] been that generics would be nice to have, but "We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it." The prominent voices had been saying "the need is overstated", not "there is no need"; but I understand[2] why so many hear it wrong.
[1]: Language FAQ, from Nov 11, 2009; one day after the 1.0 release: https://web.archive.org/web/20091113154906/http://golang.org...
[2]: Nuanced communication usually doesn't work at scale: https://news.ycombinator.com/item?id=30128061
Re: Go Developer Survey 2022 Q2 Results
#63Earlier quoted context omitted.
> You don't have compile time checks for errors. Doesn't the fact that errors are values, combined with the fact that you cannot ignore values (except explicitly by assigning them to "_"), provide compile time check for errors?
Not really. It's idiomatic to use a single "err" variable for every error value in the same function body, and the compiler will only check whether that variable is used at least once; it doesn't perform a data flow analysis to ensure that every value that might be assigned is used. So if you assign 10 different error results to the same variable at various points, but only actually check it 9 times and forget the 10…
You are right. I forgot about that case.
Perhaps variable re-declarations (via := operator) would be a good addition to Go. Compiler could optimize the code to re-use the variables when possible, but the semantics of the language would force the programmer to handle each and every error.
Re: Go Developer Survey 2022 Q2 Results
#64Earlier quoted context omitted.
> You don't have compile time checks for errors. Doesn't the fact that errors are values, combined with the fact that you cannot ignore values (except explicitly by assigning them to "_"), provide compile time check for errors?
Not really. Go thinks this is fine (on mobile, forgive me if I get this wrong). foo, err := foo() if err != nil { return nil, err } bar, err := bar(foo) return bar, nil The problem occurs because go only cares if a variable is used once per definition. Not once per assignment.
You are right, I have missed that, as I have written under the sibling comment.
Though I'd like to ask - does that scenario really happen in practice? It is idiomatic to handle every error right after the function call that returns the error. To me, the lack of "if err != nil {" under the "bar(foo)" call really stings my eyes.
I know, compile time checking is different from "it doesn't happen in practice". It's a tradeoff. I'm just wondering about the magnitude of the impact.
Re: Go Developer Survey 2022 Q2 Results
#65I wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.
Re: Go Developer Survey 2022 Q2 Results
#66I was glad to see Go get generics. Not because it was super-important but rather so we didn't have to hear about it anymore.
I think exceptions are a false economy so I have no real issue with Go's error handling. It could be cleaner. Rust's match expressions are better. Multiple returns are a bit awkward. Something like a result or error union type would be better and could fit in with the type system. Standard errors might allow more automatic (or at least less boilerplate on) propagating errors.
Go's dependency management is the real weak point. Putting domain names in import statements is a massive mistake. Java's Maven repos are simply better. Just ignore the XML for declaring dependencies). Thing slike being able to specify version is what you want. Having someone be able to verify dependencies is what you want. The latter may be necessary in a corporate environment where it may be too much of a security risk to allow open imports.
Re: Go Developer Survey 2022 Q2 Results
#67My main gripe with Go is that a large percentage of first-party documentation is not kept up to date well. If you dive deeply into Go's concurrency patterns, many of the recommended readings are old blogposts from 2014-2016. When the behaviour of the internals change, these blogposts are not clearly marked as deprecated either. For example this post https://go.dev/blog/pipelines should clearly mention that it can sti…
I don't understand. You're upset that Go's documentation from 2014 is adequate, and that the language hasn't changed to make it obsolete?
I think the problem is there is enough stale documentation and valid-but-not-recent documentation that you regularly encounter both which makes distinguishing the two cases difficult
Re: Go Developer Survey 2022 Q2 Results
#68Almost 40% of respondents either use generics or want to use generics. That's a pretty quick uptake given the decade of loud, prominent voices shouting that go didn't need and shouldn't have generics.
Yeah, I firmly believe that those purist voices have been over-represented. From 2019, they seems to change the keyword aggregation methodology in Go Dev Survey and the portion of generic just skyrocketed (https://go.dev/blog/survey2019-results) to 79%. And even before that generic had been always one of the top complaints.
Re: Go Developer Survey 2022 Q2 Results
#69My main gripe with Go is that a large percentage of first-party documentation is not kept up to date well. If you dive deeply into Go's concurrency patterns, many of the recommended readings are old blogposts from 2014-2016. When the behaviour of the internals change, these blogposts are not clearly marked as deprecated either. For example this post https://go.dev/blog/pipelines should clearly mention that it can sti…
I don't understand. You're upset that Go's documentation from 2014 is adequate, and that the language hasn't changed to make it obsolete?
I find the op's perspective weird as well, though I have colleagues which reason like this at well when I point to those blogs/talks of 2014-2016 during reviews -- "that can't be the way to do it 8 years later right?"
Re: Go Developer Survey 2022 Q2 Results
#70Earlier quoted context omitted.
I find go's package system both too cumbersome for small/quick projects, and yet leaving me wanting in more complex scenarios. It's gotten better of the years, but I never really enjoy my encounters with go-mods
I find go's package system very convenient for quick projects: go mod init [write code] go mod tidy go build It's definitely more convenient than Python's venv dance.
Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. I usually resort to the Go playground for them.