> (I believe even dedicated go IDEs like goland have always been a little behind go itself. It simply doesn't scale to have every editor implement their own go

> (I believe even dedicated go IDEs like goland have always been a little behind go itself. It simply doesn't scale to have every editor implement their own go tooling.) This isn't true in my experience. Goland worked well with go modules the day the Go release candidate including them was published. The jetbrains ecosystem is also overall great for polyglot apps including stuff like different language injection in string literals in another language. Afaik they are explicitly not using language servers, as they have their own generic language representation, which enables a lot of refactorings by itself. All in all, whenever a teammate complained about something not working in vs code, I was successfully using it in Goland.