Zed Is Now Available on Windows
Posted3 months agoActive3 months ago
zed.devTechstoryHigh profile
calmmixed
Debate
60/100
Text EditorsZed EditorWindows Support
Key topics
Text Editors
Zed Editor
Windows Support
The Zed editor is now available on Windows, sparking discussion about its features, performance, and potential as a VSCode alternative, with users sharing both praise and concerns.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
4h
Peak period
74
6-12h
Avg / period
26.7
Comment distribution160 data points
Loading chart...
Based on 160 loaded comments
Key moments
- 01Story posted
Oct 15, 2025 at 12:24 PM EDT
3 months ago
Step 01 - 02First comment
Oct 15, 2025 at 4:37 PM EDT
4h after posting
Step 02 - 03Peak activity
74 comments in 6-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 19, 2025 at 6:48 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45594920Type: storyLast synced: 11/22/2025, 11:00:32 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
I'm really liking it thus far!
https://www.gpui.rs/
https://zed.dev/blog/videogame
It is Rust software, so there is probably a good 50-90% waste when it comes to just raw needed vs. actual lines of code in there, but there is no way anyone makes a renderer so overcomplicated that it takes up a meaningful part of the 500 MB or so Zed takes up on Windows.
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.
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.
Also, the question isn't if the code isn't used, it is that it isn't used simultaneously. Almost all software has many features which aren't used simultaneously. For example, it is unlikely you have all of the different language parsers loaded at the same time, because most projects use only a few.
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.
> does we run game engine for code??
Zed literally does this; they render their UI using a graphics library just like a video game.
They aren't high-dpi though, just big and still zoomed. On the plus side, it's very similar experience to two 4:3 monitors glued together... side by side apps on half the screen is a pretty great experience... on the down side, RDP session suck, may need to see if I can find a scaling RDP app.
Seems like the only way to get high quality font rendering these days is a 4k+ display.
Just be aware that half the population prefers Windows font rendering.
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 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!
https://github.com/rust-lang/rust/issues/145864 was opened because of the the discrepancy
> 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.
Your company trusts you to write code but not run code?
MSTSC is one of the rock-solid tools from Microsoft, and does better than almost everything else available on the market other than some PC over IP technologies specifically highly optimized for this use case. I've been programming with an ancient ThinkPad forever because I'm just remoting into a much more powerful machine.
It may not be an actual problem with zed either, despite the warning.
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.
Yeah input latency is annoyingly rough, not super bad but _just_ laggy enough to make it annoying to use.
Debating how much I want to change things, I can directly punch into my Linux machine but all my dev IDEs are on a VM for a long list of reasons, and I doubt Zed is going to run on my old ThinkPad if it struggles on software rendering, but we'll see.
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
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.
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.
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.
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.
Low-dpi font rendering also isn’t an issue for me, unless it is so bad as to be illegible (which no modern system is).
We really do perceive things differently.
But waaaaah they don't support a processor that accounts for probably less then 10% of Windows Machines
Also, I do not believe Windows on Arm64 is a very large demographic? Especially for developers, unless they're specifically into that platform.
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).
On the other hand, I just thought of one way that even a small fixed amount of latency can be a material obstacle. Personally, I type fast but make lots of typos, and I don't use autocorrect. So I need to react to incorrect text appearing on screen, backspace, and retype. The slower I react, the more text I have to delete (which means not just more keypresses but also more mental overhead figuring out what I need to retype). For this purpose, I am bound by the human reaction time, but editor latency is added on top of that. The sooner the text appears, the sooner my 'reaction timer' can start, all the way down to 0 latency. [Edit: And 100ms of latency can make a meaningful difference here. I just did a quick typing speed test and measured 148 WPM which is around 12 characters per second, so 100ms is one extra character, or a bit more.]
Also, latency might affect productivity just by being annoying and distracting. YMMV on whether this is a legitimate complaint or whether you should just get used to it. But personally I'm glad I don't have to get used to it, and can instead just use editors with low latency.
Also you can absolutely feel the visual difference between 60Hz (~16ms) and 120Hz (~8ms), and for audio it's even more nuanced.
Just because studies don't back this up yet doesn't make it false. I imagine this is really hard to measure accurately, and focusing only on neuron activity seems misguided too. Our bodies are more than just brains.
Human neural feedback loop latency is a range that varies widely depending on the type of loop involved. Reflex loops are fastest, operating in tens of milliseconds, while complex loops involving conscious thought can take hundreds of milliseconds.
Short-latency reflex: 20-30ms. Signal travels through spinal cord, bypassing the brain. E.g. knee-jerk reflex.
Long-latency reflex: 50-100ms. Signal travels to the brainstem and cortex for processing before returning. E.g. Adjusting grip strength when an object begins to slip from your hand.
Simple sensorimotor reaction: 230 - 330ms. Simple stimulus-response pathway involving conscious processing, but minimal decision-making. E.g. pressing a button as soon as light turns on.
Visuomotor control: ~150ms, adaptable with training. Complex, conscious loops involving vision, processing in the cortex, and motor commands. E.g. steering a bike to stay on a path in a video game.
Complex cognitive loops: Brain's processing speed for conscious thought is estimated at 10 bits per second, much slower than the speed of sensory data. High-level thought, decision-making, internal mental feedback. E.g. complex tasks like analyzing a chess board or making a strategic decision.
The first test was the simple one-light-one-button test. I found that I had reaction time somewhere in the 220-270ms range. Pretty much what you'd expect.
The second test was a sound reaction test: it makes a noise, and I press the button. I don't remember the exact times, but my reaction times for audio were comfortably under 200ms. I was surprised at how much faster I was responding to sound compared to sight.
The last test was two lights, and two buttons. When the left light came on I press the left button; right light, right button. My reaction times were awful and I was super inaccurate, frequently pressing the wrong button. Again, I don't remember the times (I think near 400ms), but I was shocked at how much just adding a simple decision slowed me down.
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...
https://news.ycombinator.com/item?id=45253927
https://news.ycombinator.com/item?id=45254054
I know as a matter of fact that bad extensions slow down VSCode significantly.
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.
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.
The specific techniques used to send, receive, and parse JSON could matter.
You can have custom functions in your language server that is not in spec and have your editor specific plugin call them.
I imagine there is a lot of this for typescript.
But I'm not sure if this can explain the speed difference..
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...
Sounds great. Looking forward to doing a simple test run with Astro SSG
You can build the most beautiful and fastest IDE, but with this bugs, it’s useless
205 more comments available on Hacker News