I'm hopeful that https://github.com/Microsoft/language-server-protocol will decouple some of these concerns. We've built support for it for our DSL, and it's pretty great so far (esp in VSCode). Emacs LSP support is still pretty slow, so I don't use it when in emacs at present, but it feels like the right direction for getting good language support into editors.
In A CEO's Guide to Emacs (2015)microsoft
language-server-protocol
TypeScript2016–2024
microsoft / language-server-protocol
language-server-protocol
Defines a common protocol for language servers.
54Distinct people
59Mentions
1Explicit recommenders
13.1KGitHub stars
What to know before exploring
What it is
Defines a common protocol for language servers.
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
tree-sitter is a phenomenal project i’m doing a git-related project myself and use it to generate symbols for source code if you’re into it too, i recommend also checking out…
ushakov used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year59 dated mentions
Observed mentions: 2016-06-27 19:48:43 UTC to 2024-09-06 22:23:58 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 14 | 4 | 10 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 18 | 1 | 17 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 3 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Microsoft Open Source Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct.
Resources:
Microsoft Open Source Code of Conduct
Microsoft Code of Conduct FAQ
Contact opencode@microsoft.com with questions or concerns
Read the full README on GitHubWhat Hacker News says
18 sources> I still don't get it. We could create a parser framework that allowed a client to get some sort of generic AST and reference graph - which would enable all the use-cases of language servers but would also allow more use-cases in the future (e.g. IntelliJ-style inspections or language-aware diffs).
The point is to move the use-cases to the server/protocol to avoid the "(m languages) x (n IDEs)" problem. The protocol is at https://github.com/Microsoft/language-server-protocol with contribution guidelines so it should "allow more use-cases in the future".
> Instead, the standard requires running half a dozen processes with an API that doesn't provide anything except the exact data required for a number of handpicked use-cases.
Why half a dozen? Two seem enough (IDE + language server). It's also the minimum given that IDEs are using differe
Read the rest
nt languages/runtimes and that lot of languages have most of their tooling written in the targeted language.
How open is this going to be? Will it be based on a protocol implementable by other editors, akin to the Language Server Protocol (https://github.com/Microsoft/language-server-protocol) ?
In Visual Studio Live ShareErm, VSCode does all of that for Rust via RLS and the Language Server Protocol[1]. Heck, VSCode does even better than Android Studio because the pick common words in the source file as part of their auto completion. Things like comments, untyped parameters(ints, etc) all work much better in VSCode.
I'll agree that for Java VSCode isn't up to par yet but for many other languages it's easily at an equal level.
[1] https://github.com/Microsoft/language-server-protocol
In Android Studio 3.0 Release NotesThat's a good question. They've built an amazing system. Google and ex-Google engineers love the code intelligence/search systems that Google has, and those are powered by Kythe and related systems inside Google. At a product level, many ex-Googlers miss those systems in their new companies and fill the gap by setting up Sourcegraph internally.
Tech-wise, Kythe is optimized for offline analysis, and we use servers that speak LSP (https://github.com/Microsoft/language-server-protocol), which is built for online analysis and use while you're editing code. That is what I see as the main difference. We would love for the approaches to converge, or for the representation/configuration to be compatible.
In Announcing Sourcegraph 2.0IDEs promise a lot, and in many cases they deliver at least some of them. But they're all or nothing: to benefit, you must use their text editor, their debugger, their supported suite of compilers, their documentation browser, their everything.
A trend has emerged recently: editor-agnostic language oracles. These tools expose an IPC interface for querying, and in some cases even mutating (i.e. refactoring), source code. They often incorporate a compiler so the type information you get is perfect, and exactly what the compiler sees. Integration with the programmable text editor of your choice (vim, Emacs, Atom, Sublime Text, VSCode…) is a simpler matter of making the right IPC calls.
I think this is the sweet spot. I would hate to be locked into an IDE's poor text editor or buggy interface just because they offer some convenient tools
Read the rest
.
Some examples of editor-agnostic tooling:
* CIDER for Clojure and ClojureScript (via weasel or figwheel). The primary editor plugin is Emacs, but vim and Sublime Tex support exists outside the main repository.
* rtags and ycmd for C and C++
* tern for Javascript
* racer and RLS for Rust
* eclipse.jdt.ls for Java
* guru for Go
Microsoft has even created a protocol for these daemons to follow, which makes editor integration even simpler: https://github.com/Microsoft/language-server-protocol/wiki/P...
I agree with many points raised here.
Provide CLI tooling and you can build integrations with any editor! A while back Microsoft published Language Server Protocol [0]. I'm sure there must've been previous attempts achieve this, but I'm not aware of any that were widely successful. Meanwhile LSP seems to be gradually growing [1]. Having a common interface seems like such a sensible idea too! With that said, I think the software community has largely standardized on Unix. Is it unreasonable to expect OSs to implement a Unix-compatibility layer? Given that Windows is working towards that goal, is there any other major holdout?
Code formatters make tons of sense. It lets you shift the responsibility over to the computer. I think it should also be possible to have an editor visually format code in your own preferred style, while saving the ou
Read the rest
tput in the project's preferred style; although I haven't seen this implemented by any editor yet. In the web community, Prettier [2] has been growing increasingly popular. It currently supports JS, CSS, and GraphQL in many of their flavors (e.g. JSX, Flow, TypeScript, etc.); and there's ongoing discussion about supporting others like Markdown [3], and probably others which I haven't seen.
Dependency management is one of the big pain-points of dealing with older languages. I want to be able to pull in APIs that correctly solve my problem without sacrificing cross-platform support. Sometimes I want to load multiple versions of a library. Setting up a working build environment shouldn't require multiple hours or days of work. As an example, I've wasted multiple days over the last few months trying to build android for either my Pixel or Nexus 5X, using Ubuntu, and I haven't been successful. I can't count the number of times I've lost interest in projects because I couldn't get it to build after spending countless hours, sometimes days, trying to setup a working environment. I have my fair share of criticisms of the web development community, but at least it's never a problem getting one of their projects to build.
Testing is important! I think this is something that Swift is doing well. They have a list of projects [4] which they automatically test against the development branch in order to understand the compatibility impact of their changes. With their latest set of breaking changes they also provided tools to help gradually migrate to the latest version [5]. I'll note I haven't worked on a serious production-ready Swift environment, so I don't know how effectively these tools work for a serious real-world projects.
Version control is a must, but I'd also suggest trying out more tools, rather than limiting yourself to git. I've used git professionally, and I can work with it without breaking anything. But plenty of its commands are needlessly confusing and quirky, and it's too easy to shoot yourself in the foot. Relevant XKCD [5]. I've had cases where I shot myself in the foot and Time Machine's file history was the only thing that saved me. Fossil [6] is a really nifty alternative, written by the creator of SQLite. It's much friendlier, and it includes an issue tracker and wiki! I've been happily using it for some of my personal projects. It's not the right tool for every problem, but it never hurts to try out something new.
[0] https://github.com/Microsoft/language-server-protocol
[1] http://langserver.org
[2] https://prettier.io
[3] https://github.com/prettier/prettier/issues/2444
[4] https://swift.org/source-compatibility/
[5] https://xkcd.com/1597/
[6] http://fossil-scm.org
Interesting post. I have worked a lot with LSP personally and professionally. I'm CEO of Sourcegraph, and we use LSP everywhere. (Go to https://sourcegraph.com/github.com/mholt/caddy/-/blob/caddyh... and open your browser's network inspector Web Socket list to see it live, for example.)
I think LSP's success is a demonstration of the "less is more" principle. It is simple and designed only to satisfy an editor's needs. But unlike many similar attempts, LSP has a lot of traction; see https://github.com/Microsoft/language-server-protocol/wiki/P... for a list of implementations (http://langserver.org/ for more details).
One of the reasons why this simplicity is necessary is that if a protocol even tries to represent structure or relationships across many different languages, it becomes harder and harder to add support for more languages. You
Read the rest
can try to make it work for N languages, but the (N+1)th language always has some new language or syntax element that requires you to either change the specification (and update the N previous implementations) or deal with hacks (which goes against the whole reason to design the "one schema to rule them all").
A second reason is that even if you can make it work for all the languages you care about, it's very difficult to find enough language experts across all of those languages to build and maintain the implementations. It takes a lot of time to understand and communicate a complex schema and how the edge cases are handled across the various languages. And in the time it takes you to find and educate that team, you've already fallen behind new languages features being added or new popular languages coming on the scene. (Unless you are Google. Their Kythe project is an exception. :)
LSP has explicitly rejected the goal of modeling complex language features, at least so far. Perhaps with the impressive initial traction they could add it on and succeed where many other attempts haven't yet. But I doubt it.
(If you want to read more background about LSP, in addition to the Microsoft repo, you can check out some articles my cofounder wrote: https://text.sourcegraph.com/how-sourcegraph-scales-with-the..., https://text.sourcegraph.com/part-2-how-sourcegraph-scales-w..., and https://text.sourcegraph.com/sourcegraph-code-intelligence-a...)
This is basically what the language server protocol (https://github.com/Microsoft/language-server-protocol) is doing, just in reverse.
In Tmux and Vim – better togetherLanguage server protocol is a specification, hopefully all tools will work towards compatibility:
https://github.com/Microsoft/language-server-protocol
In Rust Language Server Now Available with Rustup> Because everything's better with cloud.
Hm? This has nothing to do with the cloud. RLS leverages the compiler APIs very heavily to provide context-aware code completion, so this just makes it trivial to make sure that the version of RLS that you have installed is appropriate for the version of the compiler that you have installed, by leveraging the exact same tool that people use to install the compiler.
EDIT: Or maybe you're confused regarding "server"? The RLS is a daemon, running locally on your machine. The "server" moniker comes from Microsoft's "language server protocol", which the RLS implements. https://github.com/Microsoft/language-server-protocol
In Rust Language Server Now Available with RustupWith 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.
In The State of Go> Example of small things Microsoft can help with: as far as I can see Nuclide doesn't work with dotnet core (only Mono). Throwing 1-2 devs that way would pay good dividends, in my opinion.
I don't know anything about Nuclide, but if they want to work with dotnet core, they should look into working with omnisharp-roslyn[0]. VS Code[1] and Atom[2] both have extensions that work with it.
> In my opinion Microsoft should focus more on base tools for F#, such as Roslyn, integration with dotnet core, etc.
I think there's already work underway for F# support for dotnet core[6].
As far as F# support for editors go, have a look at ionide[4]. They only have extensions for VS Code and Atom at the moment.
> Integration with Visual Studio is nice, but if the language is to be adopted in hacker circles, without major Microsoft investment, it needs to
Read the rest
provide very solid and flexible tools on top of which the community can build awesome things.
Have you seen omnisharp[5]? If so, what's missing from that?
[0] https://github.com/OmniSharp/omnisharp-roslyn
[1] https://github.com/OmniSharp/omnisharp-vscode
[2] https://github.com/OmniSharp/omnisharp-atom
[3] https://github.com/Microsoft/language-server-protocol
[4] http://ionide.io/
[5] http://www.omnisharp.net/
[6] https://github.com/dotnet/netcorecli-fsc
The wiki has a list: https://github.com/Microsoft/language-server-protocol/wiki/P...
In Announcing Rust Language Server Alpha ReleaseShowing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.