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

21–30 of 186 posts

Re: Go Developer Survey 2022 Q2 Results

#21

Post by H1Supreme »

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.

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

Re: Go Developer Survey 2022 Q2 Results

#22

Post by aniforprez »

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

Re: Go Developer Survey 2022 Q2 Results

#24

Post by kbd »

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!

Re: Go Developer Survey 2022 Q2 Results

#25

Post by metaltyphoon »

H1Supreme wrote: post #21
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. 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`?

I guess what he is saying is that

x, _ := someFunc() shouldn't compile if someFunc has error returns.

Re: Go Developer Survey 2022 Q2 Results

#26

Post by H1Supreme »

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.

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.

Re: Go Developer Survey 2022 Q2 Results

#27

Post by [deleted] »

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.

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#28

Post by the_gipsy »

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!

Compiler simpleness is the reason, and in return it's fast. Still sucks, though.

Re: Go Developer Survey 2022 Q2 Results

#29

Post by [deleted] »

H1Supreme wrote: post #21
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. 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`?

[deleted]

Re: Go Developer Survey 2022 Q2 Results

#30

Post by gregwebs »

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 am quite convinced that Zig's approach to error handling would apply well to Golang. At least adding a "try" prefix would be an easy change. Add the ability to enable/disable an error return trace and that would do a good enough job handling the majority of error handling boilerplate.

    * https://ziglang.org/documentation/master/#try
    * https://ziglang.org/documentation/master/#Error-Return-Traces
I am working on adding this to the compiler now but I know of no actual process for getting such an improvement officially into the Go language.

There are several other concepts in Zig that enhance safety that Go can consider adopting. I personally prefer the soundness of Rust, but Zig is much more philosophically aligned with Go. In error handling alone, we can consider adopting a "catch" suffix as Zig has for when "try" is insufficient as well as error sets. Additionally optional types seem like they would work well in Go.

    * https://ziglang.org/documentation/master/#Optionals
    * https://ziglang.org/documentation/master/#Error-Set-Type
Post reply on HN