Rather than editors being at fault, could these indicate that Go is a bit too verbose? I wonder if generic functions will affect this. I rarely write Go, but I can imagine autocompletion macros for `err != ...` could help.
Rather than editors being at fault, could these indicate that Go is a bit too verbose? I wonder if generic functions will affect this. I rarely write Go, but I can imagine autocompletion macros for `err != ...` could help.
GoLand does a better job and is more stable and reliable than VSCode here, even having to restart the daemon from time to time for VSCode. Of course it could also be what you said, I can only write for myself. I hope they will be able to introduce stability and reliability of the former.
No, I think it’s just that the Go language server, last I used it, had lots of trouble dealing with completion for code that lives in another module. GoLand did much better in this regard, but I suspect it’s not used nearly as much as VSCode, hence the response.
I wonder what everyone else is doing.
if err != nil { return |, err }
I can't believe how much I need this, on the one hand I love how error handling is explicit, but also the amount of times I handle an error and just pass it means the above code is used a lot.
We could generate Go from some other language, but I can’t assume any team will buy into that.
Recently I wrote something very different, more low level. Rather than handlers it had a number of goroutines looping, selecting, and sending to channels. In this case explicit errors were a lot more useful. If it had been a language with exceptions and I had forgotten a try/catch, it could have killed one of my loops. Not good!
This is the kind of use case that fits well for Go. I think it’s a systems glue language that just happens to be friendly enough to invite abuse in mundane backend business logic tasks. But using it that way is setting yourself up for frustration.
Java's Checked Exceptions was less invasive and API polluting than this is because at least it didn't get in the way of these types of calls where the error should just shortcut. More importantly in Java you could hide the errors behind a generic RuntimeException if from that point up there was nothing anything could do but generically deal with the error. Panic/Recover is similar but very discouraged for this sort of usage pattern.