[ovidnis]

In my Emacs I've got 1) eldoc (displaying signature of function at point), 2) function source lookup, 3) function documentation lookup, 4) flycheck (display compiler err/warn on save), 5) auto-completion. Among a few other things like go-guru integration which I haven't used much yet but I can see its use.

All of those features come from editor agnostic golang tools.

[josteink]

Typescript has thee same. Ditto with C#. Python is pretty close. Same with most LISPs.

In Emacs too. I'd hardly say this is a unique selling point of Go.

[geoka9]

Do they do static analysis of code? The problem is that with other languages they all work "sort of". For example, for Elpy:

"the backends can not always identify what kind of symbol is at point. Especially after a few indirections, they have basically no hope of guessing right, so they don’t"

With go guru it just works, always, no matter how deep you drill into the graph (that's what I meant by "first class").

[josteink]

With C# and TypeScript and all LISPs I've worked with, they work hand in hand with the compiler/runtime to provide absolute correctness at all levels. Absolutely first class. (And I agree Elpy does not qualify for that term)

And while we're on the subject: Only Microsoft had the foresight (or hindsight, insight, whatever) to realize this was a general problem and propose a solution which applies to all editors and all languages:

https://github.com/Microsoft/language-server-protocol

https://github.com/Microsoft/language-server-protocol/wiki/P...

You'd think Google, with their tons of resources could put together a few resources and join a new, future-proof non-NIH standard for Go, but so far they seems to be lagging.

[geoka9]

I agree, a common standard would be good. That said, experience taught me to distrust any proposed standard that comes out of Microsoft. Besides, I find that with the programming editor communities, such standards are not that important - as long as a language has the tooling, it'll be integrated, standard or no standard.

[josteink]

This protocol is about reducing the N languages and M editors = N*M client/server implementations with a much better N+M solution, where we don't have to reinvent 200 wheels every time someone makes a new editor or language.

And the protocol is open. Seriously what do you have to lose, besides a shit-ton of redundant work?

Distrust? Distrust exactly what? Are you sure you aren't being your own worst enemy?

See here for a list of fully open source and MS-independent implementations: http://langserver.org/

[josteink]

Too late to edit, so replying to self.

Looking at that list, I see Go is actually doing pretty well these days. I retract my criticism.

That said, as the page shows, having full editor support these days is getting pretty common.

[solidsnack9000]

The issue there is that Python is a dynamic language. Syntactic resolution of what a "thing" is in, in some sense, not supposed to always work -- otherwise it would be a static language!

Being able to recognize what a syntactic entity represents -- type or value or whatever -- has been supported by the editor plugins for static languages for a very long time.

[geoka9]

For sure, but then there are mainstream static languages like Java/Scala which still lack that kind of support (e.g. ensime and friends, which work unpredictably, if at all).