The editor earns speed by working with broken code.
Rust Glancer's architectural tour starts with a useful constraint. A language server must answer from partial information. It can parse the open file for symbols before the workspace is indexed. Richer editor functions need definition maps, type inference, a synchronized virtual file system, parallel reads, cancellation, and a policy for stale results.[1]
That is not a defective compiler. It is a different machine. A compiler can fail a build because one crate is wrong. An editor has to stay useful while the current line is unfinished and the workspace is still loading.
IDE support changes how a language feels.
Besok's account of rebuilding a JSONPath library in Zig comes from seven years of Rust experience and one Zig project. The author says the thin IDE support pushed the work toward command-line tools. The same account compares explicit allocator ownership, failure-path tests, and manual cleanup with Rust's ownership rules.[2]
The report is personal evidence, not a language ranking. Its useful lesson is broader. A language experience includes the feedback loop around the code. When the editor knows less, the build command and test harness become more visible. That can improve discipline, but only if the cockpit shows which system produced each answer.
A squiggle is an editing aid. A successful build is a build result. A passing test is evidence about the path that ran.
Zig's own docs put checks in named places.
The Zig language reference documents test declarations, leak reporting through the test allocator, safety checks, undefined behavior, and build modes. Those mechanisms have scopes and conditions. A leak report requires exercised code. Runtime safety depends on the selected build mode. A successful test does not inspect an unexecuted failure path.[3]
This is why one global "healthy" badge is bad cockpit design. It hides the witness. The interface should name the source, age, scope, and next stronger check.
Use two lanes, not one confidence color.
The editing lane should answer quickly and admit partial state. Show whether results come from the current buffer, a workspace index, or cached analysis. Cancel stale work when the document changes.
The inspection lane should prefer complete evidence. Run the repository's real build. Run the relevant tests. Record the command, revision, environment, and result. If the index is still useful for navigation, keep it visible without promoting it to release proof.
Install four witness labels.
- Parsed: the current buffer has enough structure for local navigation.
- Indexed: workspace analysis can answer broader questions, with a stated generation or age.
- Built: the configured build command completed for a named target and environment.
- Tested: named tests ran against a named revision. Untested paths remain unproven.
Agents need these labels too. Otherwise a coding agent can turn a fast editor hint into a confident handoff sentence. Make the receipt carry the witness that justifies the verb.