3 ms·
This looks really nice, but I am confused why the install is over 350mb, including a 300mb binary. I thought Electron-based stuff was big but this is even som
by evmar 3y ago
This looks really nice, but I am confused why the install is over 350mb, including a 300mb binary. I thought Electron-based stuff was big but this is even somehow more!?
- Aeolun 3y agoAt least it’s fast after installing that 350mb blob. Often it’s a sign that something is going to be really slow.
- widdershins 3y agoIt comes with quite a few language servers built-in.
- lucideer 3y agoThe core app itself is 100% Rust, but it supports integration via Microsoft's Language Server Protocol[0][1]. In practice, this means you will be running daemons locally for each language, which may be written in any language. Often these daemons are written in NodeJS since the reference implementation[2] is in NodeJS. [0] https://zed.dev/docs/adding-new-languages#lsp https://zed.dev/docs/adding-new-languages#lsp [1] https://microsoft.github.io/language-server-protocol/ https://microsoft.github.io/language-server-protocol/ [2] https://github.com/Microsoft/vscode-languageserver-node https://github.com/Microsoft/vscode-languageserver-node
- ra1231963 3y agoIt doesn’t follow that a language server written with JavaScript and run via node will bloat the binary by hundreds of MB. Are they bundling a node runtime too? Maybe if they are embedding dozens of language servers and runtimes it could bloat the binary, but I assumed the extensions and language servers would be downloaded on demand. But a rust binary by itself shouldn’t be that large. LSP is just a simple json protocol, so parsing it doesn’t require hundreds of MB.
- evmar 3y agoWhen I opened a Rust project I think the status bar said it was downloading Rust support, which supports your hypothesis. (Also it doesn't make much sense to bundle these things when they are all making new releases at different schedules.)
- diodak 3y agoHey, Zed developer here. Indeed we do not bundle the LSP binaries into the final binary for the reasons you've stated; and I do agree that the binary is kind of big, though at present .dmg compression gets us a long way (as the .dmg itself is ~115Mb). Right now we ship an universal binary, so half of that size is essentially unused: size /Applications/Zed.app/Contents/MacOS/zed __TEXT __DATA __OBJC others dec hex 120979456 475136 0 4336828416 4458283008 109bc0000 zed (for architecture x86_64) 117587968 458752 0 4336680960 4454727680 10985c000 zed (for architecture arm64) Then, each of these binaries includes about 40MB of assets. I've actually had a PR up (https://github.com/zed-industries/zed/pull/3997 https://github.com/zed-industries/zed/pull/3997) that reduced their size quite significantly, though that did not end up reducing the size of a .dmg itself, so I've scraped that. On top of that, we ship with debug symbols for symbolication of crashes (https://github.com/zed-industries/zed/blob/main/Cargo.toml#L175 https://github.com/zed-industries/zed/blob/main/Cargo.toml#L...).