Build language servers in Go without the boilerplate

A new Go project is trying to make language servers much less painful to build. The pitch is simple: support for the Language Server Protocol 3.17, automatic handler registration, and a debug server that helps you see messages as they move through the system.

That matters because language servers are one of the few ways to write editor features once and ship them to Visual Studio Code, JetBrains IDEs, and other editors without rewriting the same logic over and over. In the Hacker News thread, the project’s author said they built it for an infracost LSP, then used it to generate extensions for multiple IDEs.

What makes this interesting is the shape of the API, not just the protocol support. The library uses interface-based auto-registration, which means you can define handlers like hover, diagnostics, and completion without a pile of manual wiring. For Go developers who like small abstractions and explicit code paths, that is a pretty appealing trade.

What the Go library actually does

The project, called glsp, is built to help developers create full language servers in Go. On the surface, that sounds niche. In practice, it opens the door to editor integrations for tools that were never meant to become programming languages.

The examples linked in the thread make that clear. The author already published language servers for Makefile and GoReleaser, which are exactly the sort of files that developers edit often enough to want better completion, diagnostics, and jump-to-definition support.

That practical angle is probably why the post got attention. Language servers are often discussed in abstract terms, but the real value shows up in annoying file types: build scripts, infrastructure configs, and internal YAML formats that are hard to validate by hand.

• glsp supports LSP 3.17
• The author says it was built for an infracost language server
• Demo servers already exist for Makefile and GoReleaser
• The library includes a debug server for inspecting messages
• Handlers auto-register through interfaces instead of manual setup

Why the API design got people interested

The strongest reaction in the thread was about the interface-based registration model. One commenter said they liked the “interface-based auto-registration pattern” and called the implementation of HoverHandler clever because there is “no manual wiring.” That kind of feedback matters more than generic praise, because language server libraries usually fail on ergonomics before they fail on features.

The author also explained one design tradeoff that matters a lot in production: if a handler returns a normal error, the server sends an error response and keeps going. If the handler panics, the server crashes, and the author said they were going to fix that. That is the kind of detail that tells you this is a real developer tool, not a demo wrapper around the protocol.

“That’s the kind of API design that makes Go’s implicit interfaces shine.”

That quote from the HN thread captures the core appeal. Go developers tend to like systems that feel direct, and this library seems to aim for that: define a handler, let the framework find it, and keep the protocol plumbing out of the way.

The debug server is another smart choice. Anyone who has built integration code knows that being able to see the raw messages can save hours. In LSP work, the bug is often not the editor or the parser, but the translation layer between them.

How it compares with other LSP options

glsp is not the only Go library in this space. The author said they started with tliron/glsp before building their own version, mainly because they wanted a debug UI to track messages. That is a useful clue: this is not a case of “the first tool was bad,” but of “the first tool did not fit my workflow.”

For teams choosing an LSP stack, the comparison comes down to ergonomics, observability, and how much protocol code you want to write by hand. Here is the practical view:

• tliron/glsp already exists and is a known option
• owenrumney/glsp adds the debug-first workflow the author wanted
• VS Code’s LSP guide shows why protocol reuse matters across editors
• LSP keeps the editor-specific work smaller than writing separate plugins
• warg was mentioned in the thread as a CLI framework that could add LSP support

The thread also included a useful example from another commenter: they had once used a language server to connect two related blocks in a proprietary YAML file, and later to make SSH hosts clickable for terminal sessions or system stats. That is the real argument for LSP. Once the protocol is in place, editor behavior can be tied to any structured text, not just source code.

That flexibility is why language servers keep spreading into places that used to depend on custom editor plugins. A Makefile server, a Terraform helper, or a YAML tool all benefit from the same protocol surface, even if the underlying logic is completely different.

Why this matters for Go developers

Go is a good fit for this kind of tooling because the language makes it easy to build small services with clear boundaries. The library’s author seems to have leaned into that by using interfaces for registration and keeping the protocol layer separate from the domain logic.

There is also a subtle ecosystem effect here. If building a language server gets easier, then more command-line tools can grow editor features without a rewrite. That means better completions for config files, richer diagnostics for build systems, and fewer one-off plugins that break when an editor updates.

For developers who already ship CLIs, the idea is tempting: your parser is already there, your validation rules are already there, and your editor integration may be one protocol layer away. That is why the HN commenter thinking about adding LSP to a CLI framework made so much sense.

My read is that the important number here is not the 92 points on the HN post. It is the number of tools that could use editor support once the boilerplate gets smaller. If glsp keeps its current shape and fixes the panic path, I would expect more niche file formats to get first-class editor features over the next year, especially in Go-heavy infrastructure teams.

If you maintain a CLI or config tool today, the question is simple: would your users benefit more from another flag, or from hover, diagnostics, and jump-to-definition in their editor? For a lot of tools, the answer is probably the editor.