On Language Servers: Interview with Martin Lippert
Martin Lippert's talk, Implementing Language Servers - the Good, the Bad, the Ugly is an early pick. Martin gives us his thoughts on why language servers are important, what the challenges are and what the future might look like for the technology.
Q: Language servers have been called a conceptual breakthrough. What in your opinion has come together to make it possible now?
A: The architecture behind language servers, mostly the language server protocol, hits a sweet spot. Language and framework providers can now, for the first time, focus on their language or their framework, instead of dealing with the numerous proprietary extension APIs of all the various IDEs and editors out there in the world. They can implement language tooling in the language of their choice, using libraries of their choice, and re-using the compiler technology of their choice - and all that in an editor- or IDE-agnostic way. They can do the job once instead of re-Implementing everything for each IDE they want to provide language tooling for. That is a huge step forward.
On the other side of the equation, people working on IDEs and code editors don’t need to think about individual languages anymore. They can focus on the user experience while editing code and let other people do the work for individual languages and frameworks.
In the end this makes up a powerful matrix of IDEs/editors and language servers which can all be combined independently of each other. It's a very powerful approach, especially since developers use a larger variety of languages and tools than ever before.
Q: What have been some of the challenges working with this innovative technology?
A: The devil is in the details - as always. The language server protocol defines the basic structure and semantics of the messages that the client (the IDE or the code editor) exchanges with the server (the language server). And both sides need to have the same understanding about those messages and need to deal with them in the same way. Otherwise the advantage of implementing a language server that can be used out of the box with various clients is gone. At the moment the client implementations (as well as existing language servers) vary greatly in those details. It is hard to implement a language server that provides the same awesome user experience across all the various clients.
This might be a problem of the early days of this new architecture because most of the client implementations aren’t mature yet. That might improve in the future. But at the moment you really need to test your language server against each IDE/editor individually to make sure everything works as expected. And sometimes you need to deal with differences in the clients via feature flags or behavior flags in the language server. That is somewhat annoying from time to time.
Q: What would you like to see in the medium term that would take the technology to the next level?
A: I think having a broad set of high-quality client implementations that are all on the same level would be a great step forward.
And maybe a unified mechanism to add those language servers to an existing client would be great. At the moment you have to implement the client-side extension manually and for each client individually. This isn’t a lot of code, but you still have to deal with different extension mechanisms.
And it will be interesting to see how people exchange information along different languages servers or whether they will remain totally isolated from each other. I can see meaningful arguments for both sides.
Q: How do you think Language Servers and the Language Server market will look in 3 years?
A: I expect that all major IDEs and editors will support the language server protocol out-of-the-box. I also expect that most language providers will provide language server implementations for their languages out-of-the-box.
Q: What message do you think is most important here for EclipseCon attendees?
A: One of the most important messages for attendees at EclipseCon with regards to language servers is: if you want to support a language or a framework, a language server IS THE WAY TO GO. The days of hacking your parser, builder, content-assist, and refactoring directly into Eclipse are over.