[miffy900]

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.

[bdhtu]

Compared to Sublime Text:

RAM:

213 MB Zed

41 MB ST

Storage:

406 MB Zed

52 MB ST

Startup time:

Zed is slower than ST (but only by a few milliseconds).

Also when you reopen ST it will remember how you've resized the window from last time whereas Zed won't.

[andrewl-hn]

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.

[CaptainOfCoit]

> and a whole video-conferncing and screen-sharing client by default

Haha wait what? Are you confusing Zed (the text editor) with something else? Surely it doesn't ship with video conferencing???

[resonious]

I haven't seen video but it does have voice. And similarly I don't think it's screen-share, it's just editor state syncing, so live collaboration. Still quite a lot.

[joefitzgerald]

There is a feature that lets you share your screen. It shows up for other participants in the collaboration session as a tab in the editor.

[ahuth]

Probably referring to the collaboration tools. Zed has a bunch of stuff around remote pair programming with people.

[trenchpilgrim]

It has a voice chat system built in as part if the collaboration tools. Personally I think they should remove the voice chat...

[markus_zhang]

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.

[pjmlp]

For those on Windows, which is the topic at hand, UltraEdit and Notepad++.

I disagree Zed is an IDE, it is quite far from InteliJ, Borland/Embarcadero, VS, XCode, Eclipse, Netbeans...

If it is about adding enough plugins until it eventually becomes one, then any programmer's editor is an IDE.

[trenchpilgrim]

My line is - if I can compile, run and debug my program through the editor UI instead of a terminal, it's an IDE.

[niutech]

Sublime Text can run code from its UI too. IDE is much more full-featured, like VS vs VSCode or IntelliJ vs Fleet.

[pjmlp]

As I said, then any programmer editor is an IDE, including UltraEdit and Notepad++.

[trenchpilgrim]

Notepad++ has a debugger UI? One that goes beyond running a terminal inside a pane?

[niutech]

There are always: Vim and Emacs.

[doodpants]

> ST is a text editor while Zed is an IDE.

Zed is the new emacs?

[miroljub]

No. In Emacs you can write a simple one line script and change anything.

In Zed, you need to write a full blown plugin, and can change only what the Zed authors exposed through their plugin API.

[wseqyrku]

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.

[niutech]

RAM does matter, especially when you have web browser with multiple tabs opened at the same time. Sublime Text or Notepad++ are powerful, yet much more lightweight than Zed. Not to mention Vim/Emacs.

[neobrain]

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

[johnisgood]

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

Summary:

  $ 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

This is on a whole new level of bloat; both with regarding to dependencies AND the resulting executable file(s) (EDIT: executable files are unstripped).

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?

[phplovesong]

This is pretty common for larger rust projects. Its basically the new javascript+npm mess, this time with a borrow checker.

[andrewl-hn]

Cargo does the de-duplication, but only up to a point. If two packages request the same dependency with semver ranges that have a common overlap (say, `1.4` and `1.6`) then it will use a single package for both (say, `1.7.12`). But if they request semver-incompatible versions (`2.1` and `1.6`) then cargo will use both.

[panzi]

I read the question differently as: Why doesn't cargo cache (compiled) crates in ~/.cargo?

[neobrain]

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-xr-xr-x. 2 root root 337M Jan  1  1970 /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped

Extra weight also comes from webrtc, which nixpkgs dynamically links. So yeah, it's quite a large binary indeed.

[johnisgood]

Additionally, in any case, now I know what I have to do to free up some space. Get rid of Rust projects I built from scratch.

Maybe something like this to figure out what directories to delete:

  # With dut
  find . -type f -name Cargo.toml -printf '%h\n' | sort -u | xargs -r -d '\n' -I{} dut -s {} | sort -h
  # With du
  find . -type f -name Cargo.toml -printf '%h\n' | sort -u | xargs -r du -sh | sort -h

I found "websocat" and "ripgrep". Thankfully I got rid of everything else.

  ripgrep $ cargo clean
     Removed 3411 files, 1020.2MiB total

  websocat $ cargo clean
     Removed 1726 files, 820.7MiB total

That said, ripgrep itself is only 5.0M.

[lenkite]

Probably due to treesitter modules for many languages compiled in. AFAK Treesitter's codegen is unfortunately a share nothing between different languages. So a dozen language parsers can easily cross upward of 200 MB.

[pooyamo]

Binaries for dynamic libraries of tree-sitter (usually compiled with C compiler) would be smaller than that. For example this [1] .so bundle for 107 different grammars is ~137 MiB.

Unless by "compiled in", some in-lining of the C code into Rust codebase is meant.

[1] https://github.com/emacs-tree-sitter/tree-sitter-langs/relea...

[johnisgood]

  $ 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 is taking quite a long time.

[neobrain]

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

[johnisgood]

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.

[johnisgood]

I suppose it has to do with how every Rust crate (including dependencies) gets statically linked into the final binary, and this leads to extremely large intermediate artifacts, even when many crates share common dependencies.

Or the fact that there is incremental compilation artifacts...

And of course the amount of dependencies. A single project might depend on hundreds of crates (quite common), each compiled separately with its own build artifacts. sighs.

[torginus]

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

[neobrain]

Judging by this note in the docs: Collaboration features.

https://zed.dev/docs/development/freebsd#webrtc-notice

[torginus]

If they're going to implement every feature under the sun and include half of userspace to support it, they might as well build the whole thing on top of a browser.

[WesolyKubeczek]

vscode has entered the chat...

[WD-42]

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

[tremarley]

A 400mb+ install of bloat will upset many people

