The supported versions of Vim/GVim are most effectively summarised by the Travis build matrix:

https://github.com/govim/govim/blob/main/.travis.yml

Other combinations of Vim and Go may work.

For advice on building Vim from source, see here

Neovim is not yet supported; see #121 for discussion about potentially adding such support.

Assuming you have the plugin installed correctly, a minimal .vimrc is shown in:

https://github.com/govim/govim/blob/main/cmd/govim/config/minimal.vimrc

govim is a Vim8 plugin like any other. In that respect it should work with any other Vim8 plugin, unless there is a clash in terms of the functionality/approach between the two. We maintain a WIP list of any known clashes here:

• Valloric/YouCompleteMe - both share the same goal of providing language features like auto complete, go to definition, find all references etc. Hence, per this exchange, govim and YCM should not be used together. #202 tracks documenting how to achieve .-initiated completions

This question and the one that follows are also covered in two talks I gave, YouTube recordings of which are available: London Gophers and Vim London.

Firstly, I would like to acknowledge all the work that @fatih, @bhcleek and contributors have put into vim-go. It's a phenomenal effort.

Secondly, some history. vim-go predates the channel support in Vim8. As such the way it emerged and evolved is very much a function of the world that existed back in 2014.

With that said, there is absolutely nothing wrong with vim-go! Indeed, vim-go is also using gopls for some commands/functionality.

github.com/govim/govim/cmd/govim is an experiment. It's an experiment that is looking to test the hypothesis that writing Vim plugins in Go (to support developing in Go):

• will make for more readable/maintainable code
• will enable more people to contribute
• will allow common, intuitive, easy-to-understand building blocks to be created using Go primitives as opposed to VimScript primitives. i.e. we could provide a Go function/method that gets the current buffer contents rather than relying on knowledge that we need to evaluate the expression join(getline(0, "$"), "\n")
• will, over time, allow a more usable API to establish itself
• will allow for the use of existing developing tooling whilst working on github.com/govim/govim/cmd/govim (or any plugin that is build using github.com/govim/govim for that matter)

Building on the answer above, govim was started as an experiment to test whether writing Vim8 plugins in Go would be easier, more fun etc. This answer adds my current (2019-04-18) personal (myitcv) thoughts. Note however that I'm very willing to be steered in a different direction on any of these points and more!

• I focussed on gopls (and by extension, Go) in order to help quickly iterate on progress in gopls. Hence my goal was/is not "I don't want to support other languages/LSP implementations, ever"; rather, "I'm currently focussing on gopls"
• there is therefore no particular reason to prefer it over vim-go, vim-lsp, coc.nvim or any of the other related projects. vim-go at least is far more mature in terms of code life. I've not tried vim-lsp with gopls
• one major reason to consider using govim is if you want to write Vim plugins in Go or simply extend govim. For example, it was trivial to add the GOVIMStringFn command to govim. GOVIMStringFn allows you to call Go standard library string/[]byte/similar functions on text in your buffer, for example you can call strconv.Quote, or regexp.QuoteMeta. Similarly, the addition of the GOVIMMotion function, which allows the user to define motions relative to the AST representation of the buffer, was easy and efficient.
• whilst there are (large) parts of govim that are language agnostic (because all its doing is talking LSP to gopls), having my stated goal be that govim is Go-specific (for now) feels like the most efficient way to iterate on the progress being made with gopls but also to flush out whether there are any Go-specific bits where the LSP spec itself needs to change. Making govim (or some derivative of it) language agnostic is being tracked in https://github.com/govim/govim/issues/194, but again, this not my primary goal right now

At least one person (me!) is using it 100% of the time, as a direct replacement for vim-go. Yes there are rough edges, but it's easy(ish) to iron out those rough edges, and the speed benefits of gopls make it vastly preferable.