Live data from Hacker News

Zed, a collaborative code editor, is now open source

zed.dev

491–500 of 642 posts

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

#491

It's interesting that the #2 selling point on the landing page (the Copilot integration) relies purely on Microsoft's goodwill. There is no official API for Copilot but instead a (non-standard) LSP implementation embedded into the proprietary Copilot Neovim plugin. Zed seems to trust under the hood that a release of the plug-in exists on Github, pulls the minified-js language server from there and integrates with tha…

Why would Microsoft pull Copilot from Neovim? Microsoft doesn't care if you use copilot with VSCode or not. Copilot is a paid product the more support the better for them. I bet Microsoft doesn't care if you use VSCode or not. It's not a paid product.

It is not paid product for non-commercial and open-source products. The get massive amount of data if you use it in VSCode, and because of this, it is pain to ass to use on VSCodium for example. Your data is the currency, and other editors are good on limitin that.

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

#492

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…

> (no one does this! it’s got a heap-size from the 80s!)

Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.

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

#493

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.

It is a great sentence, and that holy shit moment is coming: when JS gains all the expressivity of tree-sitter and uses it to render code more beautifully than it has ever been rendered before.

(Spoiler: https://github.com/bablr-lang/)

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

#494

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…

I can't still figure out how can I get Emacs not mess up indentation and auto indentation.

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

#495

It's interesting that the #2 selling point on the landing page (the Copilot integration) relies purely on Microsoft's goodwill. There is no official API for Copilot but instead a (non-standard) LSP implementation embedded into the proprietary Copilot Neovim plugin. Zed seems to trust under the hood that a release of the plug-in exists on Github, pulls the minified-js language server from there and integrates with tha…

Why would Microsoft pull Copilot from Neovim? Microsoft doesn't care if you use copilot with VSCode or not. Copilot is a paid product the more support the better for them. I bet Microsoft doesn't care if you use VSCode or not. It's not a paid product.

If they wanted non-sanctioned editors integrating Copilot they wouldn't have taken the extra steps of implementing an obfuscated LSP but provided an API or a plain client library. At best this could be a pet project by a Neovim fan GH employee. Either way I wouldn't expect long term (if any) support from this thing.

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

#496
post #397

Earlier quoted context omitted.

Heard of Helix? It's a bit more Vim to Zed's VSCode, but it's open source and Rust too! It also comes with rust-analyzer and tree-sitter included. https://github.com/helix-editor/helix

Helix doesn't have a plugin system: https://github.com/helix-editor/helix/issues/122

Personally I love the no plugins. It keeps the core editor competitive and easy to set up.

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

#497

Earlier quoted context omitted.

Did you make an issue for that? (I'm sad about that too)

I have now: https://github.com/zed-industries/zed/issues/6440

For people following along at home, this was fixed with a 250x speed up (!) in https://github.com/zed-industries/zed/pull/6700

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

#498

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…

I can't still figure out how can I get Emacs not mess up indentation and auto indentation.

Most language modes have a `foo-ts-mode` now that uses `tree-sitter` to get a perfect* AST in the absence of errors, and almost always the most reasonable one in the presence of errors. `tree-sitter` is amazing, a real feat.

It ships with 29 and it's work to find `brew` or `apt` or `nix` or anything giving you less than 29.1 these days.

Have you tried a recent version? 29.1 is dramatically more accurate on everything from syntax highlighting to indention than VSCode (IMHO, they're probably either using or working on using `tree-sitter` too, those are serious people) or JetBrains stuff (they're working on their vscode clone more than IntelliJ these days).

I only use `nvim` for commit messages and stuff the last few years, but AFAIK it has all the `tree-sitter` stuff too.

If it's the sloppy naming of `c-basic-offset-this` vs. `py-indent-that` or whatever (I don't even remember), try a good baseline distro like Doom and tweak from there.

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

#499
post #492

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…

> (no one does this! it’s got a heap-size from the 80s!) Shouldn't the devs do this? We're in 2024, embedded systems have more RAM, IO, etc than anything from the 80s.

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

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

#500
post #445

Earlier quoted context omitted.

33% according to the latest Stack Overflow developer survey. A healthy enough number to focus on that user base. I do think there are bubbles though. Macs are popular in SV, and there’s a very healthy portion of the developer community focused on this user base.

This is a pretty useless poll when trying to compare MacOS, Windows and Linux usage, because they split Linux up into different distributions. Because adding all numbers up, you get >100%, I suppose multiple-choice were allowed, which doesn't even allow adding all Linux-like operating systems together. So not really a good Argument that MacOS is used more... https://survey.stackoverflow.co/2023

If you look around the web, most attempts to answer this market share question land in roughly the same ballpark.

The argument is not that macOS is used more. The argument is that macOS is prevalent enough that it makes sense to focus on it as a market.

Post reply on HN