29 ms·
Go Developer Survey 2022 Q2 Results
- tapanjk 4y agoTLDR (listed under "key findings" in the post): - Generics has seen quick adoption. - Fuzzing is new to most Go developers. - Third-party dependencies are a top security concern. - We can do better when announcing new functionality. - Error handling remains a challenge.
- ptsneves 4y agoError handling remains a challenge, but as satisfaction is high it gets no answer at all. Not a single paragraph, how unfortunate. It hits at my major quip with Go: that I do not trust it's governance structure. Otherwise I really like using it, and would replace it everywhere python is used.
- klabb3 4y ago> It hits at my major quip with Go: that I do not trust it's governance structure. I normally don't hold back against corporate projects and especially Google's list of forgotten or mismanaged ones. However, I've always felt Go has been doing well, compared to other languages. Older languages painted themselves into a corner (Python, C++) and newer ones (no names mentioned) already struggle with painful design-by-commitee compromises and identity crises. Every year or so I check in to see what's new in Go, and I'm mostly pleasantly surprised. They're addressing long standing feature requests, add meaningfully to the std lib, and tools get a lot of love as well. Sure, things are incredibly slow sometimes, but long term stability of a global and mature language is one of the hardest things to maintain and grow safely. They also don't leave users hanging with gaping ecosystem holes anymore (anyone remember the pre-go mod days and GOPATH hell?), when other languages throw their hands up and say "HTTP isn't our responsibility, that's a 3p issue" or "it's not our fault people misuse our language features, it's devs that are stupid".
- biomcgary 4y agoTo each their own. I love that Go is slow to change due to their governance. I think the version of generics that was finally adopted is demonstrably better than the previous proposals. Until the current Go leadership steps down, I really trust the backwards compatibility promise, too.
- deleted 4y ago[deleted]
- mfer 4y agoI wish they would ask what makes it difficult to work with dependencies in Go.
- verdverm 4y agoWhat is difficult? I find them very refreshing compared to other dep mgmt systems. They also have a lot of secondary benefits most are not aware of. https://verdverm.com/go-mods https://verdverm.com/go-mods
- bragr 4y agoI 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
- bheadmaster 4y agoI find go's package system very convenient for quick projects: go mod init <name> [write code] go mod tidy go build It's definitely more convenient than Python's venv dance.
- just-ok 4y agoPython’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.
- bheadmaster 4y ago> Python’s venv dance only really comes into play if you need a third-party dependency that you haven’t installed globally. True. Though installing third-party dependencies globally is considered bad practice, since it can easily break system packages. > The Go dance is always necessary, which makes it slightly more annoying for short scripts or tests. Well, if you just want to compile/run a single file (or a couple of files) without third-party dependencies, `go build main.go` and `go run main.go` will work just fine, too.
- aniforprez 4y agoI'm genuinely hoping that after generics, the focus will be on error handling from the survey results Go devs in a lot of communities love to put their heads in the sand going "error handling is perfectly fine". But it's not fine. Not even close. And I'm very happy there's a lot of demand for some solution in this space. It's just plain too verbose without any of the actual benefits of that verbosity. You don't have compile time checks for errors. Ignoring errors continues to be incredibly easy. The lack of exhaustive switch case statements makes this worse because the compiler doesn't care if you're handling all the expected error types (or unexpected ones). If you simply want to push errors up the chain to be handled elsewhere you're adding 3 lines of code in every function that just does `if err != nil { return nil, err }`. This much verbosity means almost every developer's eyes just glaze over all this code during review which I find to be quite dangerous. If this one thing is adequately fixed in Go, it wouldn't make the language perfect but it would probably make for the most pleasant development experience for building APIs and services
- pipe_connector 4y agoIf I'm reading your feedback correctly it sounds like you want: 1) Syntactic sugar for if err != nil { return err }; similar to ? in Rust 2) The errcheck linter to be enforced (part of go vet, maybe?) 3) Exhaustive switch statements The first point was looked at and no one has proposed a solution enough of the community could agree was an improvement while maintaining sufficient explicitness. If someone has a really good proposal for this I am sure it would be considered. The second point could probably happen with enough lobbying. So, verbosity is still there but at least every project will do something with their errors. The third point I don't believe is possible today because of the way interfaces work. If Go added sum types then this should be possible, but I could be mistaken about that.
- aniforprez 4y ago1) Yes I didn't want to make the tired comparisons to Rust but Rust does have the excellent syntactic sugar for returning errors. Of course, something like this is hampered by the lack of sum types and the ambiguous zero values in Go which makes it more difficult for the compiler to know what to return but I hope we eventually get there or we find another way to do this 2) I'm not a fan of leaving error checking to linting. It would be fantastic if the compiler would stop for mishandled errors. It already doesn't compile for banal things like unused imports and variables 3) It's not really a matter of wanting exhaustive switch statements as such but if this was present, it would make error handling much simpler, again a la Rust (I'm sorry) These are all hopes and wishes to make the language better to work with and I'm sure if we get anything close to any of this, it would be a while. The Go governance seems to move very slowly and deliberately considering how long it took them to wake up to adding generics but we can still dream
- zinclozenge 4y agoI'm glad generics saw good adoption. My wish is that they improve the efficiency of closures so that we can use generic functions to efficiently operate on slices and maps. Writing a for loop just for checking membership is quite tedious.
- awb 4y agoAs a developer, Go seemed so promising 5-10 years ago. But as a recruiter, I never saw any kind of stable movement towards Go adoption among startups. Hard to tell why that was because functionally and programmatically it’s a really clean, efficient language and tooling stack.
- icy 4y agoI would think otherwise, actually. Go seems to be the most popular choice at startups—anecdotally, of course. I have no data to back this, just what I’ve seen.
- H1Supreme 4y agoWhile I was interviewing a few months ago, there were plenty of startups looking for Go developers. Plus, startups reaching out to me about Go jobs.
- pdimitar 4y agoSemi-counterpoint: I tried interviewing for Go jobs and asked the inconvenient questions early. TL;DR: 11 out of the 12 preliminary interviews were about companies seeking maintainers of "legacy" Go code after important contributors left. Like with you, not an actual representative sample but quite telling at least from where I am standing.
- deleted 4y ago
- melony 4y agoMy 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 https://go.dev/blog/pipelines should clearly mention that it can still be considered current up to the latest version of Go. First-party documentation needs to be held to higher standards.
- nappy-doo 4y agoI 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?
- Macha 4y agoI 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
- hbogert 4y agoI 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?"
- melony 4y agoYou are missing the point, documentation is either evergreen, or it is not. If you don't clearly state whether your documentation is current, then it leads to a lot of confusion.
- geodel 4y agoI'd like to other blogs which of announcement of being current. There are deprecated notice I have seen, else things are considered current by default.
- totallyunknown 4y agoIt's a pity that there is few progress in http3 or support for Linux KTLS.
- neonsunset 4y agoMight be slightly offtopic but C#'s .NET 7 will ship with http3 enabled in Linux by default (needs libmsquic dependency). Also, if it's of interest to you, the performance is significantly better at gRPC workloads than Go: https://aka.ms/aspnet/benchmarks https://aka.ms/aspnet/benchmarks (page 9)
- whb07 4y agoBut first, fix your gopath
- saturn_vk 4y agoWhat gopath?
- bilinguliar 4y agoI am delighted with the error handling in Go. Overall I would prefer to Go with the current features and not add more, maybe even deleting some inconsistencies in Go v2.
- nerdwaller 4y agoWhat kinds of inconsistencies are on your mind?
- bilinguliar 4y agoI never use new(). It gives a way to allocate, that I would prefer to avoid in favor of declaring zero-value explicitly. Maybe I am missing the point of new().
- 37ef_ced3 4y agoIt's used like this p := new(int) since you can't say p := &int{}
- bilinguliar 4y agoIndeed, this may be the use case. I am curious how often you may need a pointer to an int.
- marwatk 4y agoIn things like rest APIs you need them quite a bit to distinguish between a value being the zero value and not present at all. Most libraries I've seen have an IntPointer or similar function exposed globally.
- bilinguliar 4y agoThis is true. In the case of REST, it is your “encoding/json” who will allocate for int pointer. So I do not see why new() is needed.
- kbd 4y agoSurprised to see language satisfaction so high. Error handling is very painful, and Go's own tools don't work together (eg. go mod tidy doesn't work properly with `go.work` since being released in 1.18). So many things in the language feel bad for no reason. At least they finally added generics!
- the_gipsy 4y agoCompiler simpleness is the reason, and in return it's fast. Still sucks, though.
- _wolfie_ 4y ago> and in return it's fast I'm still curious where this came from. There are slower compilers, sure, but golang's compiler is not that fast. It is very smart about caching, but that is not the same thing...
- 5d8767c68926 4y ago>Surprised to see language satisfaction so high. Who else do you think responds to these surveys? I have a long list of grievances against Go, so I don't use it, and am not qualified to participate in a survey.
- bheadmaster 4y agoTo be honest, many other languages have a lot of users that are quite unsatisfied with it, despite using it regularly (Java comes to mind). The fact that most of the people who use Go are happy with it isn't that insignificant.
- maximus-decimus 4y ago"There are two types of languages, the ones no one complain about and the ones no one uses" -- C++ dude
- beltsazar 4y ago
- haskellandchill 4y agoI'm a Go developer now (oops thought it was a Rust position, will fix this next year). I would put it firmly in the middle of my ranking of industry languages. Haskell, Rust, Ocaml, F#, Elm > Scala, Kotlin, Swift > Go > Java, C#, C++, C > Clojure, Lisp, Elixir > JavaScript, Python, Ruby, R, Php, Perl
- hajile 4y agoAlmost 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 4y ago[deleted]
- LukeShu 4y ago> 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/doc/go_lang_faq.html#generics 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 https://news.ycombinator.com/item?id=30128061
- avgcorrection 4y ago> Proportionate to the complexity If many people like it and find it useful then their armchair calculation of the complexity tradeoff might have been totally wrong.
- summerlight 4y agoYeah, 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 https://go.dev/blog/survey2019-results) to 79%. And even before that generic had been always one of the top complaints.
- randomdata 4y agoRandom internet comments don't mean anything. Nobody who mattered said that Go didn't need generics. In fact, Ian Lance Taylor, the lead behind getting generics in Go, has been working on adding generics to Go inside Google since before any of us outside of Google had even heard of Go. It was always explicitly on the table. It just took a long time, after many failed proposals, to find a solution that didn't come with unacceptable compromises.
- fulafel 4y agoNice to see fuzzing get mainstream visiblity and signs of adoption like this.
- throwaway893031 4y agoI begrudgingly use Go. Go really fucked us by not having sum types or exhaustive type-safe switches or pattern matching. It doesn't even have optionals, or type-safe nillables. The error handling is the least of my concerns. Moving on, I'd like to see an ML-like language (with hindly milner) that has M:N threading, with pre-emptive multitasking, and safe concurrency with borrow checker like Rust, with both structural and nominal typing. Something of a mix of Rust, Go, Erlang, and OCaml. Not sure about error handling, maybe just use exceptions (ala swift), polymorphic variants (ala ocaml), or error unions (ala zig). Most importantly in the next language iterations, we need to stop with the async/await nonsense, and let the runtime and/or compile handle that.
- deleted 4y ago[deleted]
- BoorishBears 4y agoHave you tried Kotlin?
- mardifoufs 4y agoI'm curious about your last point. What's the problem with async/await?
- nobleach 4y agoWhether it's Thread.new() or go func() or whatever. There needs to be an explicit way to say, "do this concurrently, NOT synchronously". That's pretty much all async/await is trying to accomplish, no?
- strager 4y agoFunction coloring is a problem with async/await: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
- beltsazar 4y agoI wonder if what I heard from some people is true, that at Google Go isn't used as widely as people think.
- pphysch 4y agoWhat do people think? That Google is using it for everything?
- 37ef_ced3 4y agoYou can think of Go as the modern representative the Plan 9 and Oberon schools of thought -- their answer to (and replacement for) C and C++. The fact that it was developed at Google is incidental. That's where Robert Griesemer (Oberon) and Rob Pike (Plan 9) and Ken Thompson (Unix, Plan 9) and Russ Cox (Plan 9) and Ian Lance Taylor, etc., happened to be employed.
- clpm4j 4y agoWasn't YouTube rewritten mostly in Go several years ago? Java and C++ won't be displaced as the primary languages at Google, but I think Go is in the top 4 languages they use (along with TypeScript).
- geodel 4y agoWell I don't know who are those people. Reasonable people would think Google would not let employees simply re-writing major chunk of existing code for production services in Go. So tons of huge projects in C++/Java/Dart will remain in same languages unless the product itself is sunset. Even then also Go will not be used to write OS kernel, device drivers and such. So where ever else Go is used it is decent enough.
- assbuttbuttass 4y agoGoogle employee here, for my role I work almost exclusively in Go. A lot of legacy code is C++ or Java, but almost all of the new software being developed uses Go.
- cletus 4y agoI 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.
- icholy 4y ago> Putting domain names in import statements is a massive mistake. Why do you say that? I appreciate the lack of indirection.
- convolvatron 4y agoseems to me like a worldview problem. are remote resources really persistent and associated with long lived commercial organizations like github? or are they more like urls that come and go. it would suck to have to deal with another location service, although one could imagine using something like DNS were it sufficiently secure. but on the other hand, I'm personally kind of offended that there is a rent-seeking intermediary in the middle of my development process
- lvass 4y agoI would dislike if my text editor asked me to fill a survey and would definitely not respond, hopefully they find a better way to randomly sample but surely it's nice to have the random vs self-selected split, I wish the charts showed it better. I'm sure the sample is also heavily biased with non-Chinese respondents, golang seems to be getting really popular in China despite being long past peak popularity elsewhere, unfortunately the survey doesn't give many insights on that.
- AtNightWeCode 4y agoSome thoughts. There is no best practice on how to structure a Go code base. go.dev is still ugly. It is ok in comparison to the old Win95-styled design. That awful closure fib example on go.dev is still a good reason to ignore Go. I would guess most of all devs don't understand it when they read it the first time. Fuzzing in general is an anti-pattern but can be useful.
- bilinguliar 4y agoI struggled with examples of codebase structure when I was learning the language. I looked into code written by Go contributors, and it struck me as “procedural.” This is where a significant shift in my programming started: abandoning OOP, removing unnecessary dependencies, moving from Linux to OpenBSD, from k8s to VM, and from clouds to bare metal. Pros: I understand computers better and have more fun. Cons: companies are still at the stage of moving to a cloud. And now I have to wait for trends to catch up.
- AtNightWeCode 4y agoC was the lang I first really learned. You can look at opensource projs and they are all very different. C# solutions for instance are so generic it is almost boring.
- BryLuc 4y ago