Feedback needed: ok to drop support for Go in favour of vim-go?

[lcd047]

The problem:

• The official Go compiler doesn't support syntax checking. Consequently, the go checker in syntastic needs to run full builds to do its job. This is problematic in many ways: it's slow, it doesn't adapt well to checking single files (cf. Compiling Conditional Go files #1727), produces spurious object files that are hard to be dealt with (cf. go checker fails - go build -o /dev/null because /dev/null exists & isn't an object file #1436), it complicates handling tests, and generally doesn't fit well with syntastic's model of a checker.
• On the other hand, the vim-go plugin is already popular among people that write Go code, doesn't have any of the above issues, and can do everything syntastic's checkers go, gofmt, golint, gometalinter, gotype, and govet can do, only better. It has a lot more features than syntastic. It's specifically designed to work with Go, while syntatic is a little more than a general framework.
• Recent changes in vim-go make it problematic for syntastic to work along with vim-go in the most common configurations (cf. vim-go uses location lists now #1650).
• Syntastic's defaults also seem to be a continuing source of problems for vim-go (cf. this thread).
• vim-go's maintainer doesn't use (nor is particularly interested in) syntastic, and syntastic's current maintainer (i.e. yours truly) doesn't use (nor is particularly interested in) either Go, or vim-go. This makes it problematic to find solutions to reduce frictions between the two plugins.
• vim-go already can be configured to show an interface similar to syntastic's (f.i. it has quickfix windows).

Proposed solutions:

• Drop Go-related checkers from syntastic: go, gofmt, golint, gometalinter, gotype, and govet, and tell people to use vim-go instead. Since vim-go can already do a lot more than syntastic, this shouldn't be a huge loss for anybody. Of course, any of these checkers can still be maintained externally if anybody cares to adopt it.
• Alternatively, replace syntastic's checkers for Go with shims that call vim-go's functions. This would be less than trivial, it would take a while to implement (actually I can't guarantee I can manage to summon enough motivation to do it), and it would make syntastic dependant on vim-go's internals. It would allow people to keep using syntastic's interface though.

Does anybody have any strong feelings one way or another? Any other opinions? Other suggestions?

[lcd047]

@jackcohen The go checker already runs gofmt. Anyway, the point of this thread is to decide whether it's ok to drop support for Go from syntastic, rather than how to improve the go checker.

[osleg]

I would suggest, if vim have means for that, to check for vim-go installed
and disable checkers if it does.

If this is impossible than maybe just leave the checkers disabled by
default since most of go developers I know using vim-go by default, though
me for example keeping the syntastic checkers in passive mode and use them
from time to time since they provide, sometimes, better results.

[lcd047]

@osleg Syntastic checking for vim-go would be problematic at best, since it would be run "too early" and the results would be unreliable.

Disabling checkers on the other hand might work as far as vim-go is concerned, but doing that would still leave me with a bunch of not-so-great scripts to maintain. Worse, almost nobody would care about them either. Syntastic is becoming increasingly irrelevant as a checker for the mainstream languages these days, mostly because it can't run checks asynchronously, and because the competing specialised checkers such as YCM and neomake are getting really good. Of course, this will eventually leave me a curator of a ghost museum of tiny, useless Vim scripts. :) (How nice. Looking forward to that day.)

Thus I'd still prefer to kill these checkers for good. But disabling them should do for now: f280ff2.

[osleg]

Well in that case it seems like the best decision would be just to
submodule go checkers and make it optional, I guess people who need it will
update is if required :) (Maybe even I will if something will be broken)

[fatih]

Another idea would be using a type checker directly:

https://godoc.org/golang.org/x/tools/cmd/gotype

This is much more faster and maybe it would some of the problems people have with the speed.

[lcd047]

@osleg There is no need to submodule anything, syntastic already has the mechanism of external modules. If you want to adopt some (or all) of the existing Go checkers all you need to do is create a plugin as described in the docs. I'd then remove the checkers from syntastic and add a link to your plugin from the README.

@fatih My problem is not that the go checker is slow. My problem is that the Go checkers collectively generate a lot of spurious (and generally unpleasant) interaction with people that use vim-go. That can and should be avoided. With commit f280ff2 I mentioned above syntastic no longer runs any checks for Go by default. People can still enable the checkers by adding them to the syntastic_go_checkers list, but they'll have to do it explicitly, and they'll (hopefully) have to read the manual in order to find out how to do that. But the point is, it would no longer happen by default. This should take some reports off your back (and mine), at least once people start upgrading syntastic to a version that includes the relevant commit.

Now, as I said above, I'd still prefer to get rid of these checkers. Having them adopted by somebody who cares about them would be the preferred solution, of course, but realistically, simply deleting them shouldn't bother too many people either. That part has nothing to do with vim-go though (unless you want to adopt the checkers yourself, that is).

[osleg]

@fatih the main problem with vim-go+syntastic for me was that they fight
for loclist. I tried to make vim-go to work with quickfix instead but it
didn't auto open in it on errors. So I just made vim-go checking with vet
only and left syntastic binded to a key for full build check to see compile
errors. Basically I enjoy both worlds :)

