Zed is now available on Windows

I just compiled "zed" with "cargo build --release" and not only did it pull >2000 dependencies, its size (executable file) is literally 1.4G. Debug is 1.2G.

  $ pwd
  /tmp/zed/target/release
  $ ls -lh ./zed
  -rwx------ 2 john john 1.4G Aug 28 17:10 zed

  $ dut zed/ | sort -h
   598M    0B   | | /- webrtc-sys-0a11149cbc74bc90
   598M    0B   | | | /- out
   598M    0B   | | |- webrtc-sys-090125d01b76a5e8
   635M  160M   | |   /- s-hal7osjfce-1h7vhjb-4bdtrsk93m145adnqs17i9dxe
   635M  160M   | | |- project-06kh4lhaqfutk
   641M  161M   | | /- project-1ulvakop54j8y
   641M  161M   | | | /- s-hal5rdrth3-0j8nxqq-d0wsc7qnin39797z4e8ibhj4w
   1.1G  1.1G   | | /- zed-ed67419e7a858570
   1.1G  1.1G   | |- zed
   1.3G  1.3G     | /- zed-64b9faeefdf3b7df
   1.3G  1.3G     |- zed
   1.4G    0B     |- build
   2.2G    0B   | |- build
   7.9G  1.4G     /- deps
   9.4G    0B   |- release
    14G  2.9G   | |- incremental
    19G  4.2G   | /- deps
    33G    0B   /- debug
    42G    0B /- target
    42G    0B zed

  $ du -h ./target/debug/deps/
  20G     ./target/debug/deps/
  $ du -h ./target/release/deps/
  8.0G    ./target/release/deps/

  $ du -h ./target/debug/zed
  1.2G    ./target/debug/zed
  $ du -h ./target/release/zed
  1.4G    ./target/release/zed

Any explanations as to why "cargo" does not seem to re-use libraries (dependencies) in a shared directory, or why it needs >2000 dependencies (that I see being downloaded and compiled), or why the executable file of the release mode is 1.4G unstripped while of the debug one it is less?

What does a desktop text editor have to do with WebRTC?

Amazon q is 100mb and that’s a cli app. Rust programs be huge.

Probably it helps that Sublime doesn't come with an AI agentic features, LSP, and a whole video-conferncing and screen-sharing client by default.

ST is a text editor while Zed is an IDE. I wish there were something like VSCode that is very modular but written in native. But VSCode is good enough and it is my daily driver.

No, that doesn't matter. I think you should be looking for how quickly it can get you a working environment for your favorite language not how long it takes to boot up once per reboot. If you want features the bits have to live somewhere. Look at it like a trade off, if you're just going to look at it, by all means, take a memory dump. But I find that a little bit hard to work with.

For me, as long as it's better than alternatives it's good enough. Especially if it's not running JS.

Strangely it's the actual binary's .text section that's about 400MB. Time to dive in!

I was a little sus, so I checked: https://imgur.com/a/AJFQjfL

897MB! But it appears to have installed itself twice for some reason. Maybe one is an 'update' which it didn't clean up...? I'm not sure.

Edit: I just opened it and it cleaned itself up. 408MB now. I guess it was in the process of upgrading.

Will it though? I mean it's a lot for a "text editor", but much less than a classical IDE. And 400M is pretty negligible if you're on Windows, where your OS takes up dozens of GB for no reason.

Entirely untrue. Download git, run make and you'll get a 19MB `git` binary along with a whole lot of other 19MB binaries. Running `cargo build` produces a 3.8MB binary.

And that's still comparing apples to oranges, because git is compiled with full optimizations. Running `cargo build --release` produces a 462KB binary.

Even if I'm comparing to my system's git installation, that's still 3.9MB, and that's with all the debug info stripped.

Yes rust (like C++) tends to produce larger binaries than C, but lets be real here: The reason Zed has a bloated binary is the ~2000 rust packages that comprise it.

That's an entirely different issue. The kb's of overhead for backtrace printing and the format machinery is fixed and does not grow with the binary size. All combined it wouldn't account for anywhere close to 1mb let alone 100's of mb.

[dead]

Most of the sticker shock from Rust binaries is due to them being statically-linked by default. Considering that, Rust binaries aren't especially large, especially if you strip them. Dynamically-linked binaries are better at obscuring their size.

How do other editors handle this in your experience? I’m pretty sure VSCode behaves exactly the same, with the addition of a manual “merge” editor when you try to save, but never shows changes live for a modified file.

Changes to open files without any modifications in the buffer are always shown. Are you using any kind of containers or virtual fs that might be interfering?

I find Neovim to be surprisingly sluggish. That's of course after installing extensions, but I don't find it particularly performant. Zed feels way snappier.

Not the OP, but it's pretty useful in my team, we all work on the same environment, with the same system dependencies, with no setup required on development machine (except the need for docker).

In the devcontainer you can run code snippets, use the system shell and access an execution environment close to production if well made.

It also allows to avoid (system) dependency conflicts between different projects you may work on.

