Live data from Hacker News

Zed, a collaborative code editor, is now open source

zed.dev

531–540 of 642 posts

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

#532

Earlier quoted context omitted.

I switched _to_ VSCode because Sublime was occasionally so slow at times that it was unusable. It was very fast 95% of the time, but then I'd `git pull` on a very big repo and my machine would become unresponsive while Sublime did...something.

This is very strange to me, because I have always used Sublime Text for super-giant corporate repos, and always found it snappy compared to vscode. Wonder if it was a specific usecase or something... Every little while, I try to make vscode my main editor, because I enjoy all the features. I always switch back to Sublime just because VSCode's slowness bugs me. Haven't really tried Zed in earnest yet, though, because…

I'll be eager to try Zed when it gets LSP support for sure

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

#533

I had the pleasure of working with Nathan Sobo when he joined Pivotal Labs ~2008. He had a burning desire to create a transformative text edior/ide back then. He is bright, not only in an intellectual & talent sense, but also in an energetic sense. He is also compassionate & genuine person. I'm very happy & inspired every time I see his endeavors progress. Knowing Nathan has been one of the major catalysts for me to…

Wow Brian, nice to hear from you. Thanks very much for your words! I remember you setting a new standard of speed for me when we worked together!

I credit Nathan Wilmes for showing me how to speed up my development techniques & decision making...Mainly by observing him work during our pairing sessions. It's interesting how one can learn effective practices that are difficult codify with conscious thought & written or spoken language...Yet the human observational systems & nervous system are effective in working with these complexities. It's almost like how a GPU frees the CPU from processing graphics or linear equations.

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

#534

Earlier quoted context omitted.

I think that is on the roadmap too, but possibly further down.

You know Windows is the most common development platform? If it were me I'd prioritize it

I think linux + osx combined is probably developer majority. I'm assuming most Windows development is .NET or Unity based. Over the past nine years, I've worked primarily with Node, Ruby, and a smidgen of Java and no employer has issued Windows machine. It's in sharp contrast with the start of my career where I was in VB6 and C# where I only worked with Windows environments. Could be confirmation bias, though.

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

#535

Earlier quoted context omitted.

Please not ala vscode-server over SSH. Do it proper like emacs tramp so it will connect to any platforms/architectures.

“Please don’t do it like a 4x4 truck, do it proper, like a bicycle” — there is some overlap between those things, but for people who are actually making full use of the former, the latter is not a useful suggestion

Bikes likewise have advantages that 4x4s lack. If you mean to imply everyone ought to be satisfied with the 4x4, and not ask for a bicycle: no. We can have both.

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

#536
post #87

That's great news. I actually like their zed font [1] which is custom-built from Iosevka. [2]. [1] https://github.com/zed-industries/zed-fonts [2] https://github.com/be5invis/Iosevka

Where I can download those fonts from without installing Zed?

did https://github.com/zed-industries/zed-fonts/releases/tag/1.2... not work for you?

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

#538
post #502

Earlier quoted context omitted.

The, uh, GNU folks, are a little conservative in some ways that surprise the mainstream developers. But there are always flags for it. Well, except stupid-ass dynamic-linking of `glibc`.

> are a little conservative in some ways that surprise the mainstream developers Conservative is one thing, but having the default be something that's detrimental to 99.999% of your users in 99.95% of situations feels like bad defaults/design, not being conservative. My worthless 2 eurocents :-)

You would think that it would dynamically check the system on first run and set appropriate defaults.

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

#539

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…

> There’s a market for people who want something snappier than VSCode but less labor-intensive to set up than emacs, and I wish them luck

Basically AstroNvim or Doom Emacs. Not a huge fan of Doom Emacs but AstroNvim got me to drop my main editors (Sublime + Atom) and I basically only use AstroNvim.

One enormous advantage of Nvim is that I can run it anywhere. I run it on a Linux machine, a Mac, and a Tablet (w/ Termux) extremely easy (just clone my dotfiles, install nvim, and that's it).

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

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

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…

With no intention to push back on Emacs being highly optimized, age of an application is not an accurate proxy for level of performance. If it were, grep would be faster than ripgrep. New software can apply optimisations discovered over the previous 40 years, and leverage architectural designs with different assumptions, like the GC limits in Emacs discussed elsewhere in the comments. Older applications can apply those same optimizations, but it's not a given that they will, and changing their architecture can be daunting, for sometimes unknown benefits.
Post reply on HN