News for hackers. Stuff that matters.
Re:Go team adding a Go language server to core by int_19h on Saturday September 22, 2018 @02:58AM (#18044873)
The irony is that the popularization of the language server protocol made it easier for small languages to get good tooling. Where before you had to either write your own IDE, or pick an existing one (of which all had upsides and downsides, so better pick wisely) and write an extension for it - often requiring learning a completely new language and framework to do so - now you can write a straightforward out-of-proc server implementation in the language itself (and likely reusing the existing parser etc that you already have) against a standard protocol, and have several popular IDEs and editors light up immediately.
Re:Go team adding a Go language server to core by oblio on Saturday September 22, 2018 @05:57AM (#18045326)
The ironic thing is that the LSP was started by a corporation.
Re:Go team adding a Go language server to core by int_19h on Saturday September 22, 2018 @10:17PM (#18049038)
To some extent; but there's solid reasoning behind this. By coming up with LSP, Microsoft achieved two important goals.

First, and most importantly, its languages (esp. TypeScript) can be used by people who already have an established workflow around an existing editor or IDE. It's much easier to sell a new language that plays well with an existing ecosystem, than it is to sell a whole new ecosystem (and Microsoft knows that full well from experience with .NET!). And higher adoption of TypeScript across the industry means that more people eventually come through it to the larger Microsoft ecosystem, as well, even if it's a small percentage of the larger crowd.

At the same time, it's also a way to recruit the open source community to extend Microsoft IDEs. If you're making a new PL or templating framework or something else that needs editing support, and your audience is primarily people on Vim and Sublime, then LSP is an obvious choice to minimize code duplication. But once you have it, you might as well package it for the VSCode extension gallery as well (and if you won't, someone else probably will).

So I think it's a win-win for everyone, except for companies that sell integrated all-in-one tooling solutions where the main benefit to the user is derived from only one part of it (because users can now mix and match as they see fit, and bundling becomes harder).