31–40 of 186 posts
I 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.
Earlier 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`?
I guess what he is saying is that x, _ := someFunc() shouldn't compile if someFunc has error returns.
Earlier 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`?
I guess what he is saying is that x, _ := someFunc() shouldn't compile if someFunc has error returns.
There's no point being more particular about it... there's no practical way to force a programmer to handle an error, especially in light of the fact that "do nothing with the error" is also a perfectly acceptable thing to do! (Example: Writing a JSON document out as the result of an HTTP API call. I don't want to log every such error, because that just crufts up my logs, I don't need metrics on this particular system, and once the HTTP stream is broken there's nowhere left to write an error out to the user, so... discard it is.)
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.
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...
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.
There are plenty of companies interested, many of them startups. I don't think anyone with a strong Go background looking for a job right now would have any trouble at all.
Earlier quoted context omitted.
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 l…
> Yes I didn't want to make the tired comparisons to Rust but Rust does have the excellent syntactic sugar for returning errors.
Many people seem to forget that Rust didn't start (even in its 1.0 release) with the ? operator. It started with the try!() macro, which expanded to something not unlike Go's "if err != nil { return err }". The ? operator was added later, as a shortcut to the same semantics as the macro except for also being able to work with Option instead of just Result, based on developer experience with the macro (the two major annoyances being not being able to use the macro with Option, and the nesting when chaining several uses of the macro).
If Rust was able to create the ? operator based on developer experience with its try!() macro, I don't see why Go won't be able to create its own error propagation operator based on developer experience with its "if err != nil { return err }" idioms.
Haskell, Rust, Ocaml, F#, Elm > Scala, Kotlin, Swift > Go > Java, C#, C++, C > Clojure, Lisp, Elixir > JavaScript, Python, Ruby, R, Php, Perl
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!
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.
But first, fix your gopath
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`?
x, err := thisFuncFails();
// some other lines of code, but err is not checked
x.callMethod(); // this crashes at runtime