Like I said, I like LSP, but a great exceptional feat of engineering it is not.
This applies to most of VSCode as near as I can tell.
Would something like Go have taken off 20 years ago? I'm not so sure, the zeitgeist at the time was very much in the direction of dynamic languages. And would Python take off if it was released today? Not so sure about that either.
But you know, putting in the work to write down a specification isn't really a marvel of engineering. It's ... just putting in the work.
It's no marvel of engineering, but someone did put in the work, and others used it, more that can be said about many other things that might be "better engineered".
It just seems to be a generic interface to describe language bindings, which most text editors have.
In practice it's mostly a bad thing because any advanced language has special needs which will end up difficult to address by funneling everything through a common interface.
A far cry from the days of sublime text’s regex-based autocomplete
Now some might point out that LSP-based stuff is, like, bloat. Sure, OK. But there's a lot of motivation to do work that can pay off across the board. So much language stuff was based off of random regexes! It's hard to overstate how much better of an editor situation we are in than 10 years ago.
This isn't even getting into VS Code offering a way for you to put... one? two? files into a git repo and have that mean that opening the editor will spawn a container, _install itself in the container_, and run there while still having a native GUI for the actual usage of the tool. So much incidental complexity, gone!
One might point out that containers are a "big ball of mud" solution, but I vastly prefer that to big setup scripts that only half work. Here's to hoping we can shrink the ball of mud.