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

41–50 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#41

Post by pdimitar »

H1Supreme wrote: post #26
icy wrote: post #13

Earlier quoted context omitted.

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.

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

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

Re: Go Developer Survey 2022 Q2 Results

#42

Post by eikenberry »

pipe_connector wrote: post #14
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…

> 1) Syntactic sugar for if err != nil { return err }; similar to ? in Rust

IMO they could exactly use what you wrote, ie. change gofmt to have it all on one line like that. The biggest annoyance with the error return boilerplate is the waste of vertical space and just squashing it into 1 line would fix that.

Re: Go Developer Survey 2022 Q2 Results

#43

Post by bheadmaster »

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…

> 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?

Re: Go Developer Survey 2022 Q2 Results

#44

Post by biomcgary »

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.

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

Re: Go Developer Survey 2022 Q2 Results

#46

Post by bheadmaster »

bragr wrote: post #10
verdverm wrote: post #4

Earlier quoted context omitted.

What 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

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.

Re: Go Developer Survey 2022 Q2 Results

#47

Post by nappy-doo »

melony wrote: post #9

My 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?

Re: Go Developer Survey 2022 Q2 Results

#48

Post by [deleted] »

icy wrote: post #13
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.

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#49

Post by beltsazar »

kbd wrote: post #24

Surprised 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!

Selection bias. Those who are dissatisfied with Go either have abandoned using Go or—if they have to use it at work—wouldn't bother to participate in the survey.
Post reply on HN