4 ms·
To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using
by geoka9 10y ago
To each their own, but Go is probably the only mainstream language that has first class integration with text editors. So I wouldn't let that stop me from using it, unless you can't see yourself using a text editor at all.
- solidsnack9000 10y agoWhat is the first class integration? My experience using Ruby, Python and Rust (via Racer) with Vim+Syntastic has been pretty good.
- geoka9 10y agoIDE functionality, similar to what godef/guru for Golang offer. But I'd settle on any mostly working jump-to-definition tool for Ruby/Python/Java that can be integrated with Vim/Emacs.
- josteink 10y agoIn Emacs Elpy has served me pretty well for python.
- ovidnis 10y agoIn 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 10y agoTypescript 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 10y agoDo 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 10y agoWith 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 https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations 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 10y agoI 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 10y agoThis 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/ http://langserver.org/