@lcd047 knowing myself I won't be good maintainer ;)

[andrei-m]

I've been using syntastic + vim-go for about a year together. Syntastic's error signs on margins are a wonderful feature vim-go does not have available. The immediate visual feedback this provides is great for users who haven't mastered location lists and associated navigation in Vim.

That said, the location list workflow in vim-go (without Syntastic) is probably good enough to fill the need; it's just a bit of a more onerous learning curve.

[pdf]

I use vim-go with go_metalinter_autosave disabled and use gometalinter via syntastic instead - the visual feedback is really useful. I'd really like for either the current Go support to stick around, or for the calls to be shimmed out to vim-go, so that we still get the syntastic front-end. I will say that checkers other than gometalinter are probably redundant.

[lcd047]

@pdf If somebody who actually uses vim-go can provide some dictionary between internal vim-go functions and the existing syntastic checkers, I might consider adding such shims.

[pdf]

@lcd047 VimScript is not a thing I'm particularly comfortable with, can you describe what that would look like?

[lcd047]

@pdf Each syntastic checker runs an external program with a set of arguments, and gets back a loclist populated with error items. I presume vim-go has specific functions for getting the same loclists.

[pdf]

@lcd047 if I understand how loclists work based on a quick read of the code, there would be some (relatively minor I think) refactoring involved to be able to return the lists directly. Probably needs some input from @fatih as to whether he'd be interested in taking the changes, and accepting the API dependence.

[majewsky]

Since feedback is wanted: Please don't drop the golang syntax checkers. I love how Syntastic gives me an easy way to run gofmt and golint automatically, without installing that operating system of a plugin called vim-go. I'll admit that Syntastic is also a large plugin, but at least it works for almost every language under the sun whereas vim-go only works for Go.

I'm personally okay with removing the "go" syntax checker, though. It's broken anyway in Go 1.7, and I don't see any benefit in it over the "gofmt" checker. I have let g:syntastic_go_checkers = [ 'gofmt', 'golint' ] and these checkers work wonderfully.

[bradleyfalzon]

@majewsky what's broken about the go checker in 1.7? let g:syntastic_go_checkers = ['go', 'govet'] works for me

[majewsky]

@bradleyfalzon Errors and warnings are displayed when the source file is opened (g:syntastic_check_on_open), but vanish after saving. I actually came here to report this as an issue, but this issue caught my attention and I forgot. Should I open a bug? Is it worth the effort?

(By the way, I'm actually on Go 1.7.1. Don't know if the .1 makes a difference.)

[lcd047]

Errors and warnings are displayed when the source file is opened

@majewsky This is completely unrelated to any particular checker, and it probably has to do with recent changes in Vim and in syntastic. Can you still reproduce the problem with the latest master HEAD? If you can, please open a new issue.

[majewsky]

@lcd047 It is definitely related to the particular checker. No other checker I tested had that problem. However, I have trouble producing a minimal example, so the bug is probably related to the concrete repo I was working on in some way. In any case, I don't want to derail this discussion. If I happen to be able to reproduce the bug after all, I'll make another issue.

[lcd047]

@majewsky Well as far as I can tell syntastic only cares about the result from checkers, nothing else. Errors show up when you open a file, so the go checker is actually working. The errors "vanish" when saving a file, so something gets in the way of syntastic's autocmd. That something might be another plugin, the new behaviour of QuickFixCmd* in Vim, my latest fumbling with the autocmd logic, or something else entirely. Since the problem it's only triggered by the go checker, I'd try looking at your other go-related plugins first. Then again, I only wrote the code involved, so what do I know. Maybe your line of thought is closer to the truth. shrug

Back to the initial topic: if you guys want the go checker removed, either because it's broken or for whatever other reason, please let me know.

[bradleyfalzon]

@lcd047 syntastic + vim-go + go checkers works well for me, please keep it in for others to use too and thank you for the initial support - I know lots of people that also use it, and do think enabling by default is a useful feature.

[lcd047]

@bradleyfalzon The thread at vim-go that I linked above shows that having the go checker enabled by default would only result in more friction. shrug

[mrtazz]

I'd hate to lose go support in syntastic. I use a bunch of different languages throughout my day of which Go is only one and I'm heavily relying on syntastic to run checkers on any given filetype. I'm not using vim-go for my go setup but rather have a very limited set of things I just enable (https://github.com/mrtazz/vim-tinygo), as I found it difficult to make vim-go work in a way that kept vim fast and usable for me, which is mostly due to my peculiarities.

I can absolutely understand not wanting to continuously work on incompatibilities. Syntastic is gonna continue to be a rock solid foundation for my programming. And vim-go is a fantastic plugin that does a great job. However if deprecating built in Go support frees up time for both maintainers to focus on making their respective plugins better, I think that's worth it. This is mostly to give some feedback, I'm pretty sure there will be an external checker quickly which I'd use then.

Thank you for being awesome maintainers @lcd047 and @fatih

[lukateras]

