Just wanted to mention that some basic Windows-OS keyboard shortcuts don't work, like ALT+F to open the File menu. Also things like ALT+SPACEBAR to bring up the system context menu for the focussed window (the menu with maximise, minimise, close options etc.) do not seem to work. I'm guessing with the DirectX rendering backend, the 'app' is rendered more akin to a video game than a native win32 process.
Also after install, the install directory takes up 400MB+. Even VSCode only takes up around 380MB. I believe it when they say it's not an Electron app, but I do wonder what's being packed in there. I was always under the impresion that Rust apps are pretty lightweight, but that install size is nearing Java levels of binary/dependency bloat.
> I believe it when they say it's not an Electron app, but I do wonder what's being packed in there
Half of Electron namely Node.js. As majority of lsp are .js based. Also extensions are WASM. Also VS Code keeps extensions in separate config directory, while Zed in main directory.
I say "strangely" because honestly it just seems large for any application. I thought they might not be doing LTO or something but they do thin LTO. It's just really that much code.
> The world moved into dynamic linking in the 1980's for a reason.
Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.
Storage doesn't really feel cheap. I'm considering buying a new laptop, and Apple charges $600 per TB. Sure, it's cheaper than it was in the '80s, but wasting a few gigabytes here and a few gigabytes there is quickly enough to at least force you to go from a 500GB drive to a 1TB drive, which costs $300.
> I was always under the impresion that Rust apps are pretty lightweight
Maybe compared to electron, but binary size is an issue with any nontrivial rust application. Due to how cargo works, it compiles and bundles in every dependency in world.
I've been using Zed primarily for months but I just switched back to VSCode for 2 reasons, one of which is kinda my fault and the other it's unclear where the fault is.
1. I deleted a few hours of work because I was late night coding and I decided to rename a file before check-in and delete the old version. Well I renamed it and Right-Click -> Deleted the new version by accident.
It turns out Zed has both "Delete" and "Trash" right next to each other in its right-click menu. Delete skips the trash and Zed does not implement Ctrl+Z yet, so unless you have a backup that file is gone. Because I renamed it and had not yet checked in it wasn't in version control yet.
2. For some reason a particular crate in my Rust workspace wasn't having errors and warnings show up in the editor. I messed with configuration a bunch and couldn't figure it out, so I tried VSCode and it just worked without any additional configuration.
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.
Have they implemented subpixel font rendering by now? I remember that being a sticking point when it came to Linux because they had designed their custom UI renderer around the Macs ubiquitous HiDPI displays, leading to blurry fonts for the much, much larger proportion of Linux (and Windows) users who still use LoDPI displays.
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.)
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.
> The Windows build uses DirectX 11 for rendering, and DirectWrite for text rendering, to match the Windows look and feel.
As I understand, DirectWrite font rendering uses Windows subpixel font rendering. It seems OK on my monitor (better than the linux version) but haven't done any pixel peeping.
They seem to have anticipated this issue and designed it accordingly!
I tried it out on macOS and have a 1440p external monitor that the fonts just look horrible on. Looks fine on the laptop's "retina" display but blurry enough every else that it actually gave me a headache after a few hours.
I installed Zed and tested out a bunch of fonts on my 1440p monitor. It looks decent, but not great. I think that's more a byproduct of Windows' awful font rendering in general though moreso than a Zed specific problem. VSCode is no better.
Seems like the only way to get high quality font rendering these days is a 4k+ display.
Zed looks and feels amazing to use. I test-drove it for a bit on my linux system, and the feel of it is difficult to convey to those who have not tried it yet. It's easy to overlook the significance of gpu accelerated editor - but I promise you, use it for a bit and you'll be sold.
The only feature that is preventing me from switching to Zed is the current lack of DevContainer support[1]. After investing a significant amount of time perfecting a devcontainer (custom fat image with all tools/libs + config), it would be a large step backwards to go back to installing everything locally.
There's a lot of eyes on this feature, so I'm hopeful it will be implemented in the future.
Unfortunately, I tried to use zed as my daily driver, but the typescript experience was subpar. While the editor itself was snappy, LSP actions like "jump to declaration" were incredibly slow on our codebase compared to VS Code / Cursor.
I had the same experience and the same outcome. Zed was super fast for editing but slow for rich features, which on the net slowed me down compared with VSCode
Well exactly, I'm pretty sure that's what the GP is getting at — it would be a surprise if Rust didn't have good JSON support. Which it does. So it's unlikely to be the bottleneck.
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.
Every Unity game ships with three UI frameworks (IMGUI, UGUI, UI Elements) built-in, in addition to everything else the game engine supports, and the engine is only about 50 MB.
Yes. Zed is snappy in a way that makes my copy of Sublime Text 3 feel slow. Compared to VSC it feels like going from a video game at 40 FPS with 2-3 frames of input lag to 120 FPS.
Why don't you actually do some considering how mistaken this superficial dismissal is: storage is not cheap where it matters - for example, your laptop's main drive. It doesn't help you that an external hard drive can be purchased cheaply since you won't be able conveniently upgrade your main mobile system. Also, the size of various used content (games/photos /videos) has increased a lot, leaving constrains on storage in place despite the price drop.
I just refuse to use any software that baloons it's filesize. Not because I can't afford storage, but because there are always alternatives that have similar features and packed into fraction (usually less than 1%) of filesize. If one of them can do it and other can't, it's a bad product, that I have no intention to support.
We should strive to write better software that is faster, smaller and more resilient.
"Storage is cheap" is a bad mentality. This way of thinking is why software only gets worse with time: let's have a 400mb binary, let's use javascript for everything, who needs optimization - just buy top of the shelf super computer. And it's why terabytes of storage might not be enough soon.
I can empathize with how lazy some developers have gotten with program sizes. I stopped playing CoD because I refused to download their crap 150+ GB games with less content than alot of other titles that are much smaller.
That said, storage is cheap, it's not a mentality but a simple statement of fact. You think zed balloons their file sizes because the developers are lazy. It's not true. It's because the users have become lazy. No one wants to spend time downloading the correct libraries to use software anymore. We've seen a rise in binary sizes in most software because of a rise in static linking, which does increase binary size, but makes using and testing the actual software much less of a pain. Not to mention the benefits in reduced memory overhead.
VSCode and other editors aren't smaller because the developers are somehow better or more clever. They're using dynamic linking to call into libraries on the OS. This linking itself is a small overhead, but overhead none-the-less, and all so they can use electron + javascript, the real culprits which made people switch to neovim + zed in the first place. 400mb is such a cheap price to pay for a piece of software I use on a daily basis.
I'm not here to convince you to use Zed or any editor for that matter. Use what you want. But you're not going to somehow change this trend by dying on this hill, because unless you're working with actual hardware constraints, dynamic linking makes no sense nowadays. There's no such thing as silver bullet in software. Everything is a tradeoff, and the resounding answer has been people are more than happy to trade disk space for lower memory & cpu usage.
[Window Title]
Critical
[Main Instruction]
Unsupported GPU
[Content]
Zed uses DirectX for rendering and requires a compatible GPU.
Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.
For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.
[Skip] [Troubleshoot and Quit]
That's more of an issue with your system than an issue with Zed, you have to veer pretty far from the beaten path to not have proper DirectX nowadays. Are you running Windows in a VM?
Maybe try gaming-oriented remote desktop tools, like steam link or sunshine/moonlight. Those work great with directx, assuming you have a working gpu (at least integrated gpu) on your remote box. They also have way better latency, though use a lot more bandwidth.
By explaining the advantages over "older" methods. A lot of people use Moonlight/Sunshine for non gaming related stuff, specially considering than the alternatives are all proprietary.
They're productivity tools, not gaming software. You'll be faster and deal with less errors using the correct optimized remote desktop tool for your job, versus what you're using now, which can be slow and error prone.
Sunshine and Moonlight are no more than accelerated and finely tuned VNC servers that happen to be targeted at gaming. You can totally set them up as a regular remote desktop solution.
My post was answering the question of how they should ask for permission to use it. You pitch it as productivity software that helps you do your job better.
If no monitor is connected then RDP doesn't load gpu drivers. It can also make RDP performance much worse as HW accelerated video encoding is not working
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.
Zed is awesome. It does everything I need. I easily find everything I'm looking for. It's fast, and I can use forked CLI terminals from the IDE via ACP mode. This means Cerebras and Qwen code 480b for super fast and cheap incredibly smart CLI agents.
Technically, Zed's Super Compete will almost never catch up with Cursor, or even as good as the free Windsurf.
If you look a little closer, you will see that the cursor and cursor completion requests are not initiated by the editor itself, which only interacts with the lsp.
Yes. They all come with an LSP, taking free windsurf as an example, when windsurf starts, it will start a process in /Applications/Windsurf.app/Contents/Resources/app/extensions/windsurf/bin/languageservermacosarm, This process is responsible for syntactic analysis of the current code's workspace and then local indexing. The editor communicates with LSP through localhost encoding through protobuf, including the current cursor, currently open tabs, recently viewed files, etc.
The LSP calculates locally based on this information, and if the inference cannot be completed locally, it will automatically extract the necessary information to interact with the server-side LLM. This ensures the intelligence of Super Complete.
However, ZED's Super Complete does not have an LSP. Instead, it interacts directly with the server, which runs a zeta model. This pattern is not smart, takes up a lot of bandwidth and more useless context, and lacks more useful information due to the lack of LSP support.
I hope my technical interpretation above will give you an understanding of why zed's super complete is technically backward. And, since ZED's LSP is configured by a third party, ZED itself does not offer its own languageserver, unless ZED is developing it now, but this is obviously difficult.
In this case, I don't understand why zed would charge for a feature that is clearly lagging behind.
You have to ask me why I know so much about this, because I am a member of Cursor, but I want a Zed Editor, so I want to customize an endpoint I developed by ZEDPREDICTEDITS_URL, relay requests to Cursor, to achieve powerful completion with Cursor in Zed. Obviously, it failed in the end. The above mentioned is the reason for the failure.
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.
I build Zed for Windows aarch64 from source -- works great, though the build process is quite slow on my 16GB Surface Pro. Definitely hoping for official binaries, though!
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 :)
I watched the video on the home page and thought it is weird that they spend an inordinate amount of time on frame rate. Who picks an editor based on frame rate?
If you want to talk about perf in the context of a text editor show me how big of a file you can load--especially if the file has no line breaks. Emacs has trouble here. If you load a minified js file it slows to a crawl especially if syntax highlighting is on. Also show me how fast the start up time is. This is another area where Emacs does not do well.
So Zed is available on Windows--but only if you have a x64 processor. Lots of people run Windows on Arm64 and I don't see any mention of Arm64. This is where the puck is heading.
High frame rates (low frame times, really) are essential to responsiveness which, for those who appreciate it, is going to make much more of a difference day to day than the odd hiccup opening a large file (not that zed does have that issue, I wouldn't know as I haven't tried opening something huge).
You probably do. Many people just never notice that. It's not about typing or reading fast either, it's just about how it feels. Typing into something with shitty latency feels like dragging my fingernails across a chalkboard.
It's the same with high dpi monitors. Some people (me included) are driven absolutely insane by the font rendering on low density monitors, and other people don't even notice a difference.
Honestly, consider yourself blessed. One less thing in the world to annoy you.
It's not just frame rate, but also input delay. If you're using Visual Studio Code, you might be used to waiting 100 ms for a character you typed to appear. My personal workflow is based on Kitty and Neovim, which I've configured so that it can launch within 20 ms. Working without any input delay allows me to explore and edit projects at typing speed. As such, even tiny delays really bother me and make me lose my flow. I would believe Zed's focus on performance is motivated similarly.
Also, I do not believe Windows on Arm64 is a very large demographic? Especially for developers, unless they're specifically into that platform.
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.
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.
> At the most sensitive, our findings reveal that some perceive delays below 40 ms. However, the median threshold suggests that motorvisual delays are more likely than not to go undetected below 51-90 ms.
By this study's numbers, 20ms is somewhat below the lower limit of ~40ms, but not too far below. 100ms would be easily perceivable - though, based on the other replies, it seems that VS Code does not actually have that much latency.
Don't confuse this with human reaction time, which is indeed an order of magnitude higher, at over 200ms. For one thing, reaction time is based on unpredictable events, whereas the appearance of keystrokes is highly predictable. It's based on the user's own keypresses, which a touch typer will usually have subconsciously planned (via muscle memory) several characters in advance. So the user will also be subconsciously predicting when the text will appear, and can notice if the timing is off. Also, even when it comes to unpredictable events, humans can discern, after the fact, the time difference between two previous sensory inputs (e.g. between feeling a keyboard key press down and seeing the character on screen), for much shorter time differences than the reaction time.
Of course, just because these levels of latency are perceptible doesn't mean they're a material obstacle to getting work done. As a relatively latency-sensitive person, I'm not sure whether they're a material obstacle. I just think they're annoying. Higher levels of latency (in the hundreds of ms) can definitely get in the way though, especially when the latency is variable (like SSH over cellular connections).
Yeah. The Steam survey isn't a perfect sample since it's skewed towards gamers, but that currently shows just 0.08% of Windows users are on ARM, while 81.5% of Mac users are on ARM.
That may be true if you're looking at all windows computers in existence. If you look at new laptops being sold you see different numbers. As of 2025, Arm processors hold about 13% to 20% of the market share for new Windows laptops. This is important because these are the people who are more likely to download and install your software.
Me! Frame rate and input latency are very important for a tool I use for hours every day. Obviously that's not the only feature I look for in an editor but if an editor _doesn't_ have it, I skip it. I also try to work on devices with 120Hz displays and above these days.
This always makes me laugh. The editor was barely announced two years ago. They've built it from the ground up with native support now for three different operating systems. They're experimenting with some cool new features, and even though I don't care about it I've heard their AI integration is pretty damn good.
But waaaaah they don't support a processor that accounts for probably less then 10% of Windows Machines
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.
I am using nightly on Windows and startup time is very slow. It can take 10 seconds to boot up. To quickly edit random files, I would open notepad++ or simple notepad instead, which isn't what I expected from Zed.
I installed the beta a week or two ago. Many of the files I tried opening in it just did not work at all. It can only open utf-8 encoded files.
That is not a problem for code, but if you just want to open some random .txt file or .csv file, these are often enough not utf-8 encoded, especially if they contain non English text.
The github issue for this is showing progress, but I think it's a mistake to promote the editor to stable as is.
I tried it for a bit. But unless you want to use their choice of lsp/linter/whatever from what you are used to, then you will waste even more time customising zed to your needs from your previous solution.
Is this something like Sublime? Light/responsive editor for one-off files? But maybe with some better introspection? That would fill a niche for me; trying it. FYI download+install is the smoothest experience of any software I've loaded recently I didn't build myself. Going to daily-drive it for a bit and see what's up; promising!
as a 10+ year Sublime user, Zed is the best of the more "modern" GUI editors I've tried.
I haven't fully switched over to using it as my daily-driver because Zed's heavy reliance on GPU rendering means that it locks up every time I suspend & resume my Linux box [0,1] but I'm optimistic about the progress they're making on it.
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.
Tried zed, it's interesting but several things are missing including the ability to skip extensions auto-update... which imho is critical for security.
I switched from VSCode to Zed as my "I just need to edit this 1 little text file" app because VSCode was way too spammy. Every time I open it it wants to update something or complain about some extensions or complain that I had a file open and now it MUST close it because heaven forbid I open two things at once.
I hope Zed stays clean. We'll see. So far so good. Was quite happy they had a JetBrains base hotkey setup. Had to add a few of my own but I could pretty easily, nothing missing so far.
> winget search zed
Name Id Version Match Source
-----------------------------------------------------------------------------------------------------------------------
Zed Preview ZedIndustries.Zed 0.208.4-pre Moniker: zed winget
I don't use windows, but this is good development as all platforms should be present for editors to be worth using. I am happy Zed user since long time, I am happy it had kept with out demands, with adding AI, Git etc.
Also integration of cli tools into AI is excellent and really refreshing.
First, you should fix fundamental operations on Mac and other distributions - for example when you stash or perform operations on files from other tools, it will put the state out of sync.
You can build the most beautiful and fastest IDE, but with this bugs, it’s useless
Just wanted to mention that some basic Windows-OS keyboard shortcuts don't work, like ALT+F to open the File menu. Also things like ALT+SPACEBAR to bring up the system context menu for the focussed window (the menu with maximise, minimise, close options etc.) do not seem to work. I'm guessing with the DirectX rendering backend, the 'app' is rendered more akin to a video game than a native win32 process.
Also after install, the install directory takes up 400MB+. Even VSCode only takes up around 380MB. I believe it when they say it's not an Electron app, but I do wonder what's being packed in there. I was always under the impresion that Rust apps are pretty lightweight, but that install size is nearing Java levels of binary/dependency bloat.
> I believe it when they say it's not an Electron app, but I do wonder what's being packed in there
Half of Electron namely Node.js. As majority of lsp are .js based. Also extensions are WASM. Also VS Code keeps extensions in separate config directory, while Zed in main directory.
A 400mb+ install of bloat will upset many people
This needs to be justified asap to help people understand and reconsider installing it.
Strangely it's the actual binary's .text section that's about 400MB. Time to dive in!
Welcome to static linking of large applications.
The world moved into dynamic linking in the 1980's for a reason.
It is cool to advocate for a return to static linking when it is basic CLI tools.
I say "strangely" because honestly it just seems large for any application. I thought they might not be doing LTO or something but they do thin LTO. It's just really that much code.
> The world moved into dynamic linking in the 1980's for a reason.
Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.
Storage doesn't really feel cheap. I'm considering buying a new laptop, and Apple charges $600 per TB. Sure, it's cheaper than it was in the '80s, but wasting a few gigabytes here and a few gigabytes there is quickly enough to at least force you to go from a 500GB drive to a 1TB drive, which costs $300.
Yet everyone is complaining on this thread about Zed distribution size, go figure.
They should shut up and just buy bigger drives. Ah, they can't on their laptops, bummer.
Also try to develop mobile apps with that mentality,
https://www.abbacustechnologies.com/why-your-app-keeps-getti...
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.
So the upgrades are not delta diffs either?
Just so others here know, it’s possible to have a graphics context and a Win32 menu bar in the same window.
> I was always under the impresion that Rust apps are pretty lightweight
Maybe compared to electron, but binary size is an issue with any nontrivial rust application. Due to how cargo works, it compiles and bundles in every dependency in world.
400MB is unnecessarily large though.
I've been using Zed primarily for months but I just switched back to VSCode for 2 reasons, one of which is kinda my fault and the other it's unclear where the fault is.
1. I deleted a few hours of work because I was late night coding and I decided to rename a file before check-in and delete the old version. Well I renamed it and Right-Click -> Deleted the new version by accident.
It turns out Zed has both "Delete" and "Trash" right next to each other in its right-click menu. Delete skips the trash and Zed does not implement Ctrl+Z yet, so unless you have a backup that file is gone. Because I renamed it and had not yet checked in it wasn't in version control yet.
2. For some reason a particular crate in my Rust workspace wasn't having errors and warnings show up in the editor. I messed with configuration a bunch and couldn't figure it out, so I tried VSCode and it just worked without any additional configuration.
This is like when the macOS touchbar was a thing, if I recall correctly, in the commit management menu, cancel was right next to force push.
How can people justify using editors like this when they are missing basic features?
Like what's the benefit?
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.
Have they implemented subpixel font rendering by now? I remember that being a sticking point when it came to Linux because they had designed their custom UI renderer around the Macs ubiquitous HiDPI displays, leading to blurry fonts for the much, much larger proportion of Linux (and Windows) users who still use LoDPI displays.
I am confused about this. Doesn't Zed use CoreText on MacOS just as they use DirectWrite on windows. Shouldn't MacOS CoreText handle all this ?
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.)
You don't _need_ fractional offsets no?
If they’re like egui, they may render to a font atlas which complicates subpixel-AA.
Idk about subpixel font rendering, but font rendering on Linux looks massively better after a patch last week: https://github.com/zed-industries/zed/issues/7992#issuecomme...
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.
Tbh though, is subpixel text rendering really all that important anymore when high resolution monitors are common now and low-dpi is the exception?
Yea, I tried to give it a go on Fedora, but the terrible text rendering made it a insta-delete, for me.
ok for what reason we need sub-pixel rgb anti aliasing here???? does we run game engine for code??
Subpixel antialiasing of fonts is a pretty standard feature for a few decades. Without it, text can look fuzzy on certain displays.
> does we run game engine for code??
Zed literally does this; they render their UI using a graphics library just like a video game.
That "after" image is still rendered with greyscale AA rather than subpixel, but whatever they changed did make it more legible at least.
> The Windows build uses DirectX 11 for rendering, and DirectWrite for text rendering, to match the Windows look and feel.
As I understand, DirectWrite font rendering uses Windows subpixel font rendering. It seems OK on my monitor (better than the linux version) but haven't done any pixel peeping.
They seem to have anticipated this issue and designed it accordingly!
I tried it out on macOS and have a 1440p external monitor that the fonts just look horrible on. Looks fine on the laptop's "retina" display but blurry enough every else that it actually gave me a headache after a few hours.
I installed Zed and tested out a bunch of fonts on my 1440p monitor. It looks decent, but not great. I think that's more a byproduct of Windows' awful font rendering in general though moreso than a Zed specific problem. VSCode is no better.
Seems like the only way to get high quality font rendering these days is a 4k+ display.
No lol
Zed looks and feels amazing to use. I test-drove it for a bit on my linux system, and the feel of it is difficult to convey to those who have not tried it yet. It's easy to overlook the significance of gpu accelerated editor - but I promise you, use it for a bit and you'll be sold.
The only feature that is preventing me from switching to Zed is the current lack of DevContainer support[1]. After investing a significant amount of time perfecting a devcontainer (custom fat image with all tools/libs + config), it would be a large step backwards to go back to installing everything locally.
There's a lot of eyes on this feature, so I'm hopeful it will be implemented in the future.
[1] https://github.com/zed-industries/zed/issues/11473
Any chance you'd be willing to share more about your custom dev container?
What does having a DevContainer get you?
I’m all for documenting every bit of my setup, but beyond that…
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.
That's quite unnecessary. You could just mount "all tools and services" from your base system without the complicated Dockerfile: https://blog.gpkb.org/posts/ai-agent-sandbox/
It works with devpods
Unfortunately, I tried to use zed as my daily driver, but the typescript experience was subpar. While the editor itself was snappy, LSP actions like "jump to declaration" were incredibly slow on our codebase compared to VS Code / Cursor.
Electron compiles NodeJS with v8's pointer compression which leads to an up to 50% decrease in memory usage, and might speed it up too.
I had the same experience and the same outcome. Zed was super fast for editing but slow for rich features, which on the net slowed me down compared with VSCode
That doesn't make sense, they both use tsserver under the hood.
I've heard that VSCode gets some special treatment and integrations with the typescript server that go deeper than normal LSP
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.
Could, ya, but I'd be pretty impressed and sad if Rust didn't have really good JSON parsers/serializers by now.
What do you mean? It has exceptionally good crates for that, and has for more than a decade. Is there something you feel is missing?
Well exactly, I'm pretty sure that's what the GP is getting at — it would be a surprise if Rust didn't have good JSON support. Which it does. So it's unlikely to be the bottleneck.
It’s had them for a very long time, pre-1.0.
It's extremely refreshing to see the editor's memory and processor usage be smaller than the webapp tab I'm working on.
I'm really liking it thus far!
Just be sure about that because zed fires up node as well for lsp.
Its binary is half a gig in size, so just like a browser, nothing fresh about that.
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.
What could they be statically linking to have a 400MB executable?
A tonne of treesitter grammars
They wrote their own graphics renderering library for starters, that's bundled into the editor when compiled.
https://www.gpui.rs/
Every Unity game ships with three UI frameworks (IMGUI, UGUI, UI Elements) built-in, in addition to everything else the game engine supports, and the engine is only about 50 MB.
Is that really necessary for an ide? Seems like a ton of added complexity for little to no trade off or even a downside considering...
Yes. Zed is snappy in a way that makes my copy of Sublime Text 3 feel slow. Compared to VSC it feels like going from a video game at 40 FPS with 2-3 frames of input lag to 120 FPS.
You can read about it here:
https://zed.dev/blog/videogame
The OS loads the entire binary into RAM.
It loads on demand, and pages you don't use don't need to be on RAM
considering how cheap storage is nowadays nitpicking about binary size is a very weird take. Are you editing code on an esp32?
I keep hearing this since I've got my first Pentium 1 PC, that storage is cheap.
Why don't you actually do some considering how mistaken this superficial dismissal is: storage is not cheap where it matters - for example, your laptop's main drive. It doesn't help you that an external hard drive can be purchased cheaply since you won't be able conveniently upgrade your main mobile system. Also, the size of various used content (games/photos /videos) has increased a lot, leaving constrains on storage in place despite the price drop.
RAM is not cheap. Executables live in RAM when running.
Executables lives in pages of RAM and not all pages are in physical memory at once.
No, they're mmapped to RAM. Only the pages that get used are loaded to RAM.
Only the parts that are being used (the working set).
I just refuse to use any software that baloons it's filesize. Not because I can't afford storage, but because there are always alternatives that have similar features and packed into fraction (usually less than 1%) of filesize. If one of them can do it and other can't, it's a bad product, that I have no intention to support.
We should strive to write better software that is faster, smaller and more resilient.
"Storage is cheap" is a bad mentality. This way of thinking is why software only gets worse with time: let's have a 400mb binary, let's use javascript for everything, who needs optimization - just buy top of the shelf super computer. And it's why terabytes of storage might not be enough soon.
I can empathize with how lazy some developers have gotten with program sizes. I stopped playing CoD because I refused to download their crap 150+ GB games with less content than alot of other titles that are much smaller.
That said, storage is cheap, it's not a mentality but a simple statement of fact. You think zed balloons their file sizes because the developers are lazy. It's not true. It's because the users have become lazy. No one wants to spend time downloading the correct libraries to use software anymore. We've seen a rise in binary sizes in most software because of a rise in static linking, which does increase binary size, but makes using and testing the actual software much less of a pain. Not to mention the benefits in reduced memory overhead.
VSCode and other editors aren't smaller because the developers are somehow better or more clever. They're using dynamic linking to call into libraries on the OS. This linking itself is a small overhead, but overhead none-the-less, and all so they can use electron + javascript, the real culprits which made people switch to neovim + zed in the first place. 400mb is such a cheap price to pay for a piece of software I use on a daily basis.
I'm not here to convince you to use Zed or any editor for that matter. Use what you want. But you're not going to somehow change this trend by dying on this hill, because unless you're working with actual hardware constraints, dynamic linking makes no sense nowadays. There's no such thing as silver bullet in software. Everything is a tradeoff, and the resounding answer has been people are more than happy to trade disk space for lower memory & cpu usage.
Does static linking really reduce memory and cpu usage significantly compared to dynamic linking?
That's more of an issue with your system than an issue with Zed, you have to veer pretty far from the beaten path to not have proper DirectX nowadays. Are you running Windows in a VM?
No, but I am remoted in to my dev box (over RDP/mstsc).
If you're using it via RDP then you won't notice any rendering performance issues since RDP itself has terrible rendering performance.
Maybe try gaming-oriented remote desktop tools, like steam link or sunshine/moonlight. Those work great with directx, assuming you have a working gpu (at least integrated gpu) on your remote box. They also have way better latency, though use a lot more bandwidth.
How am I supposed to ask for permission from IT to install Steam or gaming related tools like Moonshine just to use a code editor?
By explaining the advantages over "older" methods. A lot of people use Moonlight/Sunshine for non gaming related stuff, specially considering than the alternatives are all proprietary.
They're productivity tools, not gaming software. You'll be faster and deal with less errors using the correct optimized remote desktop tool for your job, versus what you're using now, which can be slow and error prone.
> Moonlight
> Open source game streaming client
> Moonlight allows you to play your PC games on almost any device
OK, fine, maybe Sunshine will be different.
> Sunshine is a self-hosted game stream host for Moonlight.
Maybe not.
Sunshine and Moonlight are no more than accelerated and finely tuned VNC servers that happen to be targeted at gaming. You can totally set them up as a regular remote desktop solution.
My post was answering the question of how they should ask for permission to use it. You pitch it as productivity software that helps you do your job better.
Every part of this sentence made me so sad.
Your company trusts you to write code but not run code?
It is for protection against rootkits, not to be nanny to the employees.
It's a free Parsec alternative.
If no monitor is connected then RDP doesn't load gpu drivers. It can also make RDP performance much worse as HW accelerated video encoding is not working
What does a text editor have to do to achieve >>awful performance<< when software rendering?
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.
I also get that message when opening Zed in a VM. The performance is not actually awful, I can use it just fine.
Nice but too little/too late, already switched to Linux - where Zed already works great!
Zed is awesome. It does everything I need. I easily find everything I'm looking for. It's fast, and I can use forked CLI terminals from the IDE via ACP mode. This means Cerebras and Qwen code 480b for super fast and cheap incredibly smart CLI agents.
Technically, Zed's Super Compete will almost never catch up with Cursor, or even as good as the free Windsurf. If you look a little closer, you will see that the cursor and cursor completion requests are not initiated by the editor itself, which only interacts with the lsp. Yes. They all come with an LSP, taking free windsurf as an example, when windsurf starts, it will start a process in /Applications/Windsurf.app/Contents/Resources/app/extensions/windsurf/bin/languageservermacosarm, This process is responsible for syntactic analysis of the current code's workspace and then local indexing. The editor communicates with LSP through localhost encoding through protobuf, including the current cursor, currently open tabs, recently viewed files, etc. The LSP calculates locally based on this information, and if the inference cannot be completed locally, it will automatically extract the necessary information to interact with the server-side LLM. This ensures the intelligence of Super Complete. However, ZED's Super Complete does not have an LSP. Instead, it interacts directly with the server, which runs a zeta model. This pattern is not smart, takes up a lot of bandwidth and more useless context, and lacks more useful information due to the lack of LSP support. I hope my technical interpretation above will give you an understanding of why zed's super complete is technically backward. And, since ZED's LSP is configured by a third party, ZED itself does not offer its own languageserver, unless ZED is developing it now, but this is obviously difficult. In this case, I don't understand why zed would charge for a feature that is clearly lagging behind. You have to ask me why I know so much about this, because I am a member of Cursor, but I want a Zed Editor, so I want to customize an endpoint I developed by ZEDPREDICTEDITS_URL, relay requests to Cursor, to achieve powerful completion with Cursor in Zed. Obviously, it failed in the end. The above mentioned is the reason for the failure.
Do either Windsurf or Cursor work well with local or no AI? One of the things I like about Zed is that it can, and is completely free.
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.
I have waited for this for months... but it's still only an x86_64 binary!
I love my ARM Surface Pro, and Zed would make a wonderful editor on this hardware. If anyone from Zed is reading this, please think about it!
I build Zed for Windows aarch64 from source -- works great, though the build process is quite slow on my 16GB Surface Pro. Definitely hoping for official binaries, though!
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 :)
For whatever reason, zed compilation on windows with msvc is extremely slow compared to the Linux counterpart.
https://github.com/rust-lang/rust/issues/145864 was opened because of the the discrepancy
I watched the video on the home page and thought it is weird that they spend an inordinate amount of time on frame rate. Who picks an editor based on frame rate?
If you want to talk about perf in the context of a text editor show me how big of a file you can load--especially if the file has no line breaks. Emacs has trouble here. If you load a minified js file it slows to a crawl especially if syntax highlighting is on. Also show me how fast the start up time is. This is another area where Emacs does not do well.
So Zed is available on Windows--but only if you have a x64 processor. Lots of people run Windows on Arm64 and I don't see any mention of Arm64. This is where the puck is heading.
Also noticed Emacs key binding is in beta still.
High frame rates (low frame times, really) are essential to responsiveness which, for those who appreciate it, is going to make much more of a difference day to day than the odd hiccup opening a large file (not that zed does have that issue, I wouldn't know as I haven't tried opening something huge).
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.
You probably do. Many people just never notice that. It's not about typing or reading fast either, it's just about how it feels. Typing into something with shitty latency feels like dragging my fingernails across a chalkboard.
It's the same with high dpi monitors. Some people (me included) are driven absolutely insane by the font rendering on low density monitors, and other people don't even notice a difference.
Honestly, consider yourself blessed. One less thing in the world to annoy you.
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 not just frame rate, but also input delay. If you're using Visual Studio Code, you might be used to waiting 100 ms for a character you typed to appear. My personal workflow is based on Kitty and Neovim, which I've configured so that it can launch within 20 ms. Working without any input delay allows me to explore and edit projects at typing speed. As such, even tiny delays really bother me and make me lose my flow. I would believe Zed's focus on performance is motivated similarly.
Also, I do not believe Windows on Arm64 is a very large demographic? Especially for developers, unless they're specifically into that platform.
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.
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.
Let's see.
https://web-backend.simula.no/sites/default/files/publicatio...
> At the most sensitive, our findings reveal that some perceive delays below 40 ms. However, the median threshold suggests that motorvisual delays are more likely than not to go undetected below 51-90 ms.
By this study's numbers, 20ms is somewhat below the lower limit of ~40ms, but not too far below. 100ms would be easily perceivable - though, based on the other replies, it seems that VS Code does not actually have that much latency.
Don't confuse this with human reaction time, which is indeed an order of magnitude higher, at over 200ms. For one thing, reaction time is based on unpredictable events, whereas the appearance of keystrokes is highly predictable. It's based on the user's own keypresses, which a touch typer will usually have subconsciously planned (via muscle memory) several characters in advance. So the user will also be subconsciously predicting when the text will appear, and can notice if the timing is off. Also, even when it comes to unpredictable events, humans can discern, after the fact, the time difference between two previous sensory inputs (e.g. between feeling a keyboard key press down and seeing the character on screen), for much shorter time differences than the reaction time.
Of course, just because these levels of latency are perceptible doesn't mean they're a material obstacle to getting work done. As a relatively latency-sensitive person, I'm not sure whether they're a material obstacle. I just think they're annoying. Higher levels of latency (in the hundreds of ms) can definitely get in the way though, especially when the latency is variable (like SSH over cellular connections).
I don't have to think a full thought for every keystroke.
Do you not perceive more than 50 Hz?
It is 18% according to this story: https://www.tomshardware.com/laptops/projections-show-that-a...
Most of that is macOS and ChromeOS, not Windows.
Yeah. The Steam survey isn't a perfect sample since it's skewed towards gamers, but that currently shows just 0.08% of Windows users are on ARM, while 81.5% of Mac users are on ARM.
That may be true if you're looking at all windows computers in existence. If you look at new laptops being sold you see different numbers. As of 2025, Arm processors hold about 13% to 20% of the market share for new Windows laptops. This is important because these are the people who are more likely to download and install your software.
> 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...
I ran it on VS Code and kitty recently:
https://news.ycombinator.com/item?id=45253927
https://news.ycombinator.com/item?id=45254054
> Who picks an editor based on frame rate?
Me! Frame rate and input latency are very important for a tool I use for hours every day. Obviously that's not the only feature I look for in an editor but if an editor _doesn't_ have it, I skip it. I also try to work on devices with 120Hz displays and above these days.
Yeah, Kate will choke on a large single line file. Its one of the very few issues I bump into from time to time.
This always makes me laugh. The editor was barely announced two years ago. They've built it from the ground up with native support now for three different operating systems. They're experimenting with some cool new features, and even though I don't care about it I've heard their AI integration is pretty damn good.
But waaaaah they don't support a processor that accounts for probably less then 10% of Windows Machines
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.
You mean... like a GUI editor that runs on Windows, Mac, and Linux?
I am using nightly on Windows and startup time is very slow. It can take 10 seconds to boot up. To quickly edit random files, I would open notepad++ or simple notepad instead, which isn't what I expected from Zed.
I installed the beta a week or two ago. Many of the files I tried opening in it just did not work at all. It can only open utf-8 encoded files.
That is not a problem for code, but if you just want to open some random .txt file or .csv file, these are often enough not utf-8 encoded, especially if they contain non English text.
The github issue for this is showing progress, but I think it's a mistake to promote the editor to stable as is.
I use this as Sublime replacement on my macOS. So far happy with it. Only use it as a general purpose text editor.
Okay, I may ocassionally do some code editing on it. But most of the time it's gotta be VSCode or vim/nvim.
I tried it for a bit. But unless you want to use their choice of lsp/linter/whatever from what you are used to, then you will waste even more time customising zed to your needs from your previous solution.
My work PC is a $600 laptop with an on-board GPU, will I notice a difference between this and Vscode?
$600 laptop can mean a Macbook with Apple Sillicon CPU in this day and age.
Is this something like Sublime? Light/responsive editor for one-off files? But maybe with some better introspection? That would fill a niche for me; trying it. FYI download+install is the smoothest experience of any software I've loaded recently I didn't build myself. Going to daily-drive it for a bit and see what's up; promising!
as a 10+ year Sublime user, Zed is the best of the more "modern" GUI editors I've tried.
I haven't fully switched over to using it as my daily-driver because Zed's heavy reliance on GPU rendering means that it locks up every time I suspend & resume my Linux box [0,1] but I'm optimistic about the progress they're making on it.
0: https://github.com/zed-industries/zed/issues/7940
1: https://github.com/zed-industries/zed/issues/23288
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.
Still on Sublime, and helix in terminal.
Tried zed, it's interesting but several things are missing including the ability to skip extensions auto-update... which imho is critical for security.
I still Sublime for quick text file changes and then Zed for programming/AI assisted tasks.
Nice to see. Will probably start using it over quick edits on Windows.
I'd like to properly give it a go one day due to the effort put into its vim keybindings, but until then I'll stick to neovim.
> Zed isn't an Electron app; we integrate directly with the underlying platform for maximal control.
Sounds great. Looking forward to doing a simple test run with Astro SSG
I switched from VSCode to Zed as my "I just need to edit this 1 little text file" app because VSCode was way too spammy. Every time I open it it wants to update something or complain about some extensions or complain that I had a file open and now it MUST close it because heaven forbid I open two things at once.
I hope Zed stays clean. We'll see. So far so good. Was quite happy they had a JetBrains base hotkey setup. Had to add a few of my own but I could pretty easily, nothing missing so far.
The windowing is pretty broken if you use system scaling https://github.com/zed-industries/zed/issues/40272
I'm so impressed by how quickly this team can ship new features. It seems like every few weeks there's a new major update!
tried to switch a few times
i can’t describe it in any other way other than it feels cold to use
i wonder if anyone else felt the same in earlier versions and feels that it’s fixed
What is Zed? A vscode like editor?
Pretty much, yeah.
It's native code, and it shows. It also has some AI integrations that are different, but I don't know how well they work.
It looks nice, but I haven't managed to use it for long.
Is it on winget?
Soon https://github.com/microsoft/winget-pkgs/pull/303728
These ones actually: https://github.com/microsoft/winget-pkgs/issues/304075
I don't use windows, but this is good development as all platforms should be present for editors to be worth using. I am happy Zed user since long time, I am happy it had kept with out demands, with adding AI, Git etc. Also integration of cli tools into AI is excellent and really refreshing.
[dead]
[dead]
First, you should fix fundamental operations on Mac and other distributions - for example when you stash or perform operations on files from other tools, it will put the state out of sync.
You can build the most beautiful and fastest IDE, but with this bugs, it’s useless
I didn't know bundling app for the most popular OS is that hard.
Not the most popular for programmers
It's a different tier of software engineers to be able to write a text editor, let alone the fastest one...
I worked at multiple FAANGs and can't see me or any of my colleagues capable of doing this.