It's interesting that 17% are not satisfied with editor support for Go. The biggest editor feature requests were for code completion and navigating code.
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.
> It's interesting that 17% are not satisfied with editor support for Go.
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.
I have had issues with the recent go plugin for VSCode too. The new version is unreliable and the language server needs a reboot fairly often. It is a real pain because when it breaks it often shows a compile error that you end up scratching your head over and a simple restart of the editor will often fix it. It definitely wastes time and needs addressing soon.
> Rather than editors being at fault, could these indicate that Go is a bit too verbose?
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 think code completion is for “I want a list of properties or methods available for this function” and not “I don’t want to have to type the next few characters”.
My code completion is actually quite decent, and my editor is vim. Under the hood, gopls takes care of the heavy lifting. It can be memory hungry (I note it taking up half my freaking ram on my 64G machine, though the codebase it's working with is quite large)
e followed by down and enter produces the following for me, its downright essential snippet code to be on a single character entry for golang:
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.
I just want to see f(g(x), h(y)). I’m hoping for an editor that both generates and hides the twelve lines of noise that call g, handle an error, call h, handle an error, call f, and handle an error. I don’t want to write or review that for the same reason that stack frame setup just happens in code that nobody writes or reviews.
We could generate Go from some other language, but I can’t assume any team will buy into that.
I feel this way when writing business logic RPC services, because returning the error to the caller is almost always what you want to do.
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.
I agree it this needs to happen. Right now about all you can do is snippet your way through it, it is an incredibly common scenario that go handles really poorly.
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.
Sublime text used to have a pretty decent Go plugin, but the repository looks abandoned. VSCode has an ok plugin I'm not really a big fan of the editor itself. Outside of that, there's the Jetbrains Goland editor which looks decent but I'm not going to pay for.
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.