3 ms·

Interesting, VSCode + Go plugin got very unreliable since I switched to the language server integration. I have to restart the language server at least once a d

by dewey 7y ago

Interesting, VSCode + Go plugin got very unreliable since I switched to the language server integration. I have to restart the language server at least once a day to make autocomplete in VSCode work again. It'd probably be hard to switch as there's a bunch of other plugins for VSCode that I use on top of all the keyboard shortcuts but it's nice to have an option if it continues to be developed.

sethammons 7y ago
Same. I switched to Goland due to it.
geodel 7y ago
There may be better way to describe my feeling. But I think this LSP thingie is Electron of language tools. With the amount of activity I notice on LSP for Go is astonishing. Writes, rewrites and re-rewrites, the constant work on refactoring and optimization seems unending.
mattiemass 7y ago
When we started work on Chime, there were no viable Go language servers available, so we had all custom stuff. Now, gopls is fairly good, and has been progressing fast. But, yeah LSP isn't the holy grail. Progress on the spec is surprisingly slow, especially given how many holes it has. But, I'm very optimistic that it will get better. There's just so much traction behind it. However, Chime still contains a huge amount of custom language handling stuff, and will for the foreseeable future. LSP on its own is just insufficient for a good experience.
nicpottier 7y ago
While the switch to go modules was pretty smooth on the code front, the tooling was another matter. They had to rewrite everything to support modules and decided to create this concept of a "language server" which would then be universal across languages and help editors like VSCode support new languages that pop up as long as they provide their own language server that matches the spec. It's a nice idea but has been (and continues to be) super painful for anybody actually trying to get work done. This was a huge fuckup on the part of the Google engineers to combine the rewrite with module support. They should have first added module support to the existing tools THEN bitten off the totally new paradigm of a language server. Yes it would have been more total work but so many person-years of productivity was lost with the approach they took and we are still counting.
- mikewhy 7y ago
  Just FYI, your comment reads like you're saying the Go developers created the concept of language servers, but they were created by MS for VS Code.
hdra 7y ago
yea, I think Go's tooling has started facing the challenge of having an existing base to support.. I remember using vim-go few years back, and I was very impressed of how much it "just works", it really turned my vim into a Go-IDE with very little effort. I had to come back to go recently after not using it for quite a while, and a lot of the magic seems to have faded somehow. Ran into a number of issues that I had to find workarounds for.

by dewey 7y ago

sethammons 7y ago

Same. I switched to Goland due to it.

geodel 7y ago

There may be better way to describe my feeling. But I think this LSP thingie is Electron of language tools. With the amount of activity I notice on LSP for Go is astonishing. Writes, rewrites and re-rewrites, the constant work on refactoring and optimization seems unending.

mattiemass 7y ago

When we started work on Chime, there were no viable Go language servers available, so we had all custom stuff. Now, gopls is fairly good, and has been progressing fast. But, yeah LSP isn't the holy grail. Progress on the spec is surprisingly slow, especially given how many holes it has. But, I'm very optimistic that it will get better. There's just so much traction behind it. However, Chime still contains a huge amount of custom language handling stuff, and will for the foreseeable future. LSP on its own is just insufficient for a good experience.

nicpottier 7y ago

While the switch to go modules was pretty smooth on the code front, the tooling was another matter. They had to rewrite everything to support modules and decided to create this concept of a "language server" which would then be universal across languages and help editors like VSCode support new languages that pop up as long as they provide their own language server that matches the spec. It's a nice idea but has been (and continues to be) super painful for anybody actually trying to get work done. This was a huge fuckup on the part of the Google engineers to combine the rewrite with module support. They should have first added module support to the existing tools THEN bitten off the totally new paradigm of a language server. Yes it would have been more total work but so many person-years of productivity was lost with the approach they took and we are still counting.

mikewhy 7y ago
Just FYI, your comment reads like you're saying the Go developers created the concept of language servers, but they were created by MS for VS Code.

hdra 7y ago

yea, I think Go's tooling has started facing the challenge of having an existing base to support.. I remember using vim-go few years back, and I was very impressed of how much it "just works", it really turned my vim into a Go-IDE with very little effort. I had to come back to go recently after not using it for quite a while, and a lot of the magic seems to have faded somehow. Ran into a number of issues that I had to find workarounds for.