Zed vs Lapce: choose by workflow
Try Zed first for documented native Rust and Python language workflows. Try Lapce if its toggleable modal editing and Apache-licensed source fit your priorities. Both offer desktop editing and remote development. Before switching, test your essential language, extension and SSH tasks in one real workspace; neither editor wins merely by being written in Rust.
By Built with Rust editorial · Published
A missing debugger workflow can matter more than a dozen attractive features. Start with what would stop you working, then compare preferences. This is a documentation-based decision guide with a reusable acceptance worksheet, not a hands-on benchmark. Our catalog entries for Zed and Lapce link to the projects; the comparison below helps you decide which to investigate first.
Compare the requirements that can rule an editor out
Both projects provide macOS, Linux and Windows downloads, as their Zed installation guide and Lapce repository confirm. Platform availability is only the first check. For example, Zed's local Linux application requires Vulkan 1.3 support. Verify the actual machine and driver you use before planning a migration. That requirement does not establish that Lapce will run on hardware where Zed will not.
Scroll sideways to compare both editors and the acceptance check.
| Requirement | Zed | Lapce | Check before switching |
|---|---|---|---|
| Rust language intelligence | Native rust-analyzer integration | rust-analyzer plugin | Navigate, diagnose and format your workspace |
| Python workflow | Native basedpyright and Ruff support | Verify the exact Python plugin and features you need | Correct environment, imports and diagnostics |
| Remote development | Local UI with an SSH-connected server | Built-in remote development | Open, edit and run a task on your intended host |
| Editor extensions | Zed extension system | WASI-based plugin system | Find a supported equivalent for every essential feature |
| Costs | Free editor; optional hosted services can cost extra | Open-source editor; Lapdev is a separate product | Separate editor needs from service subscriptions |
For Python in Lapce, verify the current plugin, environment selection, formatter and debugger against your project before switching.
Rust and Python: check the language workflow, not syntax colors
Zed's Rust documentation describes native rust-analyzer integration. Lapce's official Rust plugin also uses rust-analyzer. That shared language server makes a blanket claim that only one is suitable for Rust hard to defend. It does not prove that navigation, code actions, debugging or configuration behave identically in the two editor interfaces.
For a Rust workspace, start from a clean working tree and open the workspace root. Pick a symbol from another local module and follow its definition. Make a harmless type error on a throwaway branch, check the diagnostic, then undo it. Format a small change and inspect the diff. Run your normal test task. If breakpoints are part of your day, confirm the debugger stops where you expect; a working language server alone does not settle that requirement.
For Python, Zed documents basedpyright and Ruff as native language services, with Python installed separately. Choose the project's intended Python toolchain, then check an import from that environment and a deliberate type error. Use the same project when evaluating Lapce, verifying its current plugin and interpreter configuration instead of assuming that a file opening successfully means the environment is correct.
Keep editor selection separate from changing your Python package manager or formatter rules. Our guide to uv, Ruff and Polars separates those jobs. If a migration changes the editor, environment and lint rules together, a different diagnostic becomes harder to explain. Hold the project configuration steady until you know which change you actually want.
SSH: a local launch does not prove the remote workflow
Zed's remote-development documentation describes a local interface connected over SSH to a remote server, with language servers, tasks and terminals running remotely. The Lapce project page also documents built-in remote development. An SSH feature label is not evidence that your particular host, architecture, shell, network policy and plugins will work without setup.
Use a non-sensitive test workspace on a host you are authorized to access. Verify an ordinary SSH connection first, then connect through the editor and confirm which machine holds the files. Change a test file, reopen it, and run a harmless project task remotely. Check that diagnostics refer to the remote environment, not an unrelated local toolchain. Repeat after disconnecting and reconnecting so that a one-off successful connection is not the whole trial.
Server installation also matters on restricted networks. Zed documents both remote download and a local-download/upload option for its matching server binary. Consult the current instructions rather than disabling a firewall or guessing a binary version. For Lapce, check your release's remote setup against the intended host and repeat the same workspace tasks after reconnecting.
Extensions, modal editing and paid services are separate decisions
An extension's useful behavior is the migration requirement, not its name. List what it does: attach a debugger, preview a format, manage a notebook, or run a language-specific action. Then find and test the editor-native equivalent. Zed has its own extension system; Lapce's repository describes WASI-based plugins. Shared Language Server Protocol support does not establish that an editor extension transfers unchanged. Keep your current editor for any essential workflow you cannot reproduce.
Lapce's repository documents toggleable Vim-like modal editing and an Apache-2.0-licensed codebase. Those are concrete reasons to try it if the editing model or source license matters to your project. They are not evidence that Zed lacks modal editing or that Lapce uses less memory. Source modification and redistribution questions should start with the actual license files, not a feature-comparison score.
If shared editing is a requirement, Zed's collaboration documentation describes real-time work in a shared project and requires sign-in. That is a concrete reason to include Zed in a team trial. Have an authorized collaborator check the actual joining, editing and leaving workflow before relying on it. This does not establish that collaboration is paid, or that another editor cannot support collaboration through a different setup.
Zed's current pricing page separates its free editor from optional paid hosted AI services. Consider those services only if you need them; an external AI provider may have its own bill. Lapce and Lapdev are different products, even though their pages share navigation. Do not price a local Lapce trial using a Lapdev hosted-environment plan. This comparison does not require you to subscribe to a service or send project code to an AI provider.
Use a pass, blocked or unverified migration worksheet
Write the acceptance condition before trying an editor. A pass means the required operation worked on the stated setup. Blocked means you reproduced a failure that prevents your work. Unverified means you did not complete the check. Do not turn unverified into either a pass or an accusation that a feature does not exist.
- Record the setup. Editor release, operating system, graphics driver where relevant, project revision, language tools, and local or remote execution. Do not mix a nightly build in one trial with an unspecified stable build in the other.
- Name the non-negotiables. Use concrete actions: follow a cross-file symbol, see a known diagnostic, format without unrelated changes, stop at a breakpoint, or reopen a remote workspace. Separate required tasks from nice-to-have preferences.
- Run the same work. Use the same test project and expected results in both editors. Save pass, blocked or unverified beside each task, plus the observation that justifies it. If you change settings to fix a failure, record the change and repeat the check.
- Make a reversible choice. Switch one project first only if every required task passes. Keep your previous configuration and editor installed. If a task is blocked, continue with the working setup while investigating; if unverified, finish that check before committing to the migration.
Copy this worksheet into your project notes. Record each editor's release, OS, project revision and local or remote host type. Mark optional tasks as not required before the trial; every required task starts unverified.
Scroll sideways for both editors' result columns.
| Required task | Expected result | Zed: status + observation | Lapce: status + observation |
|---|---|---|---|
| Cross-file navigation | Opens the expected definition in this workspace | Unverified — add observation | Unverified — add observation |
| Known diagnostic | Reports the deliberately introduced type error | Unverified — add observation | Unverified — add observation |
| Formatting | Expected diff with no unrelated rule changes | Unverified — add observation | Unverified — add observation |
| Project test task | Same command and environment; expected result | Unverified — add observation | Unverified — add observation |
| Required breakpoint | Stops in the intended executable; mark not required if unused | Unverified — add observation | Unverified — add observation |
| Essential extension | Your named behavior is reproduced | Unverified — add observation | Unverified — add observation |
| SSH reconnect | Intended remote files, tools and task still work | Unverified — add observation | Unverified — add observation |
Which editor should you try first?
Start with Zed when its documented native Rust or Python setup matches your daily work and you want to evaluate that integration before managing extra language plugins. The advantage here is a documented starting configuration, not a guarantee that every debugger, extension or remote environment will fit. An essential incompatible workflow is enough reason to keep your existing editor.
Start with Lapce when you specifically want to explore its toggleable modal interface, Rust plugin workflow, or Apache-licensed source. Give it the same real-workspace checks rather than dismissing it for having a different extension model. Conversely, a source-license preference alone is not a reason to abandon a working development environment.
Keep your current editor if neither candidate passes the tasks you need. You can still explore other Rust developer tools by task without moving your editor. When ready, open the Zed project details or Lapce project details for the official download and source links.
Sources and limits
Official documentation and repositories were checked on October 13, 2026. The recommendations are editorial judgments about workflow fit. We did not benchmark startup time, memory use, battery life or editing latency, and did not perform the worksheet in either editor. Unverified Lapce Python details are not evidence that Python is unsupported. Product features can change; follow the linked official instructions for your release. No overall numerical score is assigned.
Common editor-choice questions
Is Zed or Lapce better for Rust?
Zed documents native Rust support through rust-analyzer; Lapce offers a rust-analyzer plugin. Choose by the workspace operations you need, including navigation, diagnostics, formatting and debugging. This guide does not establish a performance winner.
Can I use Zed and Lapce on Windows?
Both projects provide Windows downloads, alongside macOS and Linux. Check each editor's current installation requirements and your graphics hardware; the operating-system name alone does not establish compatibility.
Is Lapdev required to use Lapce?
No. Lapce is the code editor; Lapdev is a separate development-environment product. Do not treat Lapdev's hosted pricing as the price of installing Lapce.