Live data from Hacker News

Zed is now available on Windows

zed.dev

271–280 of 386 posts

Re: Zed is now available on Windows

#271
post #31

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.

That doesn't make sense, they both use tsserver under the hood.

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

Re: Zed is now available on Windows

#272
post #66

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 significan…

I tried it for a while. It's okay, I guess. Typing latency is neither an issue nor a bottleneck for me, so personally, I don't see the appeal. Apart from that, it feels lacking and offers nothing else that I don't already get from VS Code. If I really cared about performance, I would use Neovim.

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.

Re: Zed is now available on Windows

#273

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.

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

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

Re: Zed is now available on Windows

#274

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 in…

Helix binary on my system is 20MB+ but dynamically linked grammars are additional 200MB. Those 380-400MB are probably not pure binaries are they?

Re: Zed is now available on Windows

#275
post #89
post #10

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 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.

> Windows' awful font rendering

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

Re: Zed is now available on Windows

#276
post #146

Earlier quoted context omitted.

> 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.

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...

Tbh, the rights and wrongs aside, I suspect "everyone" is complaining about it because it's the easiest thing to talk about. Much like how feature discussions tend towards bikeshedding.

Re: Zed is now available on Windows

#278
post #266

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" an…

About no. 1, I think any sane application will show a warning "Do you want to delete abc.c" before permanently removing the file. I cannot verify it now, but pretty sure VSCode has it. So -- * if there is no such dialog, it's on zed * If there is such a dialog and you clicked yes, it's on you

> If there is such a dialog

Just checked, there is a modal dialog that reads:

    *Delete "asd"?*

    (Cancel) (Delete)

Re: Zed is now available on Windows

#279
post #66

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 significan…

What does having a DevContainer get you? I’m all for documenting every bit of my setup, but beyond that…

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.

Re: Zed is now available on Windows

#280
post #137

Earlier quoted context omitted.

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.

> 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 is cheap

I'll be very grateful if you stopped using all my RAM for two buttons and a scrollbar thank you.

Post reply on HN