[nwsm]

> VS Code almost daily at work for writing Go

How would you rate VS Code for Go? I use the official Go extension but am not impressed. My main gripe is that I often have to manually add a local import that should have been found and suggested when I typed the name of a variable or function exported from an adjacent package. I much prefer Goland, but use VS Code because it is the only editor my company's internal AI code assistant supports.

[Groxx]

VSCode for Go is pretty much just gopls (the language service). So this is all true for Go plugins in vim, emacs, etc because they all use the same base, but not GoLand.

IMO: gopls is only just barely good enough to stop people from building an actually good replacement. Highlighting and build error stuff is reliable, but it regularly misses extremely straightforward type lookups, navigation, and autocomplete hints and that makes it untrustworthy in pretty much all cases. Basically everyone I know who uses it (somewhere between 50 and 100 people that I've talked with about this) relies on plain text search to get around and find things rather than doing type-driven stuff, because otherwise they fail to discover a lot.

All of which means it's insane and awful to me, barely better than "it doesn't support Go but Go looks close enough to C that it mostly works"-style ctags. And sometimes worse: even unsupported-language-fallback stuff in random tools sometimes gives much better autocomplete than gopls, which for me semi-routinely fails to hint things defined in the same file.

---

GoLand by comparison is wildly more capable, stable, and controllable. It actually works, and e.g. if you "find usages" you get a complete and precise result. Highly recommended if you do a lot of Go work. The single exception is that it doesn't support GOPACKAGESDRIVER (because it isn't gopls), so if e.g. you've got a complicated/abnormal Bazel setup it won't integrate well.

[yeukhon]

Surprisingly it works pretty well for me. Where we work we have a weird go and non-go module setup but everything works with almost no additional tweaking on vscode side, just exporting some env variables.

But Python? I hate the testing setup. We have a mono repo, while not as big as meta’s, full discovery eats cpu. So we had to tweak our settings, per team, to only discover team specific dirs. Also, there is no way to kill a running test (at least no obvious shortcut or button-wtf)

[candiddevmike]

Have you ever had VScode add an import prefixed with your vendor path instead of real module path? It doesn't happen too often but it's goofy when it does.