I sometimes work on old PHP applications, some of which require versions as ancient as 5.4 and refuse to run on anything beyond that. They're not only difficult/impossible to install on modern systems, but also make it hard to onboard other people — you have to write a detailed setup document and then waste a couple of hours time for each new system. And then repeat that a few more years down the line.

Why not write that document as a bunch of build instructions instead of free-form text, while also isolating the result from the rest of the system.

In our case, instant on-boarding of devs with no host setup needed. It's a large, complicated repo with a lot of unusual system dependencies. We build a multi-arch base image for all this and then the devcontainer is built on-top. Devcontainer hooks then let us do all the env setup in a consistent, version controlled way. It's been a god send for us and we'll never go back.

I use a devcontainer to run Claude Code on a sandbox with all tools and services installed. That way I can run YOLO mode with some safety.

I am a big fan of using it when working with somewhat complicated toolchains, especially if they need to be compiled. Cleaning up the file system is as simple as deleting the container and starting a new one. OCaml on windows comes to mind.

It's ideal for open source projects, no need to install a toolchain locally for small changes. I've used it for a POC in Go where nobody has Go installed in my organization. Not that Go is complicated to install, but I wouldn't ask anyone to install a toolchain for a one-off POC.

There's other toolchains that are more involved or conflict with an operating system's pre-installed stuff, like (iirc) Ruby on MacOS.

While I understand your point, and think you are correct - if the 'Trash' button is not behind a confirmation box, and it's not undoable, then that is a pretty terrible design choice.

As I just elaborated on in another comment VSCode and Zed both have "Delete" in the right-click menu as the last entry. VSCode only has 'Delete' and while it has a confirm screen it goes to the trash with the ability to Ctrl+Z.

After years of deleting files in VSCode I have a muscle memory for that behavior and I just skip through the dialogue. I didn't realize Zed's 'Delete' worked differently until I lost work, so I was just reflexively skipping through its confirm screen as well.

Just a pure guess, but if you do a global find, you get a list of 3-line-ish chunks of context around search matches.

If you then Ctrl+A to select all and press backspace, I wonder if that would delete all those 3-line chunks...

It does have such a dialogue but VSCode's identically named "Delete" option has a nearly identical warning dialogue that moves the file to the trash instead.

Zed's dialogue just says "Delete file.txt?" so if you're used to VSCode it's very easy to skip through that dialogue reflexively.

> If there is such a dialog

Just checked, there is a modal dialog that reads:

    *Delete "asd"?*

    (Cancel) (Delete)

Undo works for editing. Just not (apparently) file deletion.

To clarify, you can't Ctrl+Z immediate deletion of a file (skipping the Recycle Bin/Trash). You can undo other stuff, of course.

That's a bit dramatic, isn't it? Zed is still fairly new and although it's not perfect, they're doing quite a good job so far.

I would be using Zed full time if Sublime Text wasn't already perfect for me.

Zed is pretty awesome on macOS and Linux, but I tried the Windows version tonight and things that work great on the other OSes aren't working on Windows. I've noticed:

- Issues with various keybinds not working as expected, e.g. Ctrl+S to save works on my Linux machines but not Windows if Vim Mode is enabled

- Issues with LSPs/diagnostics not working on Windows the same way they work on macOS/Linux

- The terminal holds a lot of assumptions about how the system works that don't hold true on Windows, e.g. "the user has one shell they use for all things" or "setting environment variables in the OS is easy"

I love Zed on my work issued macbook and use it full time, but the Windows version still needs some work.

Windows has undo for Delete, however. You have to press Shift to delete permanently, and then you also get a confirmation prompt.

I'm glad there's finally some progress in that direction. If they actually implement subpixel RGB anti-aliasing, it would definitely be worth considering as an alternative. It's been surprising to see so many people praise Zed when its text rendering (of all things) has been in such a state for so long.

That "after" image is still rendered with greyscale AA rather than subpixel, but whatever they changed did make it more legible at least.

Spitballing here, but subpixel rendering also requires integration with the rendering pipeline, specifically that you have the infrastructure to pass fractional offsets to the rasterization engine based on the concrete screen position of a glyph, and that the glyph atlas is a full RGBA texture (not just an alpha texture), and that the rasterizer knows about the particular texture format (RGBA vs BGRA etc.)

If they’re like egui, they may render to a font atlas which complicates subpixel-AA.

> Windows' awful font rendering

Just be aware that half the population prefers Windows font rendering.

The only IDE I have used where frame rate is noticeable was Visual Studio (not Code).

Once you are beyond a bare minimum, every other speed metric is more important. Zed does really well on many of those, but some depend on the LSP, so they become the bottleneck quickly.

It is 18% according to this story: https://www.tomshardware.com/laptops/projections-show-that-a...

> you might be used to waiting 100 ms for a character you typed to appear.

The latest benchmark I could find is 2022 and it's nowhere as bad as you claim

https://github.com/microsoft/vscode/issues/161622#issuecomme...

You literally can’t tell the difference in a 20ms delay. That is an order of magnitude lower than the neural feedback loop latency. You may think that you can, but studies don’t back this up.

This is one of those things that make me question whether I experience the world fundamentally differently than many of you.

