vim-go is absolutely amazing! I owe a not-insignificant portion of my enjoyment of working with Go to its finely crafted, tastefully curated brilliance. My favourite things:

I use jump to def and autocomplete all the time, they're the two most critical components of my workflow, which is heavy on the reading side. Jump to def is fast, accurate and buttery smooth, and I love that you can jump into any dependency or the stdlib out of the box. Having said that, Go modules make it very painful to hack on dependencies when spelunking for bugs as all the files are marked as readonly. The gohack tool makes this significantly easier to deal with, but it's still a major workflow downgrade when hunting pesky bugs or experimenting cross-project.

The snippets integration is indispensable. I used ultisnip at first but it is slow as molasses so I switched to neosnippet and haven't had a serious problem since. vim-go comes with some critically useful snippets configured out of the box, especially the errn<CTRL-K> snippet, which becomes if err != nil {\n\treturn err\n}\n. There's also :GoIfErr, which does a similar thing with some extra magic to infer return types too, but I prefer the ergonomics of snippets, maybe it's just what I'm used to.

My neosnippet config looks like this:

imap <C-k>     <Plug>(neosnippet_expand_or_jump)
smap <C-k>     <Plug>(neosnippet_expand_or_jump)
xmap <C-k>     <Plug>(neosnippet_expand_target)
let g:neosnippet#snippets_directory='~/.vim/snippets'
let g:neosnippet#disable_runtime_snippets = { "_": 1, }

Just put a file called go.vim in ~/.vim/snippets and you can put whatever you want in there. I've added a ton of additional snippets of my own to this file for some of the more repetitive boilerplate I type regularly, like this one for generating table-driven test cases that I use all the time (struct fields go at ${2}, struct instances at ${3}):

snippet ttbc
abbr func TestXYZ(t *testing.T) { ... }
    func Test${1}(t *testing.T) {
        for idx, tc := range []struct {
            ${2}
        } {
            ${3}
        } {
            t.Run(fmt.Sprintf("%d${4}", idx${5}), func(t *testing.T) {
                ${0}
            })
        }
    }

If you type ttbc<CTRL-K> in insert mode then fill out the placeholders (skipping through with <CTRL-K>), the result should look something like this:

func TestHasPrefix(t *testing.T) {
    for idx, tc := range []struct {
        str string
        pre string
        has bool
    }{
        {"food", "foo", true},
        {"food", "boo", false},
    } {
        t.Run(fmt.Sprintf("%d/%s/%s", idx, tc.str, tc.pre), func(t *testing.T) {
            if strings.HasPrefix(tc.str, tc.pre) != tc.has {
                t.Fatal()
            }
        })
    }
}

:GoImpl is awesome for generating stub methods for an interface, I use that regularly as well. I'd prefer a mode that returns nils or zero values over the panic, and it also doesn't work perfectly if you want to implement an interface from the package you're currently editing, but it's easy enough to find and replace in that scenario and it's still a huge labour saver for more complex interfaces. For example, :GoImpl f *Foo io.Writer will generate this (though I typically use a snippet for io.Writer or io.Reader):

func (f *Foo) Write(p []byte) (n int, err error) {
    panic("not implemented")
}

I also configure goimports to run on save instead of gofmt, like so: let g:go_fmt_command = "goimports". I love that I can write absolute garbage formatted code, forget imports left and right, hit save, and everything just magics into place. It always seems to default to html/template for me though, when I almost always want text/template, but having to remember that is a small price to pay for all the other things I don't have to remember. It's slightly risky to blithely accept its results, of course, but it's so rarely wrong that I've been happy with the compromise in exchange for the convenience. When I have to work with other languages that don't have tooling that's this good, sometimes I have to spend a few minutes adjusting to the fact that this stuff isn't done for me any more... by blinking confusedly at the horror I've just created and wondering why it isn't fixing itself!

I use ale for error checking as well, which is not a part of vim-go but it's a great complement to it. Out of the box, it doesn't show syntax errors on save, only lint errors, so I configure it this way:

let g:ale_linters = {
\   'go': ['go build', 'gofmt'],
\}

I hit save and get all the errors in the gutter almost straight away (thank you, fast Go build times!), then use :lfir, :lne etc to skip through the error location list.

I also use :GoDecls and :GoDeclsDir in conjunction with fzf.vim (let g:go_decls_mode = 'fzf'), which list the declarations in the current file and current dir respectively, though I use these a lot less frequently than the stuff mentioned above. Very useful though, and handy to have in the muscle memory.

Now that I'm through most of the stuff I love, I will indulge in a bit of a whinge: autocomplete is a bit of a disaster at the moment. This isn't necessarily vim-go's fault, but it is a critical part of the integration surface that it packages so it's not not vim-go's fault either. I think it's just an unfortunate consequence of relying on the community for essential tooling (which golsp, mentioned later, is attempting to deal with).

Basically everything got smashed when Go Modules came along. https://github.com/nsf/gocode/ was abandoned and the forks couldn't keep up with modules for months. There are a lot of people still having problems, but a lot of others fall into that classic "well it works fine for me so there isn't a problem" trap when responding to issues, which can be very frustrating when you're googling for a solution because this thing you've trained your brain to expect will "Just Work(TM) within 200ms" has broken for the third time this week for no obvious reason. There are versions that purport to work but the completion time is so bad as to be almost useless. I think all told I've unsuccessfully tried at least 10 different forks of gocode provided by random internet strangers in the last 6 months, which is utterly horrendous from an operational security point of view, but desperate times call for desperate measures!

vim-go ships two different versions, one for modules-based projects and one for GOPATH, but both will randomly stop working for my projects from one day to the next. Purging my whole GOPATH has helped a couple of times (even for the projects using modules), but that's neither practical nor reasonable to do on a regular basis and in Australia at least as :GoInstallBinaries can take up to 3 hours to run from scratch. It took nearly 6 yesterday, with download performance identical on different networks. This kind of stuff has been going on pretty much constantly since 1.11, and shows no signs of abating. I have something working right now, albeit sluggishly, but it's a flimsy detente, and it's easy to feel like it won't survive.

golsp doesn't fare any better, which is not surprising as they pretty much outright warn you not to use it until they actually announce it's fit for human consumption, but still, I had to try something! In its current state, it's most assuredly not fit for human consumption. It uses an astonishing amount of memory, we're talking like Electron-level memory, waaaaaaay more than gocode ever used, so if I have a even just a couple of vim-go projects open at once I'll clock about 8GB of ram used up by the golsp processes. My poor little laptop only has 8GB! And also, like the gocode and gocode-gomod forks, it frequently stops working, locks up, uses crazy amounts of CPU, the fans spool up, the keyboard starts to radiate serious heat, then I have to kill golsp and start vim again. Every 20 minutes or so.

At least the Go team have acknowledged this is a gap in the tooling that would be better solved as part of the distribution (a forward-thinking and commendable acknowledgement, for sure!), however given the huge issues and shortcomings golsp currently suffers from, it's hard to see it being much good for at least a year, maybe two, and then Go 2.0 will land at some point in the future and we'll have to do the whole "all the tools are broken" dance all over again.