Hacker News new | ask | show | jobs
by farslan 2652 days ago
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.

1 comments

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.