Topic

Language Server

2 posts about Language Server. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Posts

Databricks
Open-sourcing Metals v2: Databricks’ Java and Scala language server for multi‑million line codebases
Databricks open-sourced Metals v2, a Scala and Java language server designed to provide low-latency code intelligence for multi-million-line Bazel monorepos, including its 26M-line repository. The project extends Metals v1 by reworking three layers: a build-free, content-addressed mbt repository index; compiler-backed Scala and Java pipelines using a Metals-provided sourcepath; and metadata-first BSP integration that keeps build synchronization off the startup path. Its Java implementation uses javac APIs and a modified Turbine header compiler, which processes close to one million Java lines per second on one thread and supports interactive analysis at nearly 100,000 lines per second in benchmarks. Metals v2 is available in Cursor, VS Code, and Neovim under Apache 2.0, while Databricks reports Cursor’s share of Scala and Java file-open events rising from 40% to 78%.

Cursor
Iterating with shadow workspaces
Cursor’s shadow workspace addresses the problem of letting AI agents iterate on code without disrupting a developer’s active workspace. The design prioritizes LSP usability—especially lints, definition navigation, and language-server interaction—while also requiring independence, privacy, concurrency, universality, maintainability, and speed. A copied in-memory TextModel was rejected because sharing the user’s language server could introduce copied files into references, duplicate declarations, or miss errors. The implemented approach uses a reusable hidden Electron window for the workspace, routing AI edits through Cursor’s processes and returning lints independently of the visible editor. The post treats runnability as a harder future extension, with folder-proxy designs, platform limitations, and network-level independence still open questions.

The best engineering reads, once a week.

Topic

2 posts about Language Server. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Databricks
Open-sourcing Metals v2: Databricks’ Java and Scala language server for multi‑million line codebases
Databricks open-sourced Metals v2, a Scala and Java language server designed to provide low-latency code intelligence for multi-million-line Bazel monorepos, including its 26M-line repository. The project extends Metals v1 by reworking three layers: a build-free, content-addressed mbt repository index; compiler-backed Scala and Java pipelines using a Metals-provided sourcepath; and metadata-first BSP integration that keeps build synchronization off the startup path. Its Java implementation uses javac APIs and a modified Turbine header compiler, which processes close to one million Java lines per second on one thread and supports interactive analysis at nearly 100,000 lines per second in benchmarks. Metals v2 is available in Cursor, VS Code, and Neovim under Apache 2.0, while Databricks reports Cursor’s share of Scala and Java file-open events rising from 40% to 78%.

Cursor
Iterating with shadow workspaces
Cursor’s shadow workspace addresses the problem of letting AI agents iterate on code without disrupting a developer’s active workspace. The design prioritizes LSP usability—especially lints, definition navigation, and language-server interaction—while also requiring independence, privacy, concurrency, universality, maintainability, and speed. A copied in-memory TextModel was rejected because sharing the user’s language server could introduce copied files into references, duplicate declarations, or miss errors. The implemented approach uses a reusable hidden Electron window for the workspace, routing AI edits through Cursor’s processes and returning lints independently of the visible editor. The post treats runnability as a harder future extension, with folder-proxy designs, platform limitations, and network-level independence still open questions.

The best engineering reads, once a week.