Gocode completely doesn't work since version golang 1.10

[monoflash]

Gocode completely doesn't work since version golang 1.10.
The utility does not return anything after updating golang.
If roll back golang to version 9, then everything starts working again.
:(

[nsf]

Might help: #500

tl;dr: Go has package cache now, with 1.10 you can with hacks make gocode work, but in the long term who knows what happens next. Start looking for alternatives or hope and pray that I'll end up writing next version of the gocode relatively soon (probably it will have a different name).

[kovetskiy]

@nsf if you are going to write new version of gocode that will work with source code (instead of package cache), can we cooperate on this task? I don't really want to do it alone and maintain it for years, but it could be easier if several developers would work on that task at the same time.

[nsf]

@kovetskiy no, due to unpredictable schedule I don't see how it's possible. I might be coding it every day for a week and then doing zero progress for a few weeks, etc. That's just how open source works. there is nothing to colaborate over until there is a major codebase written and ready. Next gocode will be most likely called "gls" which stands for Go Language Server or Service. It will most likely implement the langauge server protocol by sourcegraph. E.g. similar to: https://github.com/sourcegraph/go-langserver. But having a compatibility mode in mind if possible for existing gocode text editor integrations. What I want is to take full advantage of this protocol and implement everything starting from syntax/semantic checks, goto, "codelense", find usages of, autocompletion, quick fixes, etc. It's a lot of work, but it needs to be done this way and no other way is acceptable. Proper and full source language server protocol implementation.

P.S. If you don't want to maintain it, then don't do it at all.

[kovetskiy]

@nsf I mean that I don't want to maintain it if I would be alone as you do with gocode. That's the difference.

[nsf]

Well, listen, when and if I have some code to show, then we can talk about collaboration. It's pointless to collaborate over something that doesn't even exist yet. I don't know how it will look, what kind of libs it will use, what it will do exactly, etc. And I don't want to discuss those details either.

[kovetskiy]

@nsf ok, no problem, just ping me if I have a chance to help you with any related issue. I will be glad to make a contribution.

[mdempsky]

FYI, I just added a -source flag to mdempsky/gocode to make it generate suggestions from source, instead of from compiled package definitions.

Caveat: the main branch of mdempsky/gocode doesn't implement any caching. For compiled imports, this is moderately slower (but IMO still acceptable for interactive use, ~200ms in large packages), but source imports are substantially slower (~1.5s for each completion, even in small packages).

I've prototyped caching in the cache branch. It's currently for compiled packages only (and standard cmd/go workspaces; no gb support), but it brings performance on par with nsf/gocode: ~30ms to ~40ms when cached.

I'd really like to implement this functionality directly into a langserver implementation so that it can make use of langserver's VFS functionality.

[nsf]

Added a link to "mdempsky/gocode" to README.md. Hopefully @mdempsky, you don't mind.

[nsf]

Although I understand that you don't have a magic fix for "package cache" problem yet. The chance that you'll have one is much higher than on my end. The "-source" flag thing looks interesting.

[nsf]

Sorry for message spam, but to clarify a bit what I think here. Basically in short term if new Go binary packaging changes affect you (e.g. you don't use alternative build tools such as https://getgb.io, also I don't want to say that I recommend it, it just happened this way that I'm stuck with it), then consider looking at @mdempsky fork of gocode. Since that fork can parse source files already for imported packages, maybe it will get proper caching as well sooner or later which will make it also not as slow as it is right now. This (my) repo however will probably never get those "package cache" workarounds.

In long term - we need better tools for Go ecosystem. I was writing a bit of typescript recently, I'm very happy how their language service protocol integration works with vscode. We need something like that, but preferrably faster (at least as much as it depends on language service itself). I know some people do some stuff, other people do other stuff. I'm working on something as well, but it's very early to announce anything.

[mdempsky]

@nsf Thank you for the link. I don't mind.

[localvar]

@mdempsky , I implement a source caching based on your master branch, at localvar/gocode. I hope I could send a PR to you, but seems too difficult for me to do everything right, though I think it works in most cases.

the current issue is memory consumption, need find out a way to avoid duplicated packages

the above issue should be fixed by implementing a new importer, most of the code is copied from go/internal/srcimporter, the major change is moving package cache from instance level to global to allow the reuse of already parsed packages.

because context (GOOS, GOARCH and etc.) is specified in every completion call, it is possible that the cached packages are in different contexts, this may lead to wrong suggestion result. but I don't think context changes frequently, so this should not be a big problem.