Escape IntelliJ: Scala and Kotlin LSPs on Emacs Eglot

What people actually landed on is narrower and more useful. For Scala, this looks real. Metals is regarded as a proper language server with solid editor support, and several people said the documented Emacs setup already works, including extras like worksheets. Kotlin is more compromised. JetBrains’ Kotlin LSP is largely the IntelliJ analysis engine running headless, so you are not replacing the core machinery so much as replacing the GUI around it. Java looks worse still. Multiple commenters said the ecosystem still lacks a truly strong standalone Java LSP, with jdtls described as workable but clearly behind IntelliJ, especially on Gradle-heavy projects and on the kind of whole-codebase understanding that makes large refactors safe. That led to the real dividing line. IntelliJ is still the tool people trust for JVM code navigation, refactoring, debugging, and project-wide analysis. Even many of the people complaining about bloat said they keep it around for exactly those jobs. The anti-IntelliJ case was not “there is feature parity elsewhere.” It was “for small edits, incidental work, scripting, or people who want their tools to be hackable, a lighter editor plus LSP is now good enough.” Emacs, Neovim, VS Code, and Zed all came up in that role. The mood on JetBrains itself was split but pointed. Plenty of people said the products have become slower, heavier, and distracted by AI add-ons. Others pushed back that recent builds are better optimized, that the open source IntelliJ Community core gets ignored in these complaints, and that any feature-equivalent JVM tooling will need substantial indexing and memory anyway. The practical consensus was blunt: if you want the best JVM IDE today, IntelliJ is still hard to beat. If you want a modular workflow and can live with weaker semantics, the editor-plus-LSP route is finally viable, especially for Scala and selective Kotlin use.