The main thing that annoys me about Go modules is that it broke so much tooling. I still can't get GoCode to work properly, and there are 4 or 5 different forks of the repo all trying to add module support, its a mess.
The VSCode go plugin team has been doing a good job of staying on-top of this[0]. Which points to a golang bug[1] where the Go team is tracking tooling programs that need to be updated for Go Modules. So the Go team is aware of this issue and people are working to get all the major tools on board.
This hasn't been my experience. VSCode still regularly fails to resolve dependencies for me. Usually it's because I added a go.mod after opening VSCode and I just need to restart the latter, but sometimes even that doesn't work. Hard to say exactly what the cause is since debugging VSCode is quite difficult (or maybe I'm just looking in the wrong places).
This is now mostly fixed with "gopls". It's using go/packages under the hood which is both GOPATH and Go modules aware. gopls has also caching inbuilt, both code completion and jump to definition works very well.
If you're using vim-go, HEAD has now gopls support. I believe vscode also added recently support for gopls.
Other than, I agree that it broke all other tools, but most of them are migrated to use the go/packages package so it'll be better going forward.
It's not really fixed though. When using vim-go with gopls, I see extortionate memory and CPU usage relative to what gocode used to use, and glacial lookup times compared to what gocode used to offer. Maybe it's perfectly adequate for you, and if so that's great! But that has not been my experience. Neither gopls nor any of the dozen forks of gocode I've tried since 1.11 has come close to the pre-modules experience for speed, accuracy and acceptable resource usage.
I tried to use the profiling flags to get some data to file reports, but ran out of yak-shaving time when I realised was trying to flush out a bug in the tool command helpers in golang/go where it would write empty profiles if the process was shut down the exact way vim was shutting it down. That may have been fixed since, I haven't had a chance to look back into it.
Gocode works in vim but for some reason won't do autocomplete in spacemac's go-mode. I haven't found the time to look for a fix yet. There's a fork of Gocode that fixes it, but makes vim's autocomplete very very slow. As someone who switches between vim and emacs I wish this mess gets sorted out soon!
I have been using https://github.com/stamblerre/gocode with company-mode in Emacs. It mostly works. (The limitation with gocode, it seems, is that your file has to be saved and the package you want to complete from has to be listed in the imports list in order for it to do anything. Not sure if that is what is broken with modules, or just how it is. I started using gocode after I started using modules.)
[0] https://github.com/Microsoft/vscode-go/wiki/Go-modules-suppo...
[1] https://github.com/golang/go/issues/24661