Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Developer Survey 2022 Q2 Results

go.dev

Post reply on HN
Print view View original

11–20 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#11

Post by numbsafari »

mfer wrote: post #3

I wish they would ask what makes it difficult to work with dependencies in Go.

I agree with the sibling: go dependencies generally work exactly they way I want them to, and I find it very refreshing relative to other ecosystems.

My guess is that folks coming from those other ecosystems are frustrated that it doesn't work exactly like NPM, which is the general model other ecosystems have decided to follow, despite it being unstable and insecure by design.

Internally, we use a build tool called Please that is very similar to Bazel. We have some internal tooling to automate the generation of third-party dependency boilerplate needed by the build tool. The go dependency tooling actually made this reasonably straightforward and super efficient to accomplish relative to other dependency managemers. If you are in a setup where you aren't working with multiple languages or complex builds, and can just use the raw go tooling to build... the story is even easier.

Would be interesting to hear of specific pain points that others face.

Re: Go Developer Survey 2022 Q2 Results

#12

Post by klabb3 »

ptsneves wrote: post #6
tapanjk wrote: post #2

TLDR (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.

Error 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.

> 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".

Re: Go Developer Survey 2022 Q2 Results

#13

Post by icy »

awb wrote: post #8

As 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.

I 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.

Re: Go Developer Survey 2022 Q2 Results

#14

Post by pipe_connector »

aniforprez wrote: post #5

I'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…

If 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.

Re: Go Developer Survey 2022 Q2 Results

#15

Post by loosescrews »

awb wrote: post #8

As 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.

As a recruiter, which languages seemed the most valuable to startups?

Re: Go Developer Survey 2022 Q2 Results

#17

Post by klodolph »

aniforprez wrote: post #5

I'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…

I would love to see some in-depth discussion about this. Even in 2022, I don't think it's clear what we want error handling to look like. You can ask for correctness guarantees from the compiler, but it's easy to ask, it's harder to design a system that actually works.

> 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).

I would love to see how this is supposed to work.

My first thought here is checked exceptions in Java. With checked exceptions, you have a specific set of exceptions that a function is supposed to generate, and a compile-time error if those exceptions are not either handled or propagated. This turned out to be a bit of a disaster in actual practice, and I'm not sure what the fix would look like here.

I'm generally a bit miserable when I try to deal with error handling in Rust, believe it or not.

As for the err != nil boilerplate, I've seen some proposals but I haven't seen anything that was clearly a good proposal. The generics proposal was clearly good, IMO, just for a point of reference.

Re: Go Developer Survey 2022 Q2 Results

#20

Post by awb »

loosescrews wrote: post #15
awb wrote: post #8

As 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.

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.

Post reply on HN