Zed on Linux Is Here | Hacker News Reader

Zed on Linux Is Here

zed.dev

923 points0xedb677 comments

Man, I'm conflicted. I mean, Zed works pretty damn well. So far my biggest annoyance with Zed though is that it's constantly trying to download language servers and other tools and run them. And sure, that's handy, but 1. I don't really want it, I'd much rather only use distribution-provided tools. 2. It doesn't work at all on NixOS, so it's just wasting its time and our bandwidth constantly downloading and trying to update binaries that will never run.

The thing is, I would just disable it, but you can't, as far as I can tell. There's this somewhat angry issue about it here:

https://github.com/zed-industries/zed/issues/12589

They might have a point but beyond whether or not they have a point regarding the fact that it automatically fetches binaries from the Internet, not having an option to disable it is just cruel.

I still like Zed a lot and I also have a big appreciation for the design of GPUI, which I think is a very well-designed UI library that puts focus on the important things. So, I hope it goes well.

After we finished prepping this linux launch, we've started work on making this situation better. Follow along here: https://github.com/zed-industries/zed/pull/14034

Oh, thank goodness. Yeah, that's going to be a major quality of life improvement for me. I had a feeling it'd eventually make its way into Zed eventually, but when I initially read the issue I was under the impression that there was no plans to add options around this, which I found confusing.

If any zed devs are in this thread: I highly highly suggest that any auto-download or upload (be it telemetry, plugins being downloaded, and worse: plugins uploading god knows what) is opt-in or at the very least easy to opt-out.

The eagerness to download stuff without my consent at the moment precludes me from using this e.g. in a job that touches a sensitive proprietary codebase.

This is a non-starter for many larger companies. With supply chain attacks being what they are currently, this would directly prompt Security teams to block this outright.

And with that all my interest is gone and I won’t bother with zed.

I highly recommend Little Snitch or opensnitch to protect oneself from rogue developers. Yes, anybody downloading things or uploading things without my consent is a rogue.

> It doesn't work at all on NixOS

Doesn't it work with:

  zed-fhs = pkgs.buildFHSUserEnv {
    name = "zed";
    targetPkgs = pkgs:
      with pkgs; [
        zed-editor
      ];
    runScript = "zed";
  };

Still not ideal though.

Oh sure, you can create an FHS and have it work, though personally I wouldn't. After all, Zed itself actually does work without an FHS, it's just that any binaries it tries to download will not. Which is actually not a huge problem in my case.

Weird, I just added `zed-editor` to my environment and it's fine.

NixOS is listed here: https://zed.dev/docs/linux

For me, works as expected.

I just tried it on NixOS 24.05. It starts, but nothing happens when I click "Open a project" or Ctrl+O. It's as if it lacks the ability to show a file selection dialog.

I really wish they would bundle up the basic Language Servers with the download (HTML, CSS, TypeScript) so it at least has parity with VSCode in this regard

Just a suggestion. One of the best features of pure text editors (and incredible, not all of them implement it) is autosave keeping the "unsaved" state of the file.

For example, if you make some changes in a file (new or not), don't save the changes, close and open the editor, the state of the opened files are kept like I never had closed the editor. The unsaved files are still unsaved. New edited files are still there, unsaved, ready to user manually save them.

Notepad++ works that way, and it is an amazing feature.

Similarly, I have unlimited persistent per-file undo turned on in Neovim. I can open any file I've edited previously and walk through the full history of how it got there. With Undotree [0], I can even navigate branching paths in development. I don't know how people live without this.

[0] https://github.com/mbbill/undotree

Sublime works this way and I do appreciate it

Working on it!

I think Emacs does this too, if you configure it, or even by default, using its backup files, that go by #some_name# or similar.

I wouldn’t mind auto saving and allowing me to undo changes from the previous session.

Jetbrains ides even have something like a shadow git.

Even Windows Notepad supports hot-exit now.

Is this if you close the entire editor? If you just close the file, do the changes remain next time you open it?

So does sublime. Indeed I rely on this behaviour almost unconsciously.

Atom worked that way as well

I have fallen in love with Zed on Mac, so glad to see it will still be an option when I switch back to Linux. My main concern is the collaboration features; just seems like a nonsensical addition. I have zero influence over what editors my teams use, and I work with dozens of different people on collaborative development every year - I'm not going to be persuading anyone to switch, and so that feature is just dead code and security risk. Even if I worked on a small and consistent team, I don't think the value-add justifies the complexity and risk.

For what it's worth, other major code editors Jetbrains and VS Code also offer real-time collaboration built in. For Jetbrains, it's a paid feature. For VS Code, it's free.

