If you're just starting the LSP, you might wonder what language to build your Language Server (LS) with. This article will help you pick the right language. You can choose anything (seriously, I built a toy Language Server in Bash). There's no universally correct answer, but there’s a correct one for you.
Consideration 1: Audience
Your audience is the most important consideration. If you're writing a language server for a new Python web framework (Language Servers aren't just for languages, people), then implementing the language server in Java might raise a few eyebrows.
The audience for a Python framework is less likely to contribute to a language server written in a language they're less familiar with. There's nothing wrong with Java (IMHO), but the biases associated with languages could hurt adoption.
If your language server is for a specific language or tooling tied to a specific language, you should probably use the same language to build the server.
Consideration 2: Personal Preference
If you're building your language server as a hobby, the first user is yourself. Optimize for your own enjoyment.
You’re less likely to have fun building if you pick a popular language with unfamiliar (or poor) ergonomics. If you're not having fun, you're less likely to get very far with the project, and your language server won't ever matter to anyone else anyway.
This doesn't mean you should limit yourself to languages you're already an expert in -- building a language server is a great way to learn how a new language handles
- stdin/stdout and other communication channels
- concurrency and parallelism
- error handling
- testing, debugging, profiling
- etc.
Consider picking a language you'll enjoy using.
Non-consideration: Performance
Unless you're building a language server to replace one that is demonstrably slow, you should probably avoid optimizing your decision for performance. Measure first before you start hand-coding assembly code.
You're a developer; I get it. You want to think performance matters. Suppose computationally intensive behaviors are required to calculate diagnostics/code actions/etc. In that case, you can always shell out to something tuned for performance and still keep the Language Server itself implemented at a higher level.
Don't worry about performance. It isn't important at first, and you have options later.
Non-consideration: Ecosystem and Libraries
Many languages already have libraries that provide abstractions to help you write language servers. These can jump-start your development but aren't going to make or break your project.
You have all the building blocks you need if you can read and write over stdin/stdout and encode and decode JSON.
Learn more and build alongside me in my LSP From Scratch series.
You can build a language server without third-party libraries.
What If There's No Clear Winner?
If the considerations above haven't helped you pick a clear winner, choose TypeScript (or, if you must, JavaScript).
The first-party libraries (e.g., vscode-languageserver-node) are in written TypeScript, and the community and ecosystem are excellent. A discussion on the vscode-languageserver-node project often leads to an update to the spec itself.
As a bonus, servers written in TypeScript (and JavaScript) can be bundled inside a VS Code extension and be available in the VS Code Marketplace as a single download. I've put up a Minimum Viable VS Code Language Server Extension repo where you can see how this all fits together.
All things being equal, choose TypeScript.