“We want VS Code to become the most popular code editor”
“Code editing, redefined.” This is the slogan Microsoft used to present VS Code, their new open source IDE that can be used with any programming language. A special language server protocol is part of the concept, making it possible to implement languages centrally and use them with any tool. We talked to Erich Gamma, Head of Development of VS Code, about the idea behind the IDE.
JAXenter: Hi Erich. You are currently working on the VS Code IDE at Microsoft. What is the VS Code all about? Is VS Code a browser IDE?
JAXenter: The language server protocol is part of the architectural concept of VS Code. Why did you choose this protocol?
Microsoft wants developers to freely choose the tools.
Erich Gamma: An important lesson we have learned is that the best support for a programming language is implemented using the programming language you want to support. This does not have to be the language used to build the IDE or editor.
Furthermore, language support is typically complex and uses a lot of storage because a program is an abstract syntax tree; as a result, powerful functions like IntelliSense can be offered. It makes sense to have potentially resource-killing programming language services run as independent processes to separate them from VS Code. That transforms a language service into a programming language server running on a local machine.
We call this a tool server. Running something as a separate process opens the door to many possibilities, including using this process with different editors/tools. This can be further simplified by standardizing the protocol used by the IDE to communicate with the programming language server. Therefore, an IDE just needs to implement one integration of the protocol to use all programming language servers “for free”, as long as they are using the same protocol.
For providers of programming languages this means that language integration needs to be offered as a programming language server to be consumed by different IDEs. It is a real win-win situation. Microsoft wants developers to freely choose the tools. So if you want to develop C# or TypeScript on a Mac with Sublime or Emacs, that is possible.
JAXenter: You are one of the architects of the Eclipse platform – so let’s compare them: With Eclipse everything is about integrating different tools over plug-ins into a tooling platform. Has extensibility also been an important theme inVS Code?
We went a step further than Eclipse.
Erich Gamma: Eclipse got a lot of things right when it comes to extensibility and VS Code needs to be extensible too. We also use the principle of “lazy loading” for extensions. Unlike Eclipse, we took it a step further with the isolation of extensions to prevent the IDE from being “harmed” — on start-up or when an extension goes on a rampage.
Fast start-up is one of the goals of VS Code, independent of the extensions installed. Also, it should always be possible to save changes, even when an extension is caught in a loop. Therefore, VS Code runs extensions in a separate process and communicates with this so-called “extension host” via RPC. Extensions are isolated; the core of the IDE is protected.
Another difference between Eclipse and VS Code is that we wanted to offer a marketplace for extensions right from the start. Extensions can be easily found in the marketplace; more than 1000 extensions have been developed and made available on the marketplace since last November!
JAXenter: It was recently announced that Red Hat, Codenvy and Microsoft have decided to collaborate to bring the language server protocol forward. What is the goal of this collaboration?
Erich Gamma: We defined the protocol after having already integrated two programming language servers into VS Code, namely OmniSharp for C# and TypeScript Server. We started looking for partners that shared our interest in using programming language services across IDEs and editors. We met Codenvy and Red Hat.
Red Hat announced at the DevNations conference that they will be offering a programming language server for Java and integrate it into VS Code. Codenvy wants to support languages like C# in Eclipse Che. This quickly became a win-win situation.
Initially the protocol will be developed in a public GitHub repository. Users already started discussing possible extensions via “issues”.
JAXenter: What are the next steps?
We want VS Code to become the most popular code editor.
Our goal is to run VS Code as a highly transparent Open Source project: the more community knows about what we are doing, the more feedback we get. We will continue to publish a new release every month and collect and carefully examine feedback.
The monthly iteration plan is available on GitHub. For example, this is the plan for June. Our roadmap shows exactly what we are doing in the next six months. One of the things included in the plan is the elimination of so-called “adoption blockers”. Our goal is quite simple: We want VS Code to become the most popular code editor.
JAXenter: Thank you for this interview.