I'm trying to avoid IntelliJ because I only need it for editing TeamCity build configuration files, that are written in a Kotlin based DSL [0], and autocomplete and linting are be very helpful.
I've tried Eclipse and VS Code but I don't get them to autocomplete or detect syntax correctly. Would any LSP help me with that?
> But what do you actually get with IntelliJ? A massive, monolithic Java application that frequently hogs 8GB+ of RAM, locks up your system while “indexing pre-built binaries,” and forces you into a closed proprietary ecosystem.
This is just exaggeration. I use IntelliJIDEA everyday (on mac) with multiple projects open and tbh they have optimized the IDE a lot to make it faster. I'm not saying it's perfect, but it's getting better. Also it's not closed source. The core of the IDE is open source (https://github.com/jetbrains/intellij-community) and for some specific framework support (e.g. Spring) are available on Ultimate.
Also, like where else would the indices live? They are in memory to make going to definition, source, analysis etc fast. It's not even using java objects for these, so a feature-equivalent solution would be similarly "fat".
This is actually not an exaggeration. Ive been using WebStorm when it worked well, then it became progressively slower to the point of being unusable even on small projects.
It's a bit strange to project a personal experience with one product onto all other products by the same vendor, even if those products use shared platform parts. Not to dismiss your claim, it's just IDEs (code engines specifically) are naturally pretty complicated pieces of software, so the experience may vary.
The claim that 8Gb RAM is required just for Intellij seems to be at least overgeneralization (also depends a bit on how you count RAM usage; e.g. do you count all mmaped files as RAM usage even when pages are not loaded?). Can be true for some projects, but I've been working on decently sized Java/Kotlin codebases (~250k locs) with way less RAM allocated for Intellij (again, your experience may vary). Even Intellij and Kotlin projects themselves have been usable with less memory, at least some time ago.
What's more baffling, though, is how an LSP would be significantly better if it is based on the same IDE core, just running headlessly? I think there may be an independent non-IDE based LSP for Scala, but both Java and Kotlin LSP are based on existing IDEs engines (Java LSP is based on Eclipse engine, Kotlin LSP is based on Intellij).
A quote from the kotlin-lsp GitHub repository:
> The language server is based on the most recent IntelliJ IDEA version and proprietary parts of JetBrains Air and Fleet products, making it partially closed-source.
I've tried using RustRover over WSL2 multiple times with every new release, but it's been a huge disappointment every time. My fans constantly spin like crazy, memory vanishes into thin air, and typing is super laggy - it even overwrites random sections of the file sometimes. On top of that, the built-in terminal is totally unusable because it craps out and freezes the app whenever there's a large output.
PyCharm, on the other hand, was always great to use. But since VS Code gives me pretty much everything I need for my daily work without demanding too much from my system, I've finally moved away from JetBrains.
I feel the same about VS Code, it's probably some of the plugins but sometimes, especially when LLMs make edits, memory usage explodes until my system breaks down and force pauses some apps until I kill some of them.
I should go back to Zed, maybe use the CLI interface for agentic programming instead of the UI.
The fact we still don't have a decent Java language server is one of my canaries for the fact that LLMs still, generally speaking, can't ship. There is undeniably demand for this sort of thing, but nobody is coming to meet it. (jdtls, bless it for trying, is just not good)
Nah, there is little demand for it that's the reason.
LLMs don't need a LSP, they work better without it often.
Most Java devs use IntelliJ or another IDE with its inbuilt thing.
For everyone else the existing one is good enough for incidental usage.
Exactly. I've been trying to say this. Some people think that because people can write CRUD APIs and end-user apps with AI, no-one will need to write code anymore.
There is so much to be built in terms of tooling and libraries where we need tight, solid, well-crafted, original, unique code.
To be clear, it’s not supported by a compiler, but rather plain tree sitter syntax parsing. I’m embarking on a bigger project to create a linter (and integrate) without relying on JVM or a compiler at all, but IDK when that’s gonna come.
These are two different things; a language server would be a standardized intermediate layer between said CI tooling and any editor for inline / realtime checking, code suggestions and formatting.
That's just a wrapper for jdtls. I mean it works on some projects, but fails on many gradle builds and is basically just running the Eclipse IDE headlessly.
Metal, the Scala LSP, seems to do Java just fine. When using it in VSC, I feel the limitations compared to IntelliJ are more coming from VSC than from the LSP. Dependencies etc just resolve fine, it is just the UI that is not as polished as IntelliJ’s.
I try VSC with Metal twice a year. It works fine for small projects. But for bigger projects it lacks the more holistic approach that IntelliJ has and feels more like a text editor with smarts bolted on than an IDE.
I’m using Zed a lot as well for Golang and a bit for Rust. For Java it is also hard to use and lacking the same polish.
Exactly, I've been using their community edition for years for Kotlin development. Works fine for normal day to day development needs. I had a paid subscription for a while that I just let expire because I rely more on agentic coding tools these days and I just don't write a lot of code by hand at this point. The paid version adds a lot of deeper integrations and tools that you may or may not need. Personally, I don't really miss most of that. These days the community edition and the paid edition are the same. But if you don't take a subscription, the paid stuff is unavailable.
As a company, Jetbrains is a private company. It's one of the few large software companies that managed to get there without selling out to VCs or the vultures on the stock market. Of course they want to make a profit but they also create a lot of value for developers. Including a lot of open source things. I think it's nice that it's still possible to create a business by bootstrapping and without compromising your values.
I've tried Eclipse and VS Code but I don't get them to autocomplete or detect syntax correctly. Would any LSP help me with that?
--
This is just exaggeration. I use IntelliJIDEA everyday (on mac) with multiple projects open and tbh they have optimized the IDE a lot to make it faster. I'm not saying it's perfect, but it's getting better. Also it's not closed source. The core of the IDE is open source (https://github.com/jetbrains/intellij-community) and for some specific framework support (e.g. Spring) are available on Ultimate.
The claim that 8Gb RAM is required just for Intellij seems to be at least overgeneralization (also depends a bit on how you count RAM usage; e.g. do you count all mmaped files as RAM usage even when pages are not loaded?). Can be true for some projects, but I've been working on decently sized Java/Kotlin codebases (~250k locs) with way less RAM allocated for Intellij (again, your experience may vary). Even Intellij and Kotlin projects themselves have been usable with less memory, at least some time ago.
What's more baffling, though, is how an LSP would be significantly better if it is based on the same IDE core, just running headlessly? I think there may be an independent non-IDE based LSP for Scala, but both Java and Kotlin LSP are based on existing IDEs engines (Java LSP is based on Eclipse engine, Kotlin LSP is based on Intellij).
A quote from the kotlin-lsp GitHub repository: > The language server is based on the most recent IntelliJ IDEA version and proprietary parts of JetBrains Air and Fleet products, making it partially closed-source.
https://github.com/Kotlin/kotlin-lsp
PyCharm, on the other hand, was always great to use. But since VS Code gives me pretty much everything I need for my daily work without demanding too much from my system, I've finally moved away from JetBrains.
I should go back to Zed, maybe use the CLI interface for agentic programming instead of the UI.
LLMs don't need a LSP, they work better without it often. Most Java devs use IntelliJ or another IDE with its inbuilt thing. For everyone else the existing one is good enough for incidental usage.
So ~no one cares
There is so much to be built in terms of tooling and libraries where we need tight, solid, well-crafted, original, unique code.
I’m driving it daily and it’s much faster than IJ for what I need, although it doesn’t provide all the diagnostics that IJ does…
It’s on github.com/pepegar/ktlsp if you’re curious.
And speaking on llm and lsp. The new PHP lsp PHPantom (with help of llms) is approaching jetbrains offering fast.
This is probably the one contender:
https://github.com/georgewfraser/java-language-server
and it kinda works, but it's also a bit lacking.
I try VSC with Metal twice a year. It works fine for small projects. But for bigger projects it lacks the more holistic approach that IntelliJ has and feels more like a text editor with smarts bolted on than an IDE.
I’m using Zed a lot as well for Golang and a bit for Rust. For Java it is also hard to use and lacking the same polish.
https://scalameta.org/metals/docs/editors/emacs
https://github.com/jetbrains/intellij-community ?
As a company, Jetbrains is a private company. It's one of the few large software companies that managed to get there without selling out to VCs or the vultures on the stock market. Of course they want to make a profit but they also create a lot of value for developers. Including a lot of open source things. I think it's nice that it's still possible to create a business by bootstrapping and without compromising your values.