@lcd047 I hope you'll reconsider. I rely on the built-in go checker.

Sure, it is kind of slow, but so is javac checker (the latter is much slower to the point of unusability). Actually, no checker is fast enough, it is the synchronous model that is flawed. Considering #699 will fix this (Vim 8.0 finally offers a way to do it), and go checker will become asynchronous, most of the problems users experience with this checker won't matter anymore.

I actually didn't know there was a problem with go checker until I updated to 3.8.0 (see f280ff2). Honestly, I didn't expect a minor version to contain a breaking change (it wasn't even listed in the changelog).

Syntastic is the only Vim plugin I've installed, while Go is just one of many languages I use. I rely on the fact that I don't have to configure Syntastic for each particular tool I'm working with.

I love how Syntastic offers me a consistent, streamlined syntax checking solution without having me to download a clusterfuck of plugins like vim-go. Syntastic generally just works, and it is a tremendously important feature. Each plugin, each piece of software is a potential source of problems, like one I have right now with Syntastic. Things break and change. It means I'll have to follow news about whatever I have installed, and I don't have time for that. I just want everything to work.

Consider this line from vim-go README:

Go (golang) support for Vim, which comes with pre-defined sensible settings (like auto gofmt on save) [...]

I don't believe that is a sensible default at all. I may have added a package just for one build (like log package), and go fmt will sort packages inside import statement in alphabetical order on save, thus moving it into the middle of the list, which adds a lot of cognitive load and indirect implicit behavior, something actually contradicting the philosophy behind Go (particularly, the idea that explicit is better than implicit, which is seen throughout all features in Go language design, e.g. error handling).

And actually, I don't need 95% of the stuff they provide, and the 5% I need is not enabled by default.

I'll need to opt-out from stuff that is enabled by default, and add several lines to my vimrc. But first I'll need to figure out what implicit behaviours it actually has. Then, I'll need to enable things I do need and make it behave like Syntastic, but not quite, with another few lines. All of it instead of just installing Syntastic in one line and solving the problem altogether, forever, without searching for anything else ever again.

Another thing I like in Syntastic is that there is not much to be broken. Surface area for error is relatively small, in comparison to, say, vim-go. Basically most stuff in the repo is just the glue to make production-quality tools work with Vim.

I've rolled back to 3.7.0 for now.

[lcd047]

I've rolled back to 3.7.0 for now.

@yegortimoshenko Alternatively you could just read the manual (:h syntastic-filetype-checkers) and find out how to re-enable the go checker by adding it to g:syntastic_go_checkers. FWIW.

[lukateras]

@lcd047 I know how to re-enable the checker, thanks. Not sure why you'd presume otherwise. It's just a) not a sensible default, b) I don't use any of the changes introduced in 3.8.0, c) I keep my vimrc clean, d) I hate breaking changes, especially when they are undocumented.

[lcd047]

I know how to re-enable the checker

@yegortimoshenko Then the point of your previous post was... to let us know about you sticking with 3.7.0?

It is just a) not a sensible default

The change addresses a human problem, not a techical one. shrug

[lukateras]

@lcd047 You asked for feedback, right? I told you, in detail, why removing go checker is a bad idea. I told you how harmful it is for actual user experience, and I told you that the undocumented breaking change in minor version was particularly heartbreaking, and that is actually related to the topic.

I don't understand your second point. Vim is a human-machine interface, there is no clear distinction between "human" and "technical" problems.

[lcd047]

I don't understand your second point.

@yegortimoshenko Perhaps try reading the first post in this thread from this perspective?

Anyway, I believe I did receive enough feedback to make a decision. Thank you for your input.

[lukateras]

Perhaps try reading the first post in this thread from this perspective?

@lcd047 What's with the attitude? Why would you presume that I haven't followed the discussion? Couldn't imagine that the maintainer of my single favourite Vim plugin is such an asshole.

[pdf]

@yegortimoshenko there is only one 'asshole' in this thread and it is not lcd047, please take your belligerence elsewhere.

[oblitum]

This discussion got exciting at the point it has been asked about syntastic<->vim-go mapping through a possible vim-go API, sadly that point was lost into emotional chat....

[lcd047]

@oblitum Working patches are always considered, and almost always appreciated. Sometimes even more than contributions in thread necromancing. 😄

In the mean time, given a choice, don't use syntastic for checking go files.

[oblitum]

@lcd047 haha, right, I agree.

I'm going against the advice for now (and experience, I did recall of disabling Syntastic for Go years back for similar problems). I hope that using the gofmt checker instead of the go one will avoid problems.

[oblitum]

FWIW, this is my current setup:

let g:godef_split = 0
let g:go_fmt_fail_silently = 1
let g:go_list_type = 'quickfix'
let g:syntastic_go_checkers = ['golint', 'govet', 'gometalinter', 'gofmt']
let g:syntastic_go_gometalinter_args = ['--disable-all', '--enable=errcheck']

@majewsky's tip on using gofmt checker instead of go is being useful at first because the go checker generates and leaves binaries behind, while gofmt doesn't, and for now I'm getting similar diagnostics.