This needs to be justified asap to help people understand and reconsider installing it.

[landr0id]

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

[vilhelm_s]

The Rust compiler always produces quite large binaries compared to other programming language. I notice there's a (closed) issue on the Zed github [https://github.com/zed-industries/zed/issues/34376],

> At this time, we prioritize performance and out-of-the-box functionality over minimal binary size. As is, this issue isn't very actionable, but if you have concrete optimization ideas that don't compromise these priorities, we'd be happy to consider them in a new issue.

[pjmlp]

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.

[magackame]

All those beautiful dlls will anyways sit comfortably in the same folder as your "dynamically" linked executable on Windows.

[pjmlp]

They might be, or not.

[torginus]

I think there should be a best-of-both-worlds type of linking - during compilation, the linker places a statically compiled library at a certain address, but doesn't include it in the binary. Then, during startup, the OS maps the same library to the given address (sharing the data between processes). This would improve memory use and startup time both and performance, avoiding dynamic linking. Of course you need to match the exact versions between the compiled executable and the dependency, but this should be a best practice anyways.

[trenchpilgrim]

Static linkers generally don't compile a "full copy" of the library. Just the code paths the compiled application uses. The compiler may have also made optimizations based on the apppication's usage patterns.

[landr0id]

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.

[trenchpilgrim]

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

[pjmlp]

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

[ChrisSD]

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.

[tremarley]

Precisely. It seems like the people who say storage is cheap assume everyone is using desktop PCs

[vthriller]

> Storage is cheap

My /usr is 15G already, and /var/lib/docker isn't that far off despite people's obsession with alpine images. If more people would dismiss storage as cheap it'll quickly become expensive, just not per GiB.

> update distribution is free

I wouldn't be surprised if at one point Github would start restricting asset downloads for very popular projects simply because of how much traffic they'd generate.

Also, there's still plenty of places on the planet with relatively slow internet connectivity.

[mort96]

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.

[trenchpilgrim]

That's more of an Apple problem? Storage is under $50/TB.

[juliangmp]

If you're buying Apple then you should expect inflated prices. I got a 4TB NVMe SSD for like 350€, a 2TB one goes from 122 - 220 € depending on read/write speeds.

I don't check the installation size of applications anymore.

[dsego]

A 2TB SSD for the Framework 13 cost me 200 euros. But I agree that it's not cheap, files are getting bigger, games are big, apps are huge, and then you need backups and external storage and always some free space as temp storage so you can move files around.

[Fokamul]

Bro, with this mentality, you won't get far in Apple universe.

Embrace your wallet will be owned by Apple. Then you can continue.

Sorry, but people buying Apple products are different bread :D

[homebrewer]

RAM isn't cheap (it may be for your tasks and wallet depth, but generally it isn't, especially since DDR5). Shared objects also get "deduplicated" in RAM, not just on disk.

[trenchpilgrim]

What objects is the Zed process using that would even be shared with any other process on my system? Language support is mostly via external language servers. It uses its own graphics framework, so the UI code wouldn't be shared. A huge amount of the executable size is tree-sitter related.

[juliangmp]

I 100% agree. As soon as you step outside of the comfort of your Linux distributions' package manager, dynamic linking turns into dependency hell. And the magic solution to that problem our industry has come up with is packaging half an OS inside of a container...

[nottorp]

> Storage is cheap

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

[trenchpilgrim]

OSes don't load the full executable into physical RAM, only the pages in the working set. Most of the Zed executable's size is tree-sitter code for all the supported languages, and only needs to page in if those languages are being used in a project.

[HeckFeck]

Big sigh. I wish we still had pride in our field, rather than this race to the bottom mentality.

[bowsamic]

I really like this article "How Swift Achieved Dynamic Linking Where Rust Couldn't" https://faultlore.com/blah/swift-abi

[hdjrudni]

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.

[eviks]

So the upgrades are not delta diffs either?

[wongogue]

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.

[1718627440]

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

[torginus]

Is it? On Linux, you can overwrite the file, but the underlying inode will still be open, and the 'invisble' old version will linger around - you don't have any easy way short of restarting everything to make sure the new versions are being used.

And with Chromium this directly leads to crashes - when you update the browser as its open, the new tabs will open with the new version of the binary, with the old ones still using the old binary - which usually leads to crash.

I prefer 'you cannot do X' instead of 'we allow you to do it, but it might misbehave in unpredictable ways'.

[josephg]

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

[juliangmp]

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.

[ktm5j]

Yeah I don't think 400M is really that big a deal. My `.emacs.d/` dir weighs in at over 1G and I've never thought twice about it.

For people who are serious about their text editors, 400m is a small price to pay for something that works for you.

[eviks]

If the OS is already bloated, that leaves LESS space for your editor!

[bowsamic]

> I was always under the impresion that Rust apps are pretty lightweight

I'm not sure what gave you that impression. I'd say Rust is pretty well known for fat binaries

[kibwen]

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.

[1718627440]

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

[ben-schaaf]

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.

[kibwen]

> The reason Zed has a bloated binary is the ~2000 rust packages that comprise it.

Hundreds of those MBs are from tree-sitter grammars, which are JavaScript compiled to C.

[ChrisSD]

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.

[timeon]

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

[adastra22]

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

[TiredOfLife]

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

[andrewmcwatters]

Just so others here know, it’s possible to have a graphics context and a Win32 menu bar in the same window.

[gethly]

PSPad is 40MB. And that is quite a legacy software that is still being updated to this day. Notepad++ is 17 mb.

400 mb for new project in this amazing bestest compiled language ever made is ridiculous.