Kotlin-Lsp: Kotlin Language Server and Plugin for Visual Studio Code

Original Article ↗ Hacker News Discussion ↗

Motives, Timing, and Kotlin Adoption

  • Many see this as JetBrains finally yielding after years of resisting an official LSP to protect IntelliJ’s advantage.
  • Suggested triggers: perceived stagnation or slight decline in Kotlin usage, Kotlin’s image as “Android-only,” VSCode’s massive share (especially with AI/LLM tools), and developers unwilling to adopt ecosystem-locked languages.
  • Some argue prioritizing IDE lock‑in over Kotlin’s ubiquity was shortsighted; others say JetBrains must optimize for IntelliJ revenue, not raw Kotlin usage.

Business Model and Ecosystem Debates

  • Debate over whether growing Kotlin usage benefits JetBrains: critics say it creates cost without direct revenue; defenders cite brand, mindshare, education, and long‑term conversion to paid tools.
  • Comparisons: Apple (closed but wildly successful) vs. Borland/Delphi and sponsors that abandoned NetBeans/Eclipse.
  • Clarification that Kotlin and IntelliJ are overwhelmingly developed by JetBrains, not funded by large Google contracts.

Partial Open Source LSP and Architecture

  • Initial backlash to the “partially closed-source” status.
  • JetBrains explanation: current LSP implementation leans heavily on internal IntelliJ/Fleet/Bazel infrastructure; goal is to iterate quickly, then decouple and fully open it.
  • Some see this as pragmatic early release (“better some OSS now, all later”) rather than a red flag.

Editors, IDEs, and Lock-In

  • Strong split between “best specialized IDE per language” (IntelliJ/Android Studio/Xcode, etc.) and “one editor for everything” (VSCode, Helix, Zed, Emacs).
  • VSCode praised for multi-language workflows and LSP support in a single instance; criticized for fragile extensions and weaker debugging/profiling than JetBrains.
  • JetBrains criticized for product fragmentation (different IDEs per language) and brittle project configs; others still prefer its deep tooling.
  • Emacs users are particularly excited—Kotlin support via LSP unblocks them.

Kotlin vs Java and Language Lock-In

  • Java 21/23 raises the question: why Kotlin? Supporters cite null safety, mutability semantics, terseness, better functional features, top-level functions, unsigned types, and iterator ergonomics.
  • Several correct the misconception that Kotlin is proprietary; it’s Apache 2.0 licensed.
  • Broader debate on ecosystem lock‑in: some avoid Kotlin/C#/Apple stacks entirely; others point out every language has an ecosystem, and C#/.NET and Kotlin are now broadly cross‑platform.

Limitations and Concerns About This LSP

  • Current LSP only supports JVM‑only Gradle projects; lack of Kotlin Multiplatform support is a blocker for some and is explicitly awaited.
  • Worry that JetBrains might abandon this like the Kotlin Eclipse plugin; others note that plugin was maintained for years, but had a small audience.
  • Isolated reports of compatibility issues with Cursor’s older VSCode base.