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

Zed, a collaborative code editor, is now open source

zed.dev

Post reply on HN
Print view View original

471–480 of 642 posts

Re: Zed, a collaborative code editor, is now open source

#471

Post by lucideer »

evmar wrote: post #219

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!?

The 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

[1] https://microsoft.github.io/language-server-protocol/

[2] https://github.com/Microsoft/vscode-languageserver-node

Re: Zed, a collaborative code editor, is now open source

#472

Post by benreesman »

jitl wrote: post #340
benreesman wrote: post #326

Earlier quoted context omitted.

I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…

How do you get a reasonably fancy Emacs to start up/open files quickly? Every time I try to get into EMacs after adding a few packages it becomes painfully slow to open a file for editing. Then I try to understand Emacs server, then I fail / give up and go back to vim.

https://imgur.com/a/i99Nisn

1.4 seconds for 100 packages, half of which are on probation? My (and soon `HYPER//MODERN`'s) package set is under heavy construction, I'll be sad if I don't get it under 300ms including loading and rendering a logo at 6k from a cold disk which that was.

Rust is a perfectly good language for writing tight code, but those `emacs` inner loops have been tuned by hard-ass pros for 30+ years in straight C, which is plenty fast too. Even the best Rust code doesn't have that kind of tuning in.

`emacs` is fucking fast.

Re: Zed, a collaborative code editor, is now open source

#473

Post by benreesman »

ideasman42 wrote: post #388
jitl wrote: post #340

Earlier quoted context omitted.

How do you get a reasonably fancy Emacs to start up/open files quickly? Every time I try to get into EMacs after adding a few packages it becomes painfully slow to open a file for editing. Then I try to understand Emacs server, then I fail / give up and go back to vim.

I've been using emacs as my main editor for years now and don't find the startup speed to be an issue - to the point I've never bothered with emacsclient: It starts up with ~77 packages in half a second. This is my config. https://gitlab.com/ideasman42/dotfiles/-/tree/main/.config/e...

That’s pretty close to what I’ve been running on the GC tuning but I like parts of your spelling better.

This is going MIT as part of a bigger project in about a month (think Lucid s/C++/modern models/).

If I inline attribution you mind if I borrow this or that?

Re: Zed, a collaborative code editor, is now open source

#474

Post by benreesman »

mkesper wrote: post #426
jitl wrote: post #340

Earlier quoted context omitted.

How do you get a reasonably fancy Emacs to start up/open files quickly? Every time I try to get into EMacs after adding a few packages it becomes painfully slow to open a file for editing. Then I try to understand Emacs server, then I fail / give up and go back to vim.

Use doomemacs for a start. It really optimizes startup time and offers vast included modules as well as great package management. https://github.com/doomemacs/doomemacs/blob/master/docs/gett... Oh and for Windows, WSL2 seems to be the fastest: https://github.com/doomemacs/doomemacs/blob/master/docs/gett...

Doom is a great start for a low-friction, extreme quality curated emacs setup. +1

Re: Zed, a collaborative code editor, is now open source

#475

Post by benreesman »

nccnm wrote: post #333
benreesman wrote: post #326

Earlier quoted context omitted.

I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…

Can you share more about your Emacs 29 setup? Thanks

I mentioned it above but I’m flattered by your interest (and remember your username as someone serious): my old dots were ok and are floating around but we’re putting together a multi-editor curated setup for good defaults and an emphasis on good, available-weight models as first-class citizens.

It’s a 404 until I get to an RC, but aiming for March 1st on “hyper-modern.ai” for all MIT on emacs, nvim, and vscode.

Re: Zed, a collaborative code editor, is now open source

#476

Post by sooheon »

benreesman wrote: post #326
Octoth0rpe wrote: post #51

I'm generally a big fan of zed and have been using it for 60%ish of my dev time for 6 months or so. A couple of nice things to note: - It really is remarkably responsive,and makes one really notice how UNresponsive everything else is. I have reasonably fast machines, so we're not talking about the difference between 5ms typing lag and 500ms, but it's still pretty surprising. VSCode never felt slow on my macs until I…

I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…

Emacs still blocks input on simple things like package updates though.

Re: Zed, a collaborative code editor, is now open source

#477

Post by benreesman »

dataangel wrote: post #378
benreesman wrote: post #326

Earlier quoted context omitted.

I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…

what are the right flags and gc tunings?

I don’t have much to add on what sibling @darthrupert said. You tweak this or that to your box but that’s an excellent guideline to start.

Re: Zed, a collaborative code editor, is now open source

#478

Post by coffeeaddict1 »

raphlinus wrote: post #182
Cannabat wrote: post #149

> respond to your keystrokes on the next display refresh Claimed insertion latency for a keystroke: - zed 58ms - subl 75ms - vscode 97ms - clion 83ms 60 Hz displays refresh once every ~16.6ms. 58ms to insert a character is ~3.5 frames. My laptop can do 120 Hz, and other monitors can even do 300 Hz. Yeah, it's a lot faster than the other editors, but 58ms seems really slow - definitely not "next display refresh". All…

Much of that is latency added by the design of modern compositors (see "the compositor is evil"). The good-ish news is that as the frame rate goes up, compositor latency goes down, as it's usually an integer multiple of frame refresh time. I'm also interested in influencing the design of next gen systems to reduce compositor latency, but I'm apparently pretty much alone in that interest.

Xilem seems to be heavily focused on using WebGPU. One doubt I have is: is it possible to have tight integration with the system's compositor using such an abstraction? For example, on Windows looking at the documentation for the DirectComposition, it seems that things are designed precisely to work optimally with DirectX. So my impression is that one would really need to use the native graphics APIs on each system to achieve optimal input latency.

Re: Zed, a collaborative code editor, is now open source

#479

Post by benreesman »

sooheon wrote: post #476
benreesman wrote: post #326

Earlier quoted context omitted.

I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…

Emacs still blocks input on simple things like package updates though.

Give straight.el (among others) a shot. Combined with use-package you don’t have to worry about that these days.

Re: Zed, a collaborative code editor, is now open source

#480

Post by benreesman »

da39a3ee wrote: post #392
benreesman wrote: post #326

Earlier quoted context omitted.

I’m really picky about my tools in general and latency in particular, and I give Zed a spin from time to time, it’s sweet. Clean, minimal design aesthetic, tree-sitter, tight code, it’s a nice bit of work and I dig it a lot. But emacs 29 with the right flags and a tuned GC (no one does this! it’s got a heap-size from the 80s!) is just as snappy and has more amazing packages than VSCode. There’s a market for people wh…

> But I can’t imagine switching my main axe up with a holy shit moment a lot crazier than tree-sitter in 2024 and not having the render loop be in JS. Congratulations for winning HN sentence of the year before the end of January.

I’m glad I made a funny but it’s a lot of year to come :) And this one looks to be every bit as interesting as the last one was over-hyped.
Post reply on HN