Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zed is now available on Windows

zed.dev

Post reply on HN
Print view View original

211–220 of 386 posts

Re: Zed is now available on Windows

#211

Post by earthnail »

I absolutely love the idea of Zed, and I'm regularly giving it a go. Typing in Zed really feels better than VSCode. It's hard to describe, but impossible to discard once you've used it for a short while.

Unfortunately, there's a bunch of small things still holding me back. Proper file drag & drop for one, the ability to listen to audio files inside the editor, and even a bunch of extensions, in particular one that shows a spectrogram for an audio file.

Maybe my biggest gripe is that Python support is still better in VSCode. Clicking on definitions is faster and more reliable.

Re: Zed is now available on Windows

#212

Post by josephg »

1718627440 wrote: post #181
wongogue wrote: post #162

Earlier quoted context omitted.

Even if it’s delta, it cannot patch itself when running on Windows. So it runs the updater, creates a new exec and switches to it after relaunch. Same as Chrome or Firefox.

OS deficiency. And maybe programs shouldn't be allowed to update themselves.

> maybe programs shouldn't be allowed to update themselves.

Honestly I'd be all for this if the OS had a good autoupdate mechanism for 3rd party applications. But that's not the world we live in. Certainly not on windows - which is too busy adding antivax conspiracy articles to the start menu.

Re: Zed is now available on Windows

#213

Post by [deleted] »

johnisgood wrote: post #202
neobrain wrote: post #187

Earlier quoted context omitted.

> I was always under the impresion that Rust apps are pretty lightweight, but that install size is nearing Java levels of binary/dependency bloat. For what it's worth, the zed executable on Linux weighs 3.2 MB. EDIT: Sorry, the nix store is too good at hiding things from me. It's actually around 337 MB plus webrtc-sys.

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-4bd…

[deleted]

Re: Zed is now available on Windows

#214

Post by neobrain »

johnisgood wrote: post #210
neobrain wrote: post #204

Earlier quoted context omitted.

Unstripped, perhaps? ls -lh /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor -r-xr-xr-x. 2 root root 3.2M Jan 1 1970 /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor EDIT: Ah, it was too good to be true. The true binary is hidden in libexec/.zed-editor-wrapped :( ls -lh /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped -r-x…

$ strip --strip-all ./target/release/zed $ du -h ./target/release/zed 261M ./target/release/zed $ strip --strip-all ./target/debug/zed $ du -h ./target/debug/zed 482M ./target/debug/zed Correct. It is still embarrassing, in my opinion. To make matters worse, it takes several minutes for Zed's window to appear on a cold start, whereas VSCode launches almost instantly. [1] I am trying to measure it as we speak but it i…

> Not to mention it takes minutes for the window of Zed to open, whereas VSCode is almost instant.

That one is interesting. It's much quicker for me, even cold starts are below 1s, and subsequent startups are basically instant.

Re: Zed is now available on Windows

#215

Post by globular-toast »

homebrewer wrote: post #174
mercutio2 wrote: post #71

Earlier quoted context omitted.

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

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…

Are you talking about the same thing? This sounds like your typical docker/compose dev setup for running the software under development. The "dev container" stuff is more about running your editor stack in a container, like static analysis tools, language servers etc.

Re: Zed is now available on Windows

#216

Post by ben-schaaf »

1718627440 wrote: post #176
miffy900 wrote: post #72

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…

Rust Hello World is larger than Git. Still smaller than Java and Electron, but not exactly small.

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.

Re: Zed is now available on Windows

#217

Post by johnisgood »

neobrain wrote: post #214
johnisgood wrote: post #210

Earlier quoted context omitted.

$ strip --strip-all ./target/release/zed $ du -h ./target/release/zed 261M ./target/release/zed $ strip --strip-all ./target/debug/zed $ du -h ./target/debug/zed 482M ./target/debug/zed Correct. It is still embarrassing, in my opinion. To make matters worse, it takes several minutes for Zed's window to appear on a cold start, whereas VSCode launches almost instantly. [1] I am trying to measure it as we speak but it i…

> Not to mention it takes minutes for the window of Zed to open, whereas VSCode is almost instant. That one is interesting. It's much quicker for me, even cold starts are below 1s, and subsequent startups are basically instant.

Cold starts are minutes, subsequent startups are much faster than VSCode[1].

I wonder why though.

[1] I have not measured subsequent launches of VSCode though, but Zed is relatively pretty quick after the initial launch.

Re: Zed is now available on Windows

#218

Post by d357r0y3r »

earthnail wrote: post #211

I absolutely love the idea of Zed, and I'm regularly giving it a go. Typing in Zed really feels better than VSCode. It's hard to describe, but impossible to discard once you've used it for a short while. Unfortunately, there's a bunch of small things still holding me back. Proper file drag & drop for one, the ability to listen to audio files inside the editor, and even a bunch of extensions, in particular one that sh…

The reason it's faster is largely because it doesn't have all those little quality of life features and extension ecosystem. It's easyish to make software perform well if it doesn't do all that much. If you take base vscode, no extensions, and just do raw text editing, it's hard for me to tell the difference between vscode, zed, or any other editor.

When vscode was released, Sublime was faster - and it stayed faster. But that wasn't enough to stop the rise of vscode.

Re: Zed is now available on Windows

#219

Post by simonask »

jstimpfle wrote: post #149
simonask wrote: post #133

Earlier quoted context omitted.

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?

There's many ways to represent it, but the "sub" in "subpixel" does tell us that someone along the way needs to deal with fractional pixels. :-)

Re: Zed is now available on Windows

#220

Post by simonask »

olive-n wrote: post #9

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

I'm editing a UTF16-LE file right now. Works just fine. It does show the BOM at the beginning, though.
Post reply on HN