I love the VS Code implementation (haven't reviewed the other two). If I'm pairing with someone remotely, I don't have any issue having them download VS Code. We provide a config in our project repo for VS Code, so it's really quick for people to get set up enough to join the real-time collab session with me. `brew install visual-studio-code` and then `code .` in our repo, plus OAuth with Github to authenticate the collaboration feature.

I think it really is great. Makes pairing much easier, and really speeds up drugery like refactoring 500 cases where it doesn't quite make sense to do a codemod. It's not quite like the upgrade from Word97.exe to Google Docs since we have git, but it feels similarly amazing to "just" to be talking about some code, click the other user's icon to jump right to their cursor and help them get unstuck.

I personally bounce between VS Code, Xcode, and nvim+tmux, and I don't have a problem with keeping a "lowest common denominator" editor around for collaboration or pairing. I also keep a regular keyboard at my desk so I don't force people to type on my Glove80/Kinesis Advantage.

I do believe one can join collab sessions from https://vscode.dev/ as well? So no need to install anything, it runs well and officially in the browser

And for those with installed VSCode they need to add the Live Share extension to get this functionality, it’s not built in from the start, but offered through that official extension? https://marketplace.visualstudio.com/items?itemName=MS-vsliv...

My experience with the VS Code implementation has been constant desyncs between the editor state on the different users computers. At least some of them I could reliably reproduce by using language server commands.

The main reason I'm excited for zed is for an editor that built this in from the beginnings and has the same feature with less bugs.

As someone who hates Microsoft, I just wish that other colleagues wouldn’t force me to use their editor to collaborate. I wish there was more effort to build something editor agnostic.

I have felt similarly about collab tools. Even if the tools in an editor look cool, someone on the team is gonna get left out because they use a different tools. It feels a bit like the wrong layer for the collab tools to live.

Indeed, Tuple is a better solution. That said, I think Zed is a great text editor.

Absolutely agree, the collaboration features put me off a bit. I think it can very well become a very successful and popular editor without those features. Perhaps they can invest in those feature when they have a much bigger market share.

The collab features are actually what got me to try it, and why it’s still installed on my machine.

I have no reason to use Zed over Kakoune or VS Code for working on my own (open-source VS Code, so no Liveshare).

I wanted to work on code with someone a few weeks ago, and we both downloaded Zed and started collaborating very quickly. It was a very smooth experience.

What does Zed use as the UI toolkit? Looking at the code they have a handmade UI toolkit called gpui. Does that map directly to OS/DE specific GUI bindings? I can't find where that's happening

EDIT:

Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild

https://github.com/zed-industries/zed/blob/main/crates/gpui/...

> Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild

I grew up developing Windows apps using the native Win32 API:s, and there was nothing particularly daunting about it. Using what the OS provides shouldn't be considered such an outlandish idea, and being scared of it is causing stagnation and waste (looking at you, Electron). The code here is only a couple of thousand lines per platform; surely only a small fraction of the entire code base.

I'm not sure how much of it is people being (irrationally) scared vs. looking into native APIs and making the call that it just isn't worth it, given how much messing around you have to do to get basic functionality working vs. the web where you can throw a UI together very quickly to validate an idea.

I've looked into native Linux development a few times, for example, and haven't even been sure what's the best toolkit to use. It feels like you'd have to invest quite a lot in a particular toolkit to even see if it can do what you need, coming fresh from web dev like a lot of people who go for Electron obviously are (myself included).

We have a couple of blog posts digging into gpui, but here is one from just after rewriting and shipping gpui2: https://zed.dev/blog/gpui-ownership

We’ve slowly been building out gpui to be super ergonomic and fluid for us to build the kind of UI we need to.

As a designer that just picked up Rust last February it’s been really nice to have something that is so comfortable to work with without compromising our performance goals.

That's amazing, thanks for sharing this. Native desktop UIs are an area of interest for me so this will be an exciting read for me

I hope they add UI support for proportional type. I've bounced off the editor every time I've tried it since so many UI elements end up truncated or overly wide in general because of the insistence on fixed-width font.

Hey! Nate from Zed here - have you had issues with proportional fonts in Zed?

Let us know if so - they should just work™, but would love to know if that is not the case.

I wonder if they ever considered using Qt. Not sure what the status of that is for rust projects. Sounds like it does the same as what Z is doing, mapping user interaction to os bindings and rendering the UI using the GPU.

However silly it is, I've always hated the aesthetics of VS Code. I know it's themeable but despite that the overall look and feel just isn't right on MacOS or Linux. That side bar drives me crazy.

I find that out-of-the-box Zed is much prettier and feels more native than VS Code. But for a tool that we spend hours using each day, how it looks and makes you feel really matters.

I am enjoying experimenting with Zed. I have kept my extensions and configuration to a minimum which is a refreshing change compared to the cluster that my VSCode installation has become.

The first thing I do on any VS Code fresh install is to switch the sidebar to the right. Pure heresy for many people, I know. But I want my eyes to naturally land on code, not on a file tree.

Its actually pretty obvious advantage if you are often ctrl+b hide sidebar because instead of jarringly moving start of the line you are revealing code without moving it.

Same here! Also, when it’s on the right toggling it doesn’t move the code panes left and right.

Same. It also mean when toggling the bar what moves is the bar not the code.

The activity bar is the worst. Luckily you can move it and make it smaller.

  "workbench.activityBar.location": "top",

Just in case might as well try these..

  "editor.fontFamily": "'Monaspace Neon', monospace",
  "editor.fontLigatures": "'calt'",
  "workbench.iconTheme": "vs-minimal",
  "workbench.colorTheme": "GitHub Light",

  "window.commandCenter": false,
  "window.customTitleBarVisibility": "auto",
  "window.titleBarStyle": "custom",

> However silly it is, I've always hated the aesthetics of VS Code.

Thank god I'm not alone. Besides being unsightly, it also looks like a toy.

IntelliJ is much slower than any other editor including Zed and VsCode it's much slower to open and navigate, much slower to work with, much slower, it's so slow! but the code completion, refactoring, code navigation, and debugging features and endless other smart features are incredible. For me, that extra intelligence and code awareness boost translates to way faster development overall, even if the IDE itself takes a bit longer to load or work with or consumes huge amount of memory. Sometimes the smarts outweigh the raw speed.

If you're familiar with nvim, you slowly realize how bloated and unnecessary the indexing is in intellij. It makes the experience so awful and for what? A file search feature that takes multiple seconds to find a file in root

Indexing maybe. But there's more: IntelliJ understands your code, and this make more sense for static/strong typed langs. We do a lot of Kotlin and IntelliJ is indispensable.

Same. I was just using (heavily customized) vim for many many years, and was kinda ok, but then I eventually switched to IntelliJ products at work, and while I don't really like the idea of using a product with subscription, I cannot quite switch to anything again, and have to install them even on my personal machine. Didn't try Zed though.

And it's quite annoying that I really don't think that the product I'm actually using is something crazy complicated only an for-profit enterprise can implement. Just the same as in my vim-years, I only need a good editor, that helps me to type less. In interpreted languages (Python, PHP) I don't even use debugger, debugging via print actually feels totally fine to me. What I need seems pretty similar, and is seemingly included into every modern editor I know: vim-keybindings, good "code smell" highlightings, autocomplete & some refactoring automation. The devil is in the details though. Vim emulation is never perfect, but in IntelliJ it's usable, which doesn't happen often. Static-analysis IntelliJ does seems pretty basic to me, yet somehow even that level is usually lacking (also, the ability to disable specific suggestion via annotations in IntelliJ products is great, as I feel like this functionality is only really useful when I strive for 100% "green" status, just conciously disabling what I'm not going to fix). But the most annoying thing is auto-refactoring. I mean, it feels like a simple thing, I never tried, but I think most common refactoring patterns I do daily I could automate quite easily, given I already have basic syntax-tree operation implemented. But somehow even IntelliJ is pretty poor on refactorings, and what I've seen in VSCode plugins is even worse. Again, no idea about Zed. I guess I should try it.

What do you do to make Idea slow? On my computer, everything is blazing fast. Idea is very fast, like 1-2 seconds to open a project and then it's just works instantly. Same about vscode.

I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but:

1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most.

2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.

Eventually all the little inconveniences wore on me and I switched back to VSCode.

I will probably try it again after a few more releases to see if it feels better.

I'm on the same camp, but in the end it turns out we were not putting it to the actual, real, hard-world test.

VSCode is very fast for me, when I open it in the morning and just starting my day.

But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce scenario while changing code on the fly, then the test conditions are really set up where differences between slow/heavy and fast/lightweight software can be noticed.

Things like slowness in syntax highlighting, or jankyness when opening different files. Not to mention what happened when I wanted to show the step-by-step debugging of the software to my colleagues.

In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.

I think people just have very different tolerances for latency and slowness.

I keep trying different editors (including VS Code), and I always end up going back to Neovim because everything else just feels sluggish, to the point where it annoys me so much I'm willing to put up with all the configuration burden of Neovim because of it.

I tried out Zed and it actually feels fast enough for me to consider switching.

> I don't know what's on zed/VSCode and what's on the TS language server.

Microsoft's latest embrace-extend-extinguish strategy is keeping just enough special sauce in (frequently closed-source) vscode extensions and out of the language servers. They do the same thing with Pyright/Pylance.

Okay, call me weird, but why our standards have fallen so low?

VSCode may appear fast, but still has massive latency. The Zed website claims 97ms.

I can feel it is laggy.

Why can't we have response time under 1ms? Even 5ms would be a massive improvement.

For me latency is a massive productivity killer as it feels like walking in a swamp and it always puts me off.

> Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.

VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.

A few weeks ago I had this giant json text blob to debug. I tried Gedit first, and it just fell over completely. Tried vim next, and it was for some reason extremely slow too, which surprised me.

VSCode loaded it nearly immediately and didn't hang when moving around the file. I have my complaints about VSCode, but speed definitely isn't one of them.

I don't use it as my main editor (I'm far too used to the Jetbrains editors to make the switch, they're just too smart), but it's the best one for CLI apps that use EDITOR, like git. It boots up basically instantly even when it hasn't been launched in a while and I can make my commit messages and immediately close stuff up at the speed of my thought.

In the morning vscode is ok, come noon, it’s the primary thing eating my battery and it’s getting slower and slower; day end it’s unusable. Sure, restart it, I know, but it’s fairly terrible though.

Zed looked pretty cool but the amount of extensions VSCode has makes it difficult to justify a switch. I do think that the SQL extensions for VSCode are pretty terrible, so maybe that's something where Zed can capitalize.

Interestingly the biggest issues we're having with VSCode have nothing to do with the IDE itself and are instead related to the TypeScript language server. There are so many bugs that require the TypeScript language server to be restarted, and there's little the VSCode team can do about that. Made a new file? Restart. Rename a file? Restart. Delete a directory? Restart. Refactor a couple of classes? Might need a restart.

We're also having some serious language server slowdowns because of some packages we're using. And there's not much Zed can do here for us either. It's really unfortunate because the convenience of having a full-stack TypeScript application is brought down by all of these inconveniences. Makes me miss Go's language server.

Yeah, this was mostly my experience. The Zed editor was fast, but it just felt like it wasn't as good as other editors. For me, the version control integration was particularly poor - it shows some line information, but diffing, blame, committing, staging hunks, reviewing staged changes etc are all missing.

There were a bunch of decisions that felt strange, although I can imagine getting used to them eventually. For example, ctrl-click (or jump to usages) on a definition that is used in multiple places opens up a new tab with a list of the results. In most other editors I've used, it's instead opened up a popover menu where I can quickly select which really I want to jump to. Opening those results in a new tab (and having that tab remain open after navigating to a result) feels like it clutters up my tabs with no benefit over a simple popover.

Like you, I'll probably try again in a few releases' time, but right now the editor has so much friction that I'm not sure I actually save any time from the speed side of things.

You should give Theia Ide [1] a try. It's plugin-compatible with VSCode, same user experience. It's slower to start and takes more memory but on my 3 y.o. intel Mac it is definitely snappier than VScode.

[1] https://theia-ide.org/

> 2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.

I had similar experience with JavaScript where it kept showing me errors (usually for ESM imports) even though things were fine. In VSCode, things worked without fuss. I've been testing out JetBrains Fleet [1] as well and its language support is far superior compared to Zed.

[1]: https://www.jetbrains.com/fleet/

Hah, similar here. I keep trying it out after seeing posts here and there, but I can't seem to switch from VSCode.

For nearly anything I do it is fast enough, it starts in less than 2 seconds, and the main thing I like about VSCode is ability to switch projects with fuzzy autocomplete. That means I can jump between repos also in a few seconds, which is a huge lifesaver given I switch things frequently.

Zed is amazing for Rust and pretty good for C++. I feel like it's better for more systems-y languages than JS/TS etc.

I came from Visual Studio to vscode. VsCode looks super lightweight to me.

Yeah, I agree about VSCode being sort of fast enough. Computers are getting faster and I’m on a M-series mac which makes web rendering much faster but still I feel like as far as electron apps go: VScode is basically the golden child.

Slack & Teams on the other hand, ouch.

I have a mono repo. There's lot in it. And lot many files. Typescript. Go. Python. I have a lower end mac book Air. Not having any issues with VS code.

Yeah my experience has been that you aren't going to suffer performance problems with VSCode unless you have an incredibly large codebase. Past a certain point I'm sure Vim/NeoVim/Zed are probably much more performant, but the differences in smaller codebases is barely noticeable IME.

My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit.

My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.

> To install Zed on most Linux distributions, run the shell script below.

> curl https://zed.dev/install.sh | sh

Please stop telling people to curl pipe scripts into their shell...

Why? I’m going to run their software anyways. And this is a really easy way to run an installer.

This is basically the Linux equivalent of download and double click which is a user flow that is underrated for simplicity and usability.

Completely agree. Furthermore, you could always just not pipe it to sh, read it first if you care so much. Releasing and maintaining packages across a range of distros is extremely hard and time consuming, and they just released the linux version.

Because you don't know how the script is going to try to install the program. A double-click installer on Windows has a standard approach that results in the program being placed in C\Program Files and the files being tracked and an uninstaller being placed in a centralized location. On Linux, any random "installer script" could spew files all over your /usr or anywhere else with no way to clean them up. This could even break your OS.

The Linux equivalent to double-click installer is ... a double-click installer, Flatpak. Or for even more bonus points, make the app fully portable as an AppImage. In the rare case I can't find what I'm looking for in my distribution repos, I look for an AppImage.

macOS for example checks the crypto signatures of downloaded apps, so it’s much better than randomly executing code from the internet. I think even Windows does this nowadays.

Indeed!

Just release a flatpak, even a snap.

I’m not asking to support all distros. But at least one between flatpak and snap is enough to support pretty much all distros out there in a clean manner, not with curl | sh

Snap is never the answer. Every time I use snap I always get really sad, it could've been great but instead its incredibly slow. Like unusably slow

but then I will need curl | sh to install snap :(

I always see this comment and understand its reasoning, but people who check what they are installing are the same people who can download and check a shell script.

In this case it's 150 rows with spaces and comments and the first one is

# Downloads the latest tarball from https://zed.dev/releases and unpacks it # into ~/.local/. If you'd prefer to do this manually, instructions are at # https://zed.dev/docs/linux.

Then it's a download, extract and copy stuff around, it takes 1 minute to visually parse

If an install script is obfuscated then yeah, I'd skip it too.

Versus what? Everything you install involves trust at some point.

But linux [1] has absolutely zero security measures, and this has basically free reign over your computer to send off your .ssh folder, your browser cache, to install a permanent keylogger, etc.

[1] Standard “GNU”/linux desktops

Obviously most distributions provide package managers that should be used for unified automated update mechanisms and gpg signing. Superior to curl | sh in every way.

Very different levels of trust though. And different levels of effort for malware (burning zero-days is expensive).

Also, cleaner uninstalls. If the software only has access to specific directories, I can be reasonably optimistic that removal will be clean.

Furthermore, it is much more convenient. E.g., I can just winget install vscode instead of having to google download links.

> Versus what?

Can Linux have something like the Mac App Store where apps don't have access to the whole system by default?

Do you know difference between alpha, beta, and quality software? Linux distros have different goals, or different channels for different qualities of software, while vendors wants their users to be free alpha or beta testers.

I'm never using this editor unless it can install itself and work completely offline, without going for downloads and making web requests , it is crucial, especially after totally not related xz fiasco and the white house praise for rust.

I only use editors written in C, as God intended.

If you want a fast, low-memory-footprint editor with no spurious network connectivity and a conventional desktop UI, check out Geany: https://geany.org/

`unshare --user --net zed ~/file-to-edit.txt` seems to work fine. it just shows an "auto update failed" warning in the bottom, but seems otherwise functional. does that work for you?

> especially after ... the white house praise for rust

What's the threat model here, that Rust is a trojan language from the feds?

I installed zed a couple of days ago, tried it for a Java project. It was soooo bare-bone that it vanished from the drive shortly after.

Maybe I'm doing something wrong, I got java/maven plugins but there is no XML highlighting. Java does have highlighting but that's it... OH, and and I installed it this time and I noticed "downloading json-language-server"... (it was there before probably but didn't notice)... like WTF - didn't even ask if I want to... utterly rubbish experience.

For a simple text editor I prefer BBedit on mac, which is native and blazing fast. And for something slightly more complex I usually end up with `code <file>` to quickly edit it...

Zed does not support Java (see https://zed.dev/docs).

I don't see any way to monetize a free text editor but I see that they're hiring and also hired talented devs like Thorsten Ball already.

What's the business model here?

From their FAQ:

We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:

Channels and calls Chat Channel notes We plan to allow offer our collaboration features to open source teams, free of charge.

https://zed.dev/faq#how-will-you-make-money

Now see, I'm the opposite. I would like to pay a reasonable fee to drive a silver-and-oaken stake through the heart of the collab features. I will pay real money to just make it all go away. As others have said, I work in an environment with lots of different tools so collab stuff like this is just visual noise, let me turn it all off.

be cool and gain traction, to later extract profits?

And what's the license exactly? The EULA says reverse engineering is forbidden, but some parts are open source.

Amused that it is already an official package for Arch Linux.

https://archlinux.org/packages/extra/x86_64/zed/

Cool to see a new editor in the arena with a lot of resources behind it, but I'm trying to find the selling point besides "it's really quick".

Great feature but there's a lot more stuff I need for a truly outstanding editor, what are the novel pieces?

The bar is ridiculously for editors (vim & emacs configurability, vscode just works, jetbrains can do it all) - what will/does it bring to the table to compete?

I've been looking (for years!) for an editor with code highlight which can open single files as fast as notepad++ but on linux, I have to say I'm really happy about zed.

I also use it to open folders with source code and markdown documents without having to boot up an intellij editor

I really enjoy the AI assistant it has. One of the simplest easiest ways for me to interact with chatgpt/claude apis. Write prompt, copy, paste code.

> besides "it's really quick"

I can see the appeal, as the demo looks really smooth; then again, I'm a terrible slow developer, so personally I find saving few ms here and there irrelevant to my daily workflow

i definitely agree, and Id LOVE a snappy editor, but I struggle to trade thay off with everything else other editors provide

I'm using Zed for a couple of months now. As a Vim bindings user, my personal fav Zed feature is that the Vim bindings really work.

Zed is made by people who used Vim themselves.

that is actually really cool - I always felt like (and surely am not the only one) that vim is great keybindings but an okay editor. If someone addresses this that'd be incredible.

I was watching thorsten and the primeagen's chat yesterday https://www.youtube.com/watch?v=8XweSqTYdMQ and thorsten was describing a few challenges with translating vim's functionality into zed.

Part of it being that zed doesn't have an intermediate layer between keyboard input and keybindings, so by the time the vim layer is hit it has been translated to a keybindings - that limitation kind of put me off.

As a Zed developer, our killer feature is the parallel programming that our software enables. It's like pairing without the terrible parts.

I downloaded ZED for a quick play-around, but was quite shocked to find out that editing and saving a file runs an auto-formatter on it _by default_...

Whoever thought that was a great idea obviously has never worked with version control, with other people on a project? Sorry, but this is such an obviously wrong default setting, I'm surprised nobody pointed this out before?

Enforcing auto-formatting is a common practice in my experience. Currently working on a project where the repo will refuse commits that are not following the repo-specific formatting settings.

I think it is a sane default in 2024.

You can change this behaviour if that's really a problem https://zed.dev/docs/configuring-zed?highlight=Format#format...

Or there's a "save without format" command that I used once (when working on a pywal template for a zed theme, that is not valid json but Zed really wanted to format it)

Depends if there is actually well known standard to format. E.g Go or Rust has very commonly used defaults.

Can you please explain why auto-formatting conflicts with version control/collaboration?

Not sure it should be default, but auto formatting actually helps reduce git noise.

wrong for you, right for me

everyone on your team should be using a auto-formatter

Looks like they're developing their own Apache-licensed GUI framework for this, called GPUI. I think of text handling as one of the trickier parts of building such a framework, so one specifically made to support a text editor would seem to be a pretty good foundation for a general purpose GUI toolkit. I wonder if they (or someone else) will pursue it as an alternative to Qt.

GPUI is very cool, they have blogged about it before.

https://zed.dev/blog/videogame

Many UI libraries being built today want to be very forward-focused, so they focus on being as general as possible. This does make some sense, especially considering that, for better or worse, using a web browser engine as a UI has become increasingly popular of a decision. However, in the end this leads to almost all new "greenfield" UI projects trying to develop scalable vector UI rendering engines that need advanced and highly optimized vector rendering libraries like Skia and Pathfinder. Having everything in vector all the way through is elegant, but it's complicated.

The insight with GPUI is that it's not really necessary to be that general, the vast majority of UIs are made up of a relatively small number of different primitives that you can build on to basically do anything. So instead the vast majority of what's going on in GPUI is layers of roundrects. Text rendering is the classic approach of rendering into glyph atlases. I think this is a vastly more sustainable model for a UI library.

I don't know if GPUI is ready to be used on its own, but it does have a spiffy if brief website.

https://www.gpui.rs/

Given that Zed actually has good "UI-feel", it tells me they are focused on the right things. A lot of new greenfield UI frameworks are spending a ton of time on trying to build extremely generic vector graphics systems but the actual widgets feel bad and are missing all kinds of tweaks and nuance. Here's a good litmus test for text editors: what happens if you double click and drag? In most good UI frameworks, this should result in word selection and then expanding that selection left or right. In a lot of smaller greenfield UI libraries, something vastly less useful will happen :(

Lots of the app’s UI right now is a layer of components on top of gpui (check out the ui crate!) that are pretty Zed-specific at the moment.

Some of these things will likely be made more general and have dedicated gpui elements built for them (button, input…)

I think not rushing to cover everything right out the gates is giving us the time to feel out apis that feel good to write and work well for us. Hopefully in the near future that translates to a UI library that is awesome for the whole rust community to use.

Thanks for the links. The approach described in that blog post seems like it could actually achieve crisp, native-looking text. What a welcome improvement that would be compared to the blurry, misshapen, overlapping, or poorly laid out results I've seen from other new GUI frameworks.

Their toolkit is developed in their monorepo and is not on crates.io nor versionned, so they can do breaking changes any time. Seems risky to use in 3rd party projects.

Today, sure. That doesn't preclude it from maturing into something more generally useful, nor from eventually getting its own repo. I've built more than a few libraries that started out as functions and data structures within application code.

I have an old Intel Mac Pro 2015, which slowly transitioned from my working laptop to a personal use laptop. I'm using VSCode there and it works fine. I mean I've never faced any slowdowns because of the VSCode.

I had a small project coming up and decided to try out Zed. As it's a native app I thought it would perform better than VSCode. But to my surprise it was not the case. The performance was actually worse.

And as for the TS integration, the overall experience is worse than on VSCode. The autocompletion works in a weird way, no way to just look at available methods, I have to start typing. It's just frustrating. I even decided to give another go to Sublime Text and it felt much better than Zed.

So Zed didn't work for me, but I'm sure it will work for somebody else.

I've kept my neovim config, vscode, and zed configs in parity for a while now. To the point that the keybinds and behaviors are the same (or as simliar as they can be) across all three. In my personal experience zed is eating into the time I use vscode, but not really touching neovim as much. It really has come a long way, and I'm excited I'll be able to use it on my Linux machine without having to jump through hoops.

Tips please, esp configure vscode like nvim.

It comes down to using the vim extension and making use of the context it adds when setting key binds. Both in settings and keybind json files you set commands for certain vim modes, or bind native VSCode commands to your leader. Zed does almost the same but with no defined leader key so you just have to be more specific about the command and the context they are executed in.

Zed seems like its gotten a lot of buzz on HN, and its great to see new players in the space.

For those who have used it, what are some of the killer features?

For me the "killer feature" is a graphical editor (like VSCode or the Jet Brains editors) but with performance more like vim. I'm also very much enjoying the modal editing, which VSCode lacks.

For me, a couple things;

- fast enough to compete with neovim. Idk if it’s my previous interest in display engineering, but I substantially notice the speed

- vim bindings…. Satisfactory. I don’t struggle to navigate at all, feels pretty native to me. I can split panes every which way till Sunday

- collaboration mode is pretty great

- Ability to have your current pane magnified

- Ability to set your terminal font size to a different font size than your editor (been looking for this for years in a terminal emulator)

- Super clean and crisp ui. TBH it was too much ui when I first tried it, I stopped using it almost immediately. But I have it a second try and got used to it. It’s still a lot more than vim but hey

- Outline mode (pretty sweet)

- Multi-file buffers (makes editing text across multiple files stupidly easy)

- Cracked team. Awesome people, super transparent, just some sick engineers doing sick engineering

Besides speed, the other killer feature that Zed focuses on is collaborative editing:

https://zed.dev/docs/channels

I haven't used Zed in the last year, but Zed's search across codebase display was divine. I don't want to necessarily open the file when looking at search results to see additional context in the matching sections. Zed brings up a view with all the results where you can expand context, and IIRC even edit in the results panel without having to open the entire file.

It's also collaboration-first, and unlike VS code, I believe the software behind collaboration mode is open source

Its killer feature seems to be speed. Otherwise I dont see much of a reason to use it over VS Code.

No killer features, just nice ergonomics and speed out of the box. I use it as my Vim replacement.

I use it as my secondary editor (after Sublime) but could easily see myself switching in the not too distant future. It's incredibly fast, possibly even more so than Sublime, and really well designed. While the UI design of an editor is possibly not that important to a lot of people, I find it really matters to me for unknown brain reasons, I get anxious if I ever have to use VS Code as it has zero attention to design details.

I'm really pleased for the Zed team on reaching this milestone. I think the only thing holding me back from it being my daily driver is the built-in Pyright (which I hate) and lack of Ruff support.

Tried it with mangohud and scrolled up and down a 100-line c++ file with no lsp enabled. 30fps. Absolutely not ready yet. Not sure I'm willing to leave Emacs, but gpui looks cool and I hope someone makes a fast Emacs client with it some day.

Sadly I can't run it in WSL.

thread 'main' panicked at crates/gpui/src/platform/linux/wayland/client.rs:143:51:

called `Result::unwrap()` on an `Err` value: UnsupportedVersion

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I have been using it on Windows (native) after building it from source. Just for quick editing. It hasn’t crashed on me yet.

same. :(

Man, what kinda of QA do they have that they miss something like this? WSL can be considered the second largest Linux "distro".

Of course, zed has always felt like an osx first project with linux/windows being second class citizen.

Surprised they didn't make it a FlatPak. Probably would anger some, but it would work with most Linux distributions.

Is there anything stopping anyone from making it a flatpak and maintaining it? I'm personally not surprised that they're reluctant to take on more maintenance responsibility than necessary.

Definitely looks pretty rough so far (running Debian GNOME) -- font rendering looks wonky, and resizing the window is slow and unresponsive. But I'm very optimistic for what's to come!

Check out our troubleshooting page, you might not be utilizing the GPU!

https://zed.dev/docs/linux#troubleshooting

If that doesn't work for you, please file an issue, and let us know whether you're using Wayland or X11 :)

I like using zed when I'm on the MacBook. It's quite fast, looks good and has some neat features like multi file editing.

But I don't get the utility of all the collaboration features. It's noise to me, and feels like they could have invested that energy in other areas.

I work in a small fully remote team, and our tool of choice for collaboration is git. Why would I want to edit the same file while someone else is editing it too? Who will commit it? If I want to discuss a part of the code with someone screen sharing works perfectly. There's no need to bring in simultaneous editing.

It's such a technically hard feature to develop but just doesn't seem to have any utility for me.

I kind of feel the same about collaboration features, I never use them in any editor, just git and video calls/screen sharing. Ironically though the collaboration features are their monetization plan with the base editor as FOSS, so hopefully for them we’re in the minority on that opinion…

Zed is nice and all, but I simply cannot trust a VC backed editor of all things. Eventually, enshittification will occur and I really don't want that to happen to one of my core daily programs.

It's a ticking timebomb!

Still better than VSCode!

Whirlwind week.

First, Zed found to allow silent (non-consented) background binary downloads [0]

Now, launching on Linux.

Both of which are big news in its own right.

[0] https://news.ycombinator.com/item?id=40902826

> Zed requires a physical GPU with a Vulkan 1.3 driver.

That's new. Does everyone running Linux have a dedicated GPU these days? Only caught this because I'm in the middle of updating my nvidia driver.

I believe they mean “physical” as in not implementing in software. So integrated GPUs are perfectly fine as well.

The last collaborative editor that I could use locally successfully was gobby. Currently its development is very slow or seems abandoned. I've been waiting for Zed because it was introduced as something that was "multiplayer-first" from the beginning. Reading the docs now, it looks like I need a feature called "channels" that I couldn't confirm can be used fully locally. Is there a way to use Zed as a collaborative editor fully locally?

They've open sourced the server implementation too, but short of figuring out how to run that not that I'm aware of: https://github.com/zed-industries/zed/tree/main/crates/colla...

There's much to like about Zed. Not only the technical parts, but also how transparently the communication is: https://zed.dev/blog/zed-is-now-open-source

To keep things simple yet powerful is the key to find their place in the market IMO. Don't know about the rendering speed (never had issues with other editor), but that's a bonus anyway.

There's something interesting with the light mode / default theme I got after downloading and opening on Apple silicon:

Sidebar contrast is too low, yet, spot on for the wrong contrast ratio target (3.0, for fill, versus 4.5 for text/bg).

I'll file an issue on GitHub eventually, feel free to pass along email in my profile if y'all see this and have someone who is already nerding out on this stuff.

Context on why, and before I get more fuzzy/opinionated, why I'm comfortable speaking to this is some quasi-authoritative tone: I built a new color system that ended up being launched as Material You at Google, at its heart is getting contrast while having expressive colors instead of just flat black/white, so I really appreciate the effort here.

Fuzzy/opinionated territory:

Problem with the low contrast here isn't just that it doesn't literally hit a 4.5 ratio. IMHO this isn't strictly verboten, if I thought that it would mean the engineer part of my brain was too in control. There's an argument to be made its good the sidebar isn't distracted. Problem is disabled states traditionally lower the foreground brightness, so it crosses over into "disabled element" territory when you visually parse it.

We'd appreciate the issue and discussion! We've been aware of contrast issues for some time, and I personally have been thinking about switching our color representation from HSL to OKLCH to give us more traction on these problems. But I've been working on Linux and am not a designer, so I haven't had the chance :D

Sounds great; downloading it now to try.

To the Zed folks here, can you please add a little line to say that it is an editor, for people like me who are not in the loop. There's nothing clear on the landing page or on the docs page that indicates it is so. The video shows an editor, but plenty of software has built in editors.

My first impression is the dark mode color contrast is poor compared to VSCode defaults (I tested a few things with CCA Colour Contrast Analyser). I'm sure this is all configurable but it was off-putting to me. I'm still interested in spending more time checking out Zed.

https://en.wikipedia.org/wiki/Atom_%28text_editor%29#History...

I found the zed website unhelpful, but if wikipedia is to be believed, it's a successor to the Atom text editor

The Atom editor is being maintained as a fork: Pulsar https://pulsar-edit.dev

Zed is co-founded by one (or more?) original developer of Atom. So, it's a successor in a sense that it is a new project by the same author.

Atom was developed at GitHub, and GitHub Inc remains the owner of the original Atom project. From their perspective the successor of Atom is VSCode - developed by their parent company, - despite the claims by a former Atom engineer.

I gave it a fair try

Cons:

- spawning nodejs whenever you edit JSON files seems overkill, i'd prefer they use something native and more lightweight, or a way to completely disable it

- text still looks a bit blurry on low DPI screens

- doesn't support LSP properly, completion items are missing some data

- Rust for plugins.. this is painful, compare it to Sublime Text's python API, it's night and day..

Pros:

- Fast and responsive

- UI is simple yet effective

- drag&drop layouting, something i wish Sublime Text had..

- built-in terminal

- built-in Debugger (not yet ready)

Few more months of developments, and i'll certainly switch from Sublime Text, i'll be a little sad because i wrote plenty of plugins for it

I however worry about their business model, i have 0 interests in their AI/collaboration stuff, i'll probably maintain a fork to get rid of all that crap, they should setup something as a back up plan, a small paid license, just for support, i'll be happy to buy one

> - Rust for plugins.. this is painful, compare it to Sublime Text's python API, it's night and day..

Yes, this is unfortunate as they've unsuitably chosen the barely usable & unstable "component model" for their Wasm plugin layer. It's really only half-decent in Rust (to write the code & compile to CM non-standard version of wasm binary. it's also only truthfully usable to call components _from_ rust too.)

I think they are banking on the eventual support for cross-language async - which likely could never come, or could take longer than the company stays solvent!

> I however worry about their business model

For me, this is a showstopper. I don't want to use a text editor that even has a business model.

Is (Python) debugging on the roadmap somewhere for Zed, or will this remain out of scope?

I have a fast editor in Sublime already, but I’d consider jumping ship from VS Code to Zed if I can set some breakpoints and look at local variables and whatnot (very basic IDE stuff).

Not very good experience after opening a simple Python script with no external dependencies in zed for linux. They use Pyright and there was an error and warning that were both incorrect. VSCode uses Pylance IIRC and it's not complaining.

Awesome. Been looking for a next-gen Atom for coding. I use PyCharm most of the time, but sometimes its overkill with its eternal indexing ... :) So I often find myself bringing up SublimeText for working on individual files as opposed to a whole project.

Love it. My VSCode takes 3GB of RAM and that's a single window with like 5 files open at one time. I've long been looking for a good-enough replacement (though I don't think I'll be able to leave debugpy for a while)

As a longtime vim user text editing is not an unmet need or unsolved problem. Lack of time, energy to execute on everything is a much bigger problem. And the very biggest and most dangerous unsolved problems I can see on all our plates involve democracy and climate.

Heck I'd like to "solve" all issues with public restrooms in the US, for example, or the lack of planning for trees or shade or water conservation, first, before I'd spend time on Yet Another Hip New Text Editor. The latter is perhaps several hundred slot ranks down (at most generous to it) in my priority list.

I don't know if it's just me but vscode feels like it isn't as fast as it used to be. The terminal also keeps getting messed up on Linux.

Will definitely try one this out!

Although the amount of plugins and community knowledge of vscode is immense.

I don't really like their editor, but their fonts (based on iosevka) is my 2nd favorite (after Mensch).

And their opensource development mode is the best one I've seen so far! So many nice choices.

Unfortunately, they've switched out their Zed fonts for IBM Plex: https://github.com/zed-industries/zed/pull/13596

I do not get the focus on collaborative editing (surely niche?) while the Remote Development in VS Code (in which "remote" can mean in a docker container running on your local Docker, or a container elsewhere, or a whole-ass other computer you own, or a rented computer/instance in le cloude) seems like such a more game-changing feature, similar in some ways but probably less work.

And make that the thing you charge for. ¯\_(ಠ_ಠ)_/¯

Remote development is being worked on. It’s available in preview and has been assigned a priority task. https://zed.dev/docs/remote-development

Zed's dead, baby.

Great, the only reason I started using this on my work Mac was because the Linux version was coming + I would be able to use this at home on Linux.

Zed's focus on high performance might be misplaced. Compared to editors like VSCode, the performance boost feels marginal. To convince developers to switch, the emphasis should be on enhancing the overall developer experience. Marginal speed gains alone aren't enough to make me move away from VSCode, and I don't care if a tool is written in Rust or any other language.

Yep. As a VS Code user, I can’t say that improved performance has been anywhere near the top of my wish list for…half a decade, at least.

And yeah, I get it, boo hoo, electron, blah blah. There’s always going to be the rev head at all costs crowd. I don’t think that appealing to them should be this prominent through. The value proposition just isn’t there.

Generally a big fan of Zed. Super fast and quite innovative in their grep UI. My biggest current gripe is Zed's filesystem watchers are either broken or misconfigured on Mac. If I do a `git rest --hard` via terminal or github desktop UI, zed doesn't detect it and I'm forced to do a hard reset of the app to get back to a synced state.

I don’t think I could ever switch to a windowed app as editor, vs a TUI, eg neovim. The remote story is never great for me. It forces your editor to slowly bloat to become your entire IDE. Native remote dev using tmux is so nice. Can anyone persuade me otherwise?

> Native remote dev using tmux is so nice. Can anyone persuade me otherwise?

I sure as hell can't. SSH + Tmux has consistently been the only good pair-programming solution I've used in the past decade.

On Steam Deck it just exits, or rather it and the old node.js it bundles stays in memory. But no UI.

On one end of the spectrum, you have programmers who use Visual Studio Code or Atom or one of the other Electron-based code editors (https://en.wikipedia.org/wiki/Electron_(software_framework)), and at the other, you have programmers who use vim or even vi (https://en.wikipedia.org/wiki/Vi_(text_editor)).

Now, me personally (and this is just one man's tiny and insignificant opinion in a sea of billions of people!),

I personally, am slightly more inclined to give a slight bit of additional weight to the opinions of people closer to the vim/vi side of editor use, than I am to give to people on the Electron-based side...

My humble apologies if this offends anyone.

The same team behind Zed created Atom and the Electron framework. But that doesn't say anything about Zed either. The only thing that's shared between Zed and Atom is tree-sitter (https://en.wikipedia.org/wiki/Tree-sitter_(parser_generator)).

I wouldn't want a collaborative text editor that sends all my data to their servers, but I have incredible respect that they're very open and transparent about this fact on their website.

You don't see that kind of behaviour from Microsoft and Apple.

It worked well out of the box, but the font rendering is a bit off. Using x11, not wayland.

The default font was a bit small on a 4K resolution by default, but it was easy discover how to enlarge it.

Opening a Rust project worked flawlessly without any configuration at all.

I started using this a few hours ago and so far am really pleased with the experience. Vim keybindings mostly work as expected and TS integration works great oob. I can totally see this becoming my primary editor going forward.

I tried on Intel GPU ( dell xps 9305 ) with Ubuntu 20.04 and it does not open a window, with --foreground that's what I got:

zed --foreground

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

Is there even more debug available?

I'll have to figure out how to get it on NixOS. Always the challenge with Nix lol.

https://search.nixos.org/packages?channel=24.05&show=zed-edi...

Looks like someone was already maintaining an ebuild for Gentoo https://gpo.zugaina.org/app-editors/zed

Installed it on my Fedora 33 box running the AMD drivers from the kernel and a 6800 GPU and I can game no problem with proton and steam but Zed ran very very slowly. Sluggish. Immediately uninstalled. :/

Fantastic news. I've enjoyed using Zed on Mac for Go development, it just feels snappier than VSCode. I hope to try the Linux build over the weekend.

I am also tempted to try out their gpui library, might just cure my Rust aversion.

Anyone else get ~60-70% CPU usage when moving the mouse around? And no GPU usage.

We have a few words on this in our troubleshooting guide:

https://zed.dev/docs/linux#troubleshooting

Let us know if that doesn't fix it!

Yeah I get something like that too

Ah, I'd love to try this. But I have a hard cross-platform requirement (Windows/Linux/MacOS) and I can't seem to get this running in WSL. Will keep checking if that improves in the future.

Windows builds are out there. You can build it yourself as well. They haven’t matured as much as Linux ones yet. But your requirement of portability is definitely fulfilled.

If I understand correctly I need a graphical card - my current linux laptop does not have one. Until I upgrade to a newer model I will uninstall my copy of zed.dev - couldn't even launch it.

If you are using a monitor you must have one, I think. At least, an integrated one.

It's SO BAD when people say ":just pipe this shell script to bash!" for their installers. I just can't take those projects seriously if they think that's acceptable.

You can review the bash script first. Regardless, they provide a few different installation options https://zed.dev/docs/linux

I've often had the same feeling, but taking a critical view:

How is "run these bash commands", worse than "run this Python script", or "run these binary instructions on your CPU"? It all seems mostly the same.

What am I missing?

I am curious - if they provided a link to the script instead, would it have been ok? If you want to see the code before running, you can just redirect to a file before running it.

vim mode in the json settings:

"vim_mode": true,

Selection color is not particularly good with comments: https://i.imgur.com/ExeT7Ne.png

To save you time: If you're on macOS, you can install with

  brew install --cask zed

The docs don't make it very clear that the cask is available via homebrew.

The only reason why I dropped (and Im not alone) using Zed is the arcaic UI sublime-like search functionality. Please revisit that part because I really want to use ZED.

This is actually the first time I’ve seen someone unhappy with search - can you tell me a bit more what you are looking for?

There is lots of room for improvement of course, but I’d love to hear what your desired search experience is.

> arcaic UI sublime-like search functionality.

I've never used Zed, but Sublime is my primary editor specifically because of the incredible search functionality.

What do you use that's better?

Super excited for this project. Especially since it's available for Linux now.

I still use the JetBrains products as daily drivers but always keen to use new tools like this.

Does anyone know what is their monetization plan, or if they even have one? Editor with even this much polish takes a lot of time and effort. How is it being funded? Can we expect useful features to progressively get locked behind subscription as it grows in popularity (a la Gitlab)?

Edit: Nevermind, found it - https://zed.dev/faq#how-will-you-make-money. Interesting charter.

    We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:

        Channels and calls
        Chat
        Channel notes

    We plan to allow offer our collaboration features to open source teams, free of charge.

Edit 2: They have apparently also already raised money via private equity. I am quiet soured on "free" products which will almost always be enshittified as the pressure to turn profit grows.

> We envision Zed as a free-to-use editor, supplemented by subscription-based, optional network features, such as:

> Channels and calls

> Chat

> Channel notes

> We plan to allow offer our collaboration features to open source teams, free of charge.

https://zed.dev/faq

Yeah, I just can't get excited by anything this foundational that has monetization plans. While neovim is a pain to configure and will probably never be a polished "product", it's completely free to use, with no weird monetization features that might start out in good faith, but slowly creep into must-have parts of the software.

I'm perfectly willing to pay for some types of software, but for something as fundamental as my text editor, I want a model that doesn't depend on a company that needs money. That may sound a bit backward, as it otherwise depends on the goodwill of volunteer contributors, but that's the model I prefer and actually believe in.

Build a big enough userbase for big tech to want to buy it. It's the only game left outside ads. Worked for WhatsApp, Instagram, Github, Kaggle, etc.

No syntax highlighting for Clojure :'(

No Emacs keybindings :'(

I never got these new type editors compared to EMacs.

Pretty nice to see aarch64 packages for so many distros. Sublime packages are x64 only, so this will go well with my Asahi setup

To be honest speed and lightweight are important. But no as important as code completition and a good debug experience.

I tried on wsl, but dosent seen to work. I will have to wait for a windows version, since im stuck in windows by now.

Does Zed work with any language with a language server?

Is TypeScript support fully baked in? I don’t want to pay for things I don’t use.

I think you need extension which will integrate language server. I installed extension for Haskell and it works out of the box.

How to install/activate extensions? I saw that exists a directory called "extensions" in the repository.

There's an extension ui in the app.

Ctrl + Shift + X or use the top right dropdown menu.

I would love to give it a try but I am using WSL2 at the time being, so maybe in the future.

I couldn't find anything resembling "Send code to REPL", so no Zed for me.

@ people who have used both extensively: How does Zed compare to Sublime Text?

Interesting the decision[1] of building against glibc instead of musl. Any reason for not using musl instead (and doing a static binary)? This would avoid the compatibility issues e.g.: Alpine and Nix.

[1]: https://zed.dev/docs/linux

Can you even do GPU acceleration without dynamic libraries on Linux?

FYI, to launch Zed, run `'~/.local/bin/zed'`

If .local/bin is in your PATH you would be able to fire it up with just `zed`

Any word on whether this can be installed from the nixos repo?

Zed is damn fast, with large files and i love it's UI

Anyone got this working in WSL? Using WSLg perhaps?

Trying but not succeeding

Zed Shaw started a company called Zed Industries?

LOL no. The Zed founders are the guys who built Atom and Electron (and Treesitter): Nathan Sobo, Max Brunsfeld and Antonio Scandurra.

At first I thought this might be a creation of Zed Shaw (whose Learn Ruby the Hard Way, was the best introduction to that language, back in the day; and Mongrel was great).

Instead it's a creation of the team who built Atom, Tree-sitter and Electron. Pretty solid resume!

I can vouch for "Learn C The Hard Way" as well :)

Here I am still using Atom in 2024.

Tried installing on arch Linux, it wouldn't start and I gave up on the idea

neat! just installed it in podman, so far so good

Now they just need a flatpak…

We have a flatpak build! It's not on flathub yet though :)

https://github.com/zed-industries/zed/blob/main/docs/src/dev...

"real programmers" just use vim

https://xkcd.com/378/

Shoves ChatGPD with auto install of Node and what not else right up your throat. On top of that I can't install any extensions ...

Yeah ...

I'll stick with VScode, might be slow but works

is it for osx at first?

Is this better than VS Code?

Is there an Emacs keymap?

> To install Zed on most Linux distributions, run the shell script below.

This is not an acceptable way to install anything on Linux. If you want to target Linux users you can't distribute with a shell script for installation.

I get that the idea is to reduce friction to installation and trying it out, but most Linux users - the ones you want filing bug reports anyway - are ones who will do due diligence and inspect the shell script to see what kind of opinions it makes about how to install the software.

For example, I see that the shell script downloads a tarball and unpacks it to `~/.local`, then tries to mess with my PATH variable.

Well, my local directory is `~/local`. So that's not where I want it. Actually, I would want it in `~/local/zed`, isolated from the rest of the installations in there. Then the PATH variable stuff just creates junk files since I don't use zsh. So I end up having to figure out the URL to the tarball and install it myself.

My point is that if you just listed the download link to the tarball, it would actually be closer to your own goal of reducing installation friction. The shell script is so much more friction because I have to read bash code instead of just clicking a download link.

They aren't happy with this, either:

"[...]And of course, the journey isn't over yet－we'd love your help, particularly if you're excited about:

- Helping bring Zed to your distro. Either by packaging Zed or by making Zed work the way it should in your environment (we know many people want to manage language servers by themselves).[...]"

Give them a hand ;) https://zed.dev/docs/development/linux#notes-for-packaging-z...

> This is not an acceptable way to install anything on Linux

You might want to tell the rest of the software world how unnacceptable it is, because a huge amount of software, and especially dev tooling, is installed in this exact way.

It's especially hard for young or fast moving projects, most distro packaging just isn't very compatible with this velocity.

I'm personally on NixOS , which usually makes it easy to always get the latest and greatest, but eg would I really want to add a third party apt repository for Zed, which introduces complications and also can make changes to my whole system, rather than just having zed install itself in a local user-owned directory? I don't want to end up with 15 different third party apt repositories... adding those actually provides a higher amount of trust than shell scripts that only run with user permissions.

And there are similar considerations for most other distros. Arch is probably the only other one, next to nix, where it's quite easy to stay up to date.

(zed is already an official Arch package, btw, and before that it already was in aur, and of course it is in nixpkgs already)

It's not ideal, but whenever some pattern propagates across the ecosystem, there are probably valid reasons why.

I disagree. I’m on Linux for my main installation and I know I can inspect the bash script if I want to.

It’s impossible to please everyone. Pipe to sh is simple, transparent, and easy to do. If reading through 200 lines of installation script is too much then reading through thousands of lines of Zed’s code base will certainly be too much.

They also list other ways of installing https://zed.dev/docs/linux

My question is why they didn't just make a Flatpak. Then they and their users wouldn't need to go through any of this hassle and distro fragmentation at all. Even if they didn't want to publish it on Flathub, Flatpak supports single file packages people can directly install as well.

As a point of clarification, the script does not edit your zshrc file, it just prints a suggested edit that you may want to make to that file in order to add zed to your PATH.

>This is not an acceptable way to install anything on Linux.

If you think this is not acceptable, check out what they did last week: https://news.ycombinator.com/item?id=40902826

This is a fairly common way to install tools on Linux. Tailscale, Homebrew, Pi-hole and many others offer installations in this way.

> you can't distribute with a shell script for installation

Why not? It worked for me.

It's on NixOS and Arch I'm sure you just wait a little to get it on your Distro... I don't think they have bad intentions.

See https://zed.dev/docs/linux#other-ways-to-install-zed-on-linu... for distro packages.

> My point is that if you just listed the download link to the tarball, it would actually be closer to your own goal of reducing installation friction. The shell script is so much more friction because I have to read bash code instead of just clicking a download link.

It's there https://zed.dev/docs/linux#downloading-manually, it just doesn't show up as the default installation method.

Honestly, I still take that as an improvement over having to recompile it

> Well, my local directory is `~/local`. So that's not where I want it.

You can just move it after. .local is different from local so there is no clash.

This comes across as rather entitled. They offer an easy installation path that works for most people. They also went out of their way to provide alternative installation methods and instructions [1]. All while gifting you and the world free and open source software.

[1] https://zed.dev/docs/linux

Really dislike the one line installer. How is it installing? Flatpak? Adding an apt repo? Manual install?

Fortunately docs go into better detail, https://zed.dev/docs/linux

I'm on Debian anyway so who am I kidding expecting this to be in apt :D

Pipe the script to cat before you pipe it to sh and take a look. It's downloading an executable to ~/.local/bin. If that's not your preference, there are many other options for obtaining the software, via your distribution or manually. I feel the backlash to this pattern is pretty overblown. They're not attempting to hide anything, just make the common case convenient.

You can just read the script that you're curling rather than pipe it into sh directly. It seems like it just extracts the binary from a tar.gz and puts it into ~/.local.

It's already in the Arch Linux repositories, which is pretty cool: https://archlinux.org/packages/extra/x86_64/zed/

Yep, it's the same as running random code with root permissions.

Same as running random .exe from emails, but even without M$ signature.

Apt packages also have the root access, but official repositories at least have some paper trail and release process.

There is some support to flatpak already, see https://github.com/zed-industries/zed/blob/main/docs/src/dev...

I hope it gets packaged, on NixOS there's a package already on stable and unstable.

It's a basic download and extract script. Also creates directories as per XDG spec.

I really don't get why this is the modern editor style of choice.

20% (35 chars) of screen space permanently wasted on a always on file browser (meanwhile the animation showcases fuzzy finding)

4% (7 chars) of screen space permanently wasted by line numbers (why are the numbers cut off on the right?)

2.7% (5 chars) of screen space taken up by a gutter

So 27% of screen space effectively dead 99% of the time.

Why do people do this to themselves?

I can't quite figure out how to get the gutter to truly only appear when needed (I can't remember why) but in my vim configuration 2 chars of space are taken up by the gutter and the rest is for the actual code. The current line number is in the bottom right, and if I need to go to a specific line number I have `G` for that. If I need a file explorer, there's the default Netrw one, there's NERD Tree, there's a terminal (I actually rarely need this anyway, but I can understand not everyone can cope, but I can't comprehend why you would need it on 100% of the time).

Why does the "modern text editor" waste so much screen space?

I have a 1200p laptop monitor which gives me 174 chars of horizontal space at a comfortable font size. If I split that in half I get two terminal windows worth of 87 characters each. If I keep my code under 85 characters per line, not only is it easier to read, I can keep a man page or another piece of code on the other half of my screen.

> 20% (35 chars) of screen space permanently wasted on a always on file browser

That is toggleable. Cmd+B on Mac. I usually keep it closed, but it's just a shortcut away when I need it.

> 4% (7 chars) of screen space permanently wasted by line numbers

You can disable that in the settings with:

"gutter": { "line_numbers": false }

> 2.7% (5 chars) of screen space taken up by a gutter

You can also disable the other items in the gutter to free up all of that space.

> So 27% of screen space effectively dead 99% of the time.

You can also press shift+esc at any time to toggle a fullscreen pane of whatever you are working on when you need more space without affecting your editor's state. I don't know the name of that action, I actually found that accidentally.

Edit: I forgot to mention, you can actually disable the tab bar now too if you want even more space. You would just need to rely on the tab switcher feature or file search to move around.

I haven't tried Zed and am unlikely to, but I get 238 characters of fantasque sans mono 11pt on my 1200p screen, so I could give up those spaces and still have two vertical panes (assuming Zed supports vertical panes and the file-browser isn't duplicated).

I agree with you and probably have a similar setup to you.

There's a % of people that like to think deeper about their tools, but I think most folks don't care enough or might be struggling with higher priority things at work. Plus, you don't know what you're missing.

For me, good setup is like compound interest that just keeps paying off over time.

> The current line number is in the bottom right, and if I need to go to a specific line number I have `G` for that.

How would you know which line number to go to? You see that word half a screen up, what's its line number?

You can close the left dock (ctrl+b for me). The gutter is still huge, though.

First impressions:

  1. curl | sh, seriously
  2. The default theme is so low-contrast that I seriously struggled to read text. I could not find something that was, like, actual white on actual black.
  3. I can figure out how to enable Copilot, but not to open a file. (I had to resort to “zed file.cpp” from a terminal.)
  4. vim keybindings are not bad, but also not perfect.
  5. It feels… laggy? Isn't this supposed to be fast? Whenever I move the cursor over a symbol, it first moves and then like 100 ms later, it tries to highlight that symbol everywhere. And that takes time. In a 200-line file.
  6. Ugh programming ligatures. Where are preferences to turn it off? Where are the preferences for anything?

OK, well, I guess I could use this if I had nothing better. But if the point is that it's supposed to be zero-lag, #5 really destroys the point for me.

> 1. curl | sh, seriously

It's pretty much guaranteed to work cross-platform, and if you're worried about it you can save the script and view it yourself. You're about to run their binary on your machine, why are you concerned about the script you're downloading?

> 2. The default theme is so low-contrast that I seriously struggled to read text.

The landing page when I opened the app had an option to choose from about 40 themes. I tried 3 of them and they were no _worse_ than VSCode's defaults.

> but not to open a file.

usual keyboard shortcuts, and system menu bar?

> Where are preferences to turn it off? Where are the preferences for anything?

System menu bar, which links out to some fairly comprehensive docs - https://zed.dev/docs/configuring-zed

I agree on the vim keybindigs and the performance, though.

I couldn't even get it to run at all. It's in the official repo of my distro, but when I installed that package and tried to execute it, the binary launched another executable with a 'zed-cli://' URI pointing to some socket/named pipe it tried to create under /tmp (but didn't) as an argument, then just sat there doing nothing. Seems like it's doing some sort of local client-server implementation -- not sure why a standalone desktop app would be designed that way.

It never spawned a window, and possibly because the process is itself launching another process, nothing is output to stdout or stderr to indicate what's going on.

Apparently opening files is so complicated it requires an external helper program. https://zed.dev/docs/linux#opening-files-does-not-work

Re: #2, use

"buffer_font_weight": 600

in the settings.json to fix the font rendering.

I'm a sucker for text editors. I've used so many at this point. Notepad++ from way back. Anyone remember Komodo, the Perl focused text editor from ActiveState? BBEdit. TextMate. Sublime text. Atom. Visual Studio Code. All kinds of IDEs from Eclipse to the IntelliJ family and the full fledged Visual Studio. I've used many flavors of vim and learned emacs multiple times. I doubt I've named half of the editors I've used.

I'm at the point where I just can't motivate myself to try yet another. In my experience, they all have their strengths and weaknesses. My rule of thumb now: use whatever the majority of people on my team use. For non-team related work I find the community around Visual Studio Code to be good enough that it does what I need most of the time. I use bog-standard vim when I ssh into boxes.

komodo the editor (i recall it as a semi-commercial alternative to eclipse, much like intellij, but based on mozilla UX code?) was funny, because exactly the time it got traction and people started to talk about it, the tech news were inundated with Comodo the TLS operator caught doing shaddy stuff (and if i recall, blaming some hackers)

didn't hear much about komodo till now

Seems like a good VSCode alternative, but I'll stick with my editor of choice. I imagine it will be 1~2 years before Zed is bought by Microsoft and either squashed like Atom or replaces VSCode.

Reply on news.ycombinator.com