[HN Gopher] Show HN: Create a full language server in Go with 3....
___________________________________________________________________
Show HN: Create a full language server in Go with 3.17 spec support
Author : rumno0
Score : 81 points
Date : 2026-03-24 21:56 UTC (5 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bbkane wrote:
| Started in case I ever build a language server, thanks! The
| interface looks very understandable, and the debug server looks
| really nice.
|
| Now that I think about it, it might be really cool to add LSP to
| my CLI framework[0] (I already have tab completion for shells,
| why not make an editor plugin if it's this easy ..)
|
| 0: https://github.com/bbkane/warg
| rumno0 wrote:
| I wrote this for the infracost LSP so I could write multiple
| IDE extensions. Its not even really a language server, its just
| a neat way to parse the Terraform/Cloudformation and return
| diagnostics.
|
| Language servers are cool!
| SwiftyBug wrote:
| Very nice. Now I want to build a language server. If only I had
| anything to build it for.
| catlifeonmars wrote:
| To give you some idea how versatile a language server is, I
| wrote one once to provide go-to-definition between two related
| blocks in a large proprietary YAML configuration file. If the
| definition was missing, it would also render the red squiggly
| line to indicate that something was misspelled.
|
| Another time I used one to make the hosts in my SSH
| configuration file clickable to either open a terminal with a
| session or just to display cpu/memory statistics.
|
| Lots of neat editor-independent interactions can be enabled
| using language servers.
| rumno0 wrote:
| I've been thinking about this comment for a few hours now! I
| love it! I like building VS Code extensions and realized
| quickly the benefit of writing the logic in an LSP but I
| would never have thought to do the SSH config thing you
| describe.
|
| I've now started a Makefile lsp since you've inspired me to
| think about the painful scenarios that LSP can solve if I
| think a bit wider.
|
| Cheers for that!!
| rumno0 wrote:
| thanks!
|
| Thankfully, I finally had a reason to build an LSP (infracost
| LSP), so it motivated this and I'm really pleased with it
| zephyrwhimsy wrote:
| Markdown survived because it optimized for the right tradeoff:
| human readability with just enough structure for machine parsing.
| whateveracct wrote:
| // DiagnosticSeverity indicates the severity of a diagnostic.
| type DiagnosticSeverity int
|
| Hmmm :robot:
| jryio wrote:
| The godoc format enforces that the comment start with the name
| of the identifier and be a complete sentence(s) describing what
| that identifier does. Predates LLMs
| badc0ffee wrote:
| I wouldn't say it enforces that the comment start with the
| name of the identifier. Maybe certain linter options enforce
| that?
|
| In https://go.dev/doc/comment it seems to be a convention,
| but there are a couple of examples there where the don't
| follow it.
| rumno0 wrote:
| Yeah some times godoc comments look crap by necessity
| fainpul wrote:
| But you don't _have to_ add a docstring. Cases like this are
| worse than no docstring at all, because it wastes the reader
| 's time.
|
| If you add one, at least make the effort to provide some
| useful information. For example which is more severe: higher
| or lower numbers.
| rumno0 wrote:
| I disagree - you should have docstring and I don't think
| this is worse by having it... its just not ideal
| hrmtst93837 wrote:
| Boilerplate docstrings are lint that spreads, and stale
| ones are worse, I've seen sevreity fields documented less
| clearly than the code they annotate.
| maleldil wrote:
| Every public item should have a docstring, even if it's
| just to indicate that there's nothing special about the
| item.
| Myzel394 wrote:
| Have you tried out https://github.com/tliron/glsp?
| rumno0 wrote:
| I actually started out using that. I wanted a debug UI to track
| messages which was the major driver in creating my own tbh
___________________________________________________________________
(page generated 2026-03-29 23:01 UTC)