Ie, last that I looked, eglot had no equivalent to lsp-install-server.
I'd prefer to install pyright myself in my own node virtualenv rather than having it dropped into ~/.config/emacs/.cache/lsp/npm/pyright, but I understand why autoinstall is an attractive option.
Feature regressions and security holes from those sources will effect everyone, even those installing manually.
It's not that it's hard, but it's Yet Another Thing That Can Go Wrong.
I also feel that lsp-mode's features are higher quality overall, with the downside of depending on packages and features not built into emacs itself. An example of such a feature is lsp-mode's project integration, it uses projectile which is much more powerful and useful than the built in project.el. Another example is using flycheck instead of flymake for on-the-fly diagnostics.
I would not say either package is better than the other because they are so different, and have such different philosophies. Eglot is much more minimal and tries to use native emacs features when possible, preferring minimalism over features. lsp-mode brings in a lot of features and prefers to use third party packages instead of built ins.
I used eglot for a little while before trying lsp-mode and decided that I personally prefer lsp-mode overall, with both being great options. I would recommend anyone curious to give both a try and decide for themselves.
It is quite telling that Emacs is the only place that ELisp gets used as a style. Compare that to a lisp like Clojure where people love implementing Clojure in strange new places. Or Common Lisp which has more than 10 major implementations (and one in Emacs, naturally). Nobody chooses to use ELisp without serious prompting.
Someone writing bad ELisp doesn't say much about the quality of a package or how useful it will be.
If they're writing it on Emacs, then it is.
I mean, if you have an app running on the JVM, and the developers are poor at Java, you kind of would expect issues.
And besides "good code" in ELisp is a bit of a funny one. Lexical scoping is a relative innovation.
I used to think this, but sometimes this determines how deeply your package integrates into emacs.
The obvious example here being seamless tramp support.
IIRC this is demonstrated in this very interesting blog post[0] about debugging why opening a remote file is slow in the projectile package, likely didn't exist in the project.el alternative that is more steeped in those traditions.
0: https://www.murilopereira.com/how-to-open-a-file-in-emacs/
Of course, there are problematic sections (so do eglot) but keep in mind that `lsp-mode` and emacs-lsp organization has ~10 times more code and contributors.
Edit: typo lsp
No clue how good it is, but it does exist and it's not the only one.
https://emacs-lsp.github.io/lsp-mode/page/lsp-latex/
> for autocorrection when sending mail or writing random documents
Complete-at-point is integrated with company-mode, of which I use lsp as a backend to serve suggestions. So ... In a way, yes, I do get spelling suggestions through the same mechanism that lsp works.
I think for a languages like Python, LSP servers are interesting but for some other languages the existing tools are already very powerful: OCaml with merlin comes to mind for example.
That said, the LSP approach is nice and makes many editors able to profit from each language server :).