No More JetBrains Products for Me

TEXT ANALYSIS PROTOCOL ENGAGED

THE DISSECTION

This is a developer breakup letter: personal, emotionally resonant, and mechanically precise. A power user with years of JetBrains loyalty defects to Zed, a Rust-based editor, citing performance collapse as the decisive grievance. The post is doing the rounds on Hacker News because it articulates a widely-felt but rarely-expressed frustration: JetBrains products feel wrong in a way that makes their conceptual quality irrelevant.

The author is not leaving because features are missing. He is leaving because the tool actively disrupts the cognitive flow state that is the entire point of a developer tool. The startup friction, the background indexing, the RAM consumption — these are not bugs. They are the signature of an architecture built on the assumption that hardware is infinite and that user time is cheap. That assumption is dying.

THE CORE FALLACY

The post frames this as a product preference problem: JetBrains got slow, Zed is faster, switch. It treats the issue as a competitive vendor problem — which competitor wins — rather than recognizing what this transition signals about the architecture of developer tooling itself.

The fallacy: thinking this is about JetBrains vs. Zed, when it is really about the end of the Java Virtual Machine era of developer tooling. JetBrains products are written on the IntelliJ platform, which runs on the JVM. The JVM delivers cross-platform consistency and plugin extensibility. It also delivers startup latency, memory overhead, and indexing complexity that are structural, not incidental.

Zed is written in Rust. It exploits modern hardware parallelism, compiles to native binaries, and treats performance as a first-class design constraint. This is not a product improvement. This is a generational architectural transition.

The author's grief is real — he genuinely loved the JetBrains design philosophy — but what he is mourning is a paradigm, not a product.

HIDDEN ASSUMPTIONS

Three assumptions smuggled into the post that deserve scrutiny:

1. Local desktop tooling is still the primary locus of developer workflow. The author treats the editor as the sovereign workspace. But the real architectural shift is toward cloud-based IDEs (Cursor, Windsurf, GitHub's Copilot workspace) and AI-native coding environments where the "editor" is a thin interface on top of LLM-mediated code generation. The author's choice of Zed over JetBrains is real, but it may be a transitional comfort rather than a durable endpoint. Zed is still a local desktop app.

2. Performance problems are a product failure, not a structural inevitability. The author implies JetBrains could fix this with better engineering. In some sense yes — but the JVM foundation, the plugin ecosystem, the feature depth that defines JetBrains' value proposition, all work against radical performance reform. The slowness is the price of the scope. He is not encountering a solvable bug; he is encountering a trade-off that is baked into the architecture.

3. The AI integration in Zed is "tasteful." This is doing a lot of work. The author implies AI tooling can be well-integrated or poorly-integrated, and that this is a design judgment call. The deeper reality: AI coding assistance is a transitional phenomenon. As AI capabilities mature, the editor itself becomes partially obsolete — code generation, refactoring, debugging, and documentation become ambient rather than invoked. The question is not whether Zed's AI integration is tasteful today; it is whether the concept of a "primary editor" survives the next five years of AI tooling advancement.

SOCIAL FUNCTION

This post is performing grief-marked defection — a specific cultural genre common in developer communities where users of mature, respected tools announce their departure with genuine mourning. It serves several social functions:

• Validation for latent defectors: People already frustrated with JetBrains get permission to switch.
• Prestige signaling: The author's years of investment in JetBrains (~$85/year for years) make his departure meaningful. Casual users switching would not generate this response.
• Community norm-setting: The Hacker News audience rewards this kind of post because it reinforces a community value: that performance and developer experience matter more than feature breadth or brand loyalty.
• Low-stakes rebellion: Defecting to Zed, a Rust-native editor with AI integration, positions the author as forward-thinking without requiring a radical workflow change. It's a safe hedge.

The post is not predicting collapse. It is documenting a transition in progress.

THE VERDICT

This post is a data point in the broader obsolescence of the JVM-generation IDE paradigm. JetBrains is not dying — it has deep enterprise penetration, massive install base, and genuine quality in its toolchain. But it is being outflanked on the axes that matter most to a growing segment of developers: startup latency, memory discipline, and AI-native tooling integration.

The Zed switch is real but modest in scope. The more significant transition happening beneath it: the desktop IDE itself is being decompressed by AI. When code generation, debugging, refactoring, and architecture suggestion become ambient LLM capabilities, the "primary editor" becomes a UI layer rather than a productivity core. JetBrains knows this — that's why they have AI tools. But their architectural legacy makes them slow-footed in responding.

What the post actually documents: not the death of JetBrains, but the beginning of the end of the local desktop IDE as the primary developer workspace. JetBrains can survive this transition if it migrates to a faster, more AI-native architecture. If it doesn't, it becomes the next Emacs — beloved, professional, and slowly relegated to the enthusiast fringe.

EMBEDDED ENTITY ASSESSMENT: JetBrains

EMBEDDED ENTITY ASSESSMENT: Zed