I 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.
Go Developer Survey 2022 Q2 Results
71–80 of 186 posts
Re: Go Developer Survey 2022 Q2 Results
#72Earlier quoted context omitted.
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.
> 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.
Re: Go Developer Survey 2022 Q2 Results
#73Earlier quoted context omitted.
> You don't have compile time checks for errors. I don't quite understand this statement. The compiler finds errors in my code all the time. Should it be evaluating something like `if err != nil`?
A real problem is when something like this occurs x, err := thisFuncFails(); // some other lines of code, but err is not checked x.callMethod(); // this crashes at runtime unless you explicitly ignore `err`, the compiler shouldn't allow you to use `x` without checking err. In Rust/Zig this is accomplished with the union types, which doesn't allow to use `x` until you have checked it's not an error. This is also very…
The problem is worst with procedural functions
os.Mkdir("foo")
looks pretty innocent but with no return value to use, the compiler is no help in reminding you this is a fallible function
Re: Go Developer Survey 2022 Q2 Results
#74I 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.
Likewise. Go was engineered for simplicity mostly in reaction to the complexity of C++. As anticipated, now that we got generics, some developers keep asking for more and more features. Let's not turn Go into another C++ when its goal is to stay a straightforward, simple, modernized C.
Re: Go Developer Survey 2022 Q2 Results
#75Earlier quoted context omitted.
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?"
You 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.
Re: Go Developer Survey 2022 Q2 Results
#76Surprised 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!
> Error handling is very painful
Wait until you try Typescript. First you have to try/catch and then you also need an if statement to type assert the error in order to do anything with it. Now that's painful. If errors were commonly returned as values you could beautifully reduce it to if statements alone.
Re: Go Developer Survey 2022 Q2 Results
#77Earlier quoted context omitted.
As a recruiter, which languages seemed the most valuable to startups?
I get constant requests for Node & React (web) and Python (AI / ML) developers. I do a little recruiting in the mobile space too and there’s a small need for React Native but a huge need for native mobile devs.
The reason why you are not getting any requests for Go is because you are not asked to find people for backend.
Re: Go Developer Survey 2022 Q2 Results
#78I 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.
Do you write primarily HTTP / RPC services? I've found Go's error handling very tedious when "return an error to the caller" is almost always the answer, but for background stuff, daemons, etc. it's nice.
I write HTTP/RPC and some TCP servers, implementing specs to parse files and data processing pipelines based on PubSub, NATs, etc.
Whenever the server fails to do what is needed - in most cases, it will retry with a backoff. In case it is not retryable - most often, it will exit, an alert will fire, and I will start handling an incident.
Background jobs run in a goroutine and send a non-retryable error to the channel.
go func() { errChan Followed by a blocking select:
select { case err := Something along these lines.
Re: Go Developer Survey 2022 Q2 Results
#79It's a pity that there is few progress in http3 or support for Linux KTLS.
Might 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 (page 9)
Re: Go Developer Survey 2022 Q2 Results
#80I 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.
What kinds of inconsistencies are on your mind?
I 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().