Hacker News Reader

Comment by kqr | Hacker News Reader

> Notably, the two-sided market problem was solved by Microsoft, who were a vendor of both languages (C# and TypeScript) and editors (VS Code and Visual Studio), and who were generally loosing in the IDE space to a competitor (JetBrains).

Talk about commoditising your complement!

----

Unrelated: how are LSP implementations and Emacs support generally these days? When I last tried 2–3 years ago the Emacs-specific plugins for various languages were still more reliable and predictable than their LSP counterparts, but has this changed a lot? If so, I might be inclined to try again.

View on HN

I've had a terrible experience with lsp-mode, gopls and Emacs 27. Minor issues like inconsistencies and CPU/RAM hogging that requires manual restarts, and the major one that made me stop using it is that Emacs would frequently crash when editing Go files.

I reported this to lsp-mode, but they kicked the can over to Emacs[1], which I never bothered reporting. The fact this is now a combination of tools with no clear reporting path when something goes wrong is awful UX.

Every few months I update the entire setup with hopes things improve, but eventually I always get the crashes. I would really like for this to work, as the DX when it does is great, but for me it's just not there yet.

[1]: https://github.com/emacs-lsp/lsp-mode/issues/3242

I will just note that I have the opposite experience, as a daily user of go-lsp for about two years. It has been more reliable and much faster than the older Go modes I tried. It has also worked much better for me in Emacs than it does for colleagues using VSCode's integration with gopls.

It's not without problems, occasionally taking quite a bit of processor power or needing the odd restart when it falls out of sync with a multi-module project, but it has never once crashed Emacs for me (using it on Ubuntu on WSL2, for what it's worth).

I am not writing this to invalidate your experience. It's clear that something is rotten with the way the plugin uses emacs on your OS, and it's frustrating to not get help with that. I will note that their observation - that an Emacs crash is first and foremost is an Emacs problem, not a plugin problem - is fair though. But, I also would not want to go through a long series of communications between different projects, so I get your pain entirely.

LSP support with lsp-mode is fantastic with at least Rust. I use Elixir at my day job and while it does a good job of doing 98% of what I want (go to definition, find references (iffy; Elixir is difficult to analyze like this), code lenses, autocomplete, etc.) there are a few rough patches. This is likely due to shortcomings with the lang server implementation, not the lsp-mode library itself.

Like I said, editing Rust is awesome in Emacs; saw someone working on Rust in VS Code and didn't notice anything that Emacs couldn't match.

See also lsp-ui; I don't turn this on personally, but it does give you some significant bling.

rust-analyzer is easily the best LSP I've played with, by a huge margin. It's good enough to sell the whole concept on its own.

lsp-mode is still not part of the official distribution, though.

And I’d argue that that’s right! As the post says, there’s no LSP in core VS Code either!

Neither is eglot, the other implementation. AFAIK there is no LSP package in the official distribution.

eglot is part of the GNU ELPA packages archive, managed by the people doing Emacs. It's possible to install it from the Emacs package manager, and the package will be signed and verified. So although it's not part of the official distribution indeed it's pretty easy to install.

Is that not also true of lsp-mode?

No the same, lsp-mode is part of the MELPA archive not GNU ELPA. So it's easy to install too but MELPA has no package signature verification. For commonly used packages I don't think it's a big problem, any funny business would be detected quickly.

It's moving fast, and the experience will depend a lot on the LSP server itself now. As for me, I've recently switched to LSP with eglot for C, C++ (clangd) and Python (pyls). The experience is good, in that it's easy to forget about it until you need it, and then it works OK.

It's best to have a recent Emacs though. At least Emacs 27, which introduced support for a C based JSON library (in Emacs 26 all the LSP parsing is done in elisp). This is the biggest change. Emacs 28 introduced an elisp JIT. I haven't any hard data, only a subjective experience but in my daily use with Emacs 28 it's fine, whereas it could be a bit sluggish at times with Emacs 26.

It's pretty good, LSP related modes are best used in tandem with the languages' major modes and LSP-mode has gotten much better the last year or so imo. It's more reliable and consistent across languages.

I've used it with Python, C/C++, SQL, HTML/CSS/JS, without issue and of course it has stellar support for Clojure.

It's catching up. You can use them in tandem though and ignore the features that overlap by configuration. I use Eglot with a bunch of different languages. Clojure is the only one where I still use other packages for dealing with similar things.

Can you please comment on your experience with Eglot? Is it better/ faster?

Eh, gonna be really hard to be Emacs' prowess in the land of Lisps. This rings pretty true to me: they all work well together.

IME, if you are using an up-to-date Emacs, compiled with the right libraries and options (M-x lsp-doctor), and you are using a language where the LSP support is good, you'll have a good time writing in that language in Emacs. I do C# at $DAYJOB, and I write most of it in Emacs. Outside of work, the only LSPs I have tried are Java and Kotlin. The Java LSP is great at the language level, but falls down in understanding project structure. The Kotlin LSP is vice-versa. I haven't tried one where there's a good Emacs-specific plugin like Python, though I probably should.

I switched back to Emacs + lsp-mode for Python, and it’s been excellent.

Reply on news.ycombinator.com