Rust Glancer and the bet that a language server can be memory-light
Lightweight Rust LSP optimized for low memory usage
At a glance
- What is it?
- Rust Glancer is an experimental Rust language server built for low memory use and near-instant editor restarts, targeting 90 percent completeness rather than replacing rust-analyzer. Its repository is a workspace of thirty crates split into an LSP layer, an analysis engine and a set of vendored components, and its author is explicit that it was built with heavy LLM assistance.
- Who is it for?
- Rust Glancer suits an editor user whose language server memory footprint is the problem, because low usage and fast restarts are the stated goals rather than a side effect, and it suits someone who wants to read how a compiler-adjacent tool is decomposed into a workspace of small crates.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Low memory and fast restarts are the two stated goals
Rust Glancer is described as an experimental LSP implementation that is optimized for low memory usage and near-instant editor restarts.
That pairing of goals is the whole point of the project. A language server sits in the background of your editor holding a full model of your workspace, and a language server for Rust is normally rust-analyzer, which is large. If you switch Rust files in a big workspace, the server restarts and your editor waits. A server that uses little memory and restarts in a moment changes what an editor can afford to do, because the cost of throwing state away stops mattering.
The project is explicit about not being a replacement for the incumbent. It aims to be 90 percent complete, being complete enough for day to day work without trying to be rust-analyzer 2.0.
The scale of that claim should be read carefully. Ninety percent of what? The project does not enumerate the missing tenth in the repository description, so a reader wanting to know whether a specific feature is there has to check the documentation site rather than the project summary. The framing is that of a work in progress that is usable, not of a drop-in replacement.
The primary language is Rust, the licence is Apache-2.0, and no homepage is recorded for the project, with the project documentation hosted at rust-glancer.github.io.
A workspace of thirty crates, and what each layer is for
The Cargo workspace is the clearest available description of the architecture, and the member list reads like a map of the compilation pipeline.
[workspace]
members = [
"editors/zed",
"crates/rust-glancer",
"crates/lsp/server",
"crates/lsp/proto",
"crates/lsp/engine",
"crates/engine/workspace",
"crates/engine/source",
"crates/vendor/parser",
"crates/vendor/syntax",
"crates/vendor/tt",
"crates/engine/cfg-eval",
"crates/vendor/macro-expand",
"crates/engine/parse",
"crates/engine/item-tree",
"crates/engine/ir-model",
"crates/engine/macro-runtime",
"crates/engine/ir-view",
"crates/engine/def-map",
"crates/engine/semantic-ir",
"crates/engine/ty",
"crates/engine/body-ir",
"crates/engine/analysis",
"crates/engine/project",
"crates/engine/package-store",
"crates/lib/text",
"crates/lib/arena",
"crates/lib/profile",
"crates/lib/std",
"crates/lib/std-derive",
"crates/lib/wincode-utils",
"crates/lib/test-fixture",
"crates/tools/codegen",
]The structure separates four concerns. The lsp/ directory holds the server, the protocol types and the engine that drives them, so the editor-facing surface is isolated from everything else. The engine/ directory is where the analysis lives, and its members follow a clear order: source and workspace at the bottom, then parse, then item-tree, then ir-model, then macro-runtime, then ir-view, then def-map, then semantic-ir, then ty, then body-ir, then analysis, with project and package-store at the top managing the workspace and the dependency sources.
The vendor/ directory is the interesting one, and the names make its purpose plain. parser, syntax, tt and macro-expand are vendored components, which is a strong hint that the author is not writing a Rust parser from scratch but adapting existing ones.
The lib/ directory holds the shared utilities, and three of them are telling. arena is an arena allocator, std and std-derive are a self-hosted standard library and its derive macro, and profile is presumably instrumentation. The workspace also uses resolver 3 and edition 2024.
The allocator is the load-bearing dependency
The acknowledgements section is unusual in how specific it is about one thing, and that thing is memory.
The project says that without jemalloc and tikv-jemallocator it would not have been possible at all. Not that they are nice to have, but that they are the reason it exists. The author adds that jemalloc is awesome as an allocator and also saved hundreds of hours of profiling allocations.
Then the twist: mimalloc and mimalloc_rust turned out to work even better for the purpose of this project.
So the final position is that the general-purpose choice, jemalloc, was tried first, cost a great deal of profiling time, and was superseded by mimalloc, which fitted the goal better. That is a much more informative sentence than a list of dependencies, because it tells you the memory target was pursued empirically and that the author changed the answer when the measurements said so.
The rest of the acknowledgements are equally deliberate. rust-analyzer is called an obvious inspiration, motivation, source of learning material and the place where a lot of ideas were hijacked, and the author says Rust is lucky to have such a great LSP and that everyone working on it is awesome. chalk is described as a really pleasant project to integrate, with lovely documentation.
A project like this is essentially an exercise in building a compiler-adjacent tool without the benefit of a large team, so the upstream projects it borrows from are not incidental dependencies but the actual source of most of the design.
The AI disclaimer says more about the code than any badge would
There is a section of the project summary devoted to how the project was built, and it is worth reading in full because it tells you what to expect from the source.
The project is being built with heavy use of LLMs. The author frames them as a tool, not a brain replacement. He considers the code to be his own and spends a lot of time caring about code quality, and considers the result to be rather readable and maintainable. He is careful to add that it might not be the idiomatic example of compiler-adjacent tooling, because he does not have that much domain experience, but that he is working on improving it as he works on it.
The most interesting sentence comes next. If it is slop, then it is his slop, and the best way to help is to tell him what is wrong, so that he can learn something and hopefully make the project better.
That is a specific and unusual invitation. Instead of a generic please open an issue, it is a request for review framed around a personal standard rather than a project standard, and it explains what kind of feedback is most useful.
For a reader considering the code, this section is the most relevant thing in the repository, because it sets expectations honestly. An LLM-assisted codebase of thirty crates written by one person without deep compiler tooling experience is a different risk profile from a mature project with a review culture, and the author is telling you that rather than hiding it.
Installation lives in the docs, and the repository gives no command
There is no install command in the repository, and that is a deliberate choice of where the documentation lives rather than a gap.
The project guide says installation is covered in the docs, at the installation page of the project documentation site, and the rest of the project guide points at that same site for more detail. So the repository is an index and the docs are the manual.
What the repository does give you is a sense of the shape of a development setup. There is a Justfile at the root, which is the task runner convention this project uses instead of a Makefile, and a rust-toolchain.toml that pins the toolchain. A clippy.toml, a rustfmt.toml and a deny.toml cover linting, formatting and dependency policy, and a .config/ directory holds tool configuration. There is a CHANGELOG.md, an AGENTS.md, and an .agents/ directory, and a .coderabbit.yaml for automated review.
The editors/ directory holds an editor integration, with zed named in the workspace members, and a .vscode/ directory at the root as well, so at least two editors are in scope.
There is also a test_targets/ directory, and the workspace excludes several named fixtures from it, including simple_crate, moderate_crate, complex_crate, moderate_workspace and complex_workspace, plus a set of bench_fixtures with names that describe the workload they are built to stress, such as synthetic_parse_heavy, synthetic_item_tree_heavy, synthetic_def_map_heavy, synthetic_body_heavy and rust-analyzer itself.
Three releases in two months, and a licence stated two ways
The release history is short and recent, which is consistent with a project at the stage where the author says it is.
The listed releases are v0.1.1 on 2026-08-20, v0.2.0 on 2026-09-01 and v0.3.0 on 2026-10-01, with the last push to the repository on 2026-10-19. So this is roughly three releases across two months, on a pre-1.0 version line, with commits landing after the newest tag.
The licence is stated in both the project summary and the workspace manifest, and in both places it is dual. The project summary says licensed under either the Apache License, Version 2.0, or the MIT license, at your option, with both files present in the repository root. The workspace package metadata agrees, with license set to MIT OR Apache-2.0.
The recorded licence identifier is Apache-2.0, which is a simplification of the dual statement, but the files on disk are the authority and they are unambiguous.
There is also a detail worth noting about the project identity. The workspace package metadata points at a repository and homepage under the popzxc name, while the repository itself is hosted at rust-glancer/rust-glancer, and the workspace description calls it a Rust workspace for rust-glancer. The author listed in the manifest is Igor Aleksanov.
Taken together, the version numbers, the 90 percent framing, the experimental label and the invitation to send the author feedback about his own code all point the same way: this is early, and it is being built in the open.
Editorial conclusion
Rust Glancer suits an editor user whose language server memory footprint is the problem, because low usage and fast restarts are the stated goals rather than a side effect, and it suits someone who wants to read how a compiler-adjacent tool is decomposed into a workspace of small crates. It does not suit a team that needs full language server coverage today, since the project describes itself as 90 percent complete and experimental, and it does not suit anyone unwilling to read the source to work around a gap. Before you switch an editor over, read the installation page in the project docs, because the repository itself only links there and contains no install command, and note that the last push was on 2026-10-19 with the newest release v0.3.0 published on 2026-10-01.
Frequently asked questions
What is Rust Glancer?
It is an experimental LSP implementation for Rust, optimized for low memory usage and near-instant editor restarts. The project aims to be 90 percent complete, enough for day to day work without trying to be rust-analyzer 2.0.
How is the Rust Glancer codebase organized?
As a Cargo workspace of about thirty crates. The lsp/ directory holds the server, protocol types and engine, engine/ holds the analysis stages from source and parse through semantic-ir, ty and body-ir to analysis, vendor/ holds the parser, syntax, tt and macro-expand components, and lib/ holds shared utilities including an arena, a self-hosted standard library and a profile crate.
What allocator does Rust Glancer use and why does it matter?
The acknowledgements say the project would not have been possible without jemalloc and tikv-jemallocator, and that jemalloc also saved hundreds of hours of profiling allocations, but that mimalloc and mimalloc_rust turned out to work even better for the purpose of this project.
How do I install Rust Glancer?
The repository does not contain an install command. Installation is covered in the project documentation at rust-glancer.github.io, and the project summary points there. The repository itself provides the development scaffolding, including a Justfile, a pinned rust-toolchain.toml, clippy, rustfmt and dependency policy configuration, and an editors directory with a Zed integration.
What licence is Rust Glancer released under?
It is dual licensed, at your option, under either the Apache License, Version 2.0 or the MIT license, and both LICENSE-APACHE and LICENSE-MIT are in the repository root. The workspace package metadata records the same MIT OR Apache-2.0 expression.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/rust-glancer-rust-glancer)Was this useful?