I have never, ever felt “latency” in editor UI. Any editor UI. It’s editing text for Pete’s sake. I can only type so fast, or read so fast.

That's an interesting take. For whatever reason, frame rate is not one of my complaints about existing editors such as Emacs, VS Code, etc.

It's expected for editors to have non-perceivable latency. It's just text, how hard can it be.

I think the claim is more that an editor is supposed to have an arbitrary good frame rate.

Ubiquity is pretty important when you're going to invest in learning a new editor. This is one of the advantages of vim for example. It is available everywhere... linux, windows, terminal, gui, etc.

No, but I am remoted in to my dev box (over RDP/mstsc).

I assume it is not an issue with other applications like Chrome or VSCode (I mean VSCode is Chrome). They usually have some sort of fallback rendering on these environments that work well enough.

It may not be an actual problem with zed either, despite the warning.

I also get that message when opening Zed in a VM. The performance is not actually awful, I can use it just fine.

Maybe it's misdetecting something? I used to use Remote Desktop for game development sometimes, as weather could make the journey to the office impossible, and the performance was always pretty ok, even with UE5 stuff making heavy use of Nanite running at 1440p.

And if it was actually software emulated, which I can't believe for a moment, though I admit I never checked (I just always assumed the window contents were transmitted via some kind of video encoder) - then I can't imagine that a text editor would be a problem.

The input latency might not be as good as you'd like.

It has a huge amount of treesitter modules, etc., statically compiled into the executable. They're not all loaded the instant you fire it up.

Size on disk is about 64x less relevant than size in RAM for me. To give Zed some credit in this area, it's statically linked and the Linux binary is half the size as the Windows one.

considering how cheap storage is nowadays nitpicking about binary size is a very weird take. Are you editing code on an esp32?

https://github.com/zed-extensions/tsgo does exactly this

I've heard that VSCode gets some special treatment and integrations with the typescript server that go deeper than normal LSP

As the owner of a somewhat popular language, I checked to see if there's an extension available (there is!) as we publish a language server.

One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug.

EDIT - commented on the tsserver thread here: https://github.com/zed-industries/zed/issues/18698#issuecomm...

You could have an lsp server of infinite speed, but that wouldn't help one bit if the bottleneck is how the client deals with the messaging.

The specific techniques used to send, receive, and parse JSON could matter.

VSCode's TypeScript service does not currently use LSP, and many language queries run in the same thread as the extension (or "Extension Host"). That does not necessarily explain the performance difference though

Are you saying that VSCode runs tsserver in its own NodeJS process? Or are you saying that VSCode uses the NodeJS it ships to run tsserver in a different process?

That option is either not explained well, or not what OP was really asking for. It doesn't specify what's the default behaviour for extensions that are neither explicitly enabled, nor disabled. It also doesn't say how to disable everything apart from some set of extensions.

Extensions to me mean something that I explicitly choose to install (regardless of whether they automatically update). As far as I can tell, Zed goes about downloading code (“extensions”?) invisibly with no user input. See, for example, https://github.com/zed-industries/zed/issues/12589

> or you have an "official" extension manager that rolls out an update every next year

As a debian user, sign me up!

They clearly just want the option to say yes/no to the downloads, hence the use of the word "nonconsensual".

Seems like a reasonable ask.

If you open a .cpp file it will silently download clangd in the background. Same is true for other language servers AFAIK.

I think I got as far as installing the Visual Studio Installer so I could install Visual Studio and I just bailed on that whole thing, lol. I'll have to take some time out on a weekend to take another look :)

In vscode you can click on various assets, like images or audio files, and then view them right inside vscode. If you work with datasets, the ability to inspect them is crucial.

Yes ofc I can use Finder instead but in vscode I just cmd+p.

Was a heavy sublime user for many years, slowly migrated to vim (first sublime with vim keybindings) but now daily drive lazyvim and the defaults with that are very sane.

Quick install on any platform and just works. And obviously plenty of configuration that’s available to you but if you haven’t I’d give that a go.

I also use Sublime heavily and then started with Zed for the AI assistance.

When they say $600 they probably mean brand new pricing.

Last I checked, cheapest MacBook is $999+ for the air.

Soon https://github.com/microsoft/winget-pkgs/pull/303728

For Zed user, yes. They don't care (I too, didn't use Windows for years, but Windows is popular is a fact, not opinion).

What I meant was there are so many problems with Windows that the team cannot do it quickly (they post about it before: https://zed.dev/blog/windows-progress-report).

Just surprised, as I thought building GUI app on Windows must be easy right, as must be libs/frameworks already available to support that? It's just not.

It is, based on Stack Overflow survey: https://survey.stackoverflow.co/2025/technology#most-popular... Couldn't find a way to access Statista report.

It obviously varies a lot by the preferred languages, but Windows is still at the top, on average.

Only if they happen to be UNIX programmers.

Turns out there are plenty of other jobs as programmers.

Excuse me, can you read what I wrote? I didn't say zed editor is bad, I just said that zed's PREDICT EDIT isn't good enough, or at least it shouldn't charge for it.