Zed on Linux Is Here


633 points | by 0xedb 14 days ago


  • handsaway 14 days ago
    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.

    • j1elo 14 days ago
      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.

      • vmfunction 14 days ago
        > 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.

        Same can be said about a lightweight web page and 'React' with tons routers all in SPA and vdom. Maybe the page is fine when it is the only page open, but when there are other SPA also open, then even typing becomes sluggish. Please don't use modern computer's sheer power to camouflaging poor software performance. Always make sure the code uses as little resource as possible.

      • chillfox 14 days ago
        I have had to open the parent folder of all the different code bases I need in a single VSCode window, instead of having an individual window for each.

        I much prefer having individual windows for each code base, but the 32G of ram for my laptop is not enough to do that.

        If I were to run multiple instances of VSCode, then the moment I need to share my screen or run specs some of them will start crashing due to OOM.

      • Ygg2 13 days ago
        > In summary: our modern computer's sheer power are camouflaging poor software performance

        I somewhat disagree. Features sell the product, not performance[1], and for most of the software development you could count on the rising CPU tide to lift all poorly performing apps. But now the tides have turned to drought and optimizing makes a hell of a lot of sense.

        [1] They are more of a negative sell and relative to other feature parity products. No one left Adobe Photoshop for Paint, no matter how much faster Paint was. But you could if feature parity is closer, e.g. Affine vs Photoshop.*

      • veidr 14 days ago
        Yeah, all I need to do to reliably show the drastic performance difference is open 5 different windows with 5 different versions of our monorepo. I frequently need to do that when e.g. reviewing different branches and, say, running some of the test suites or whatever — work where I want to leave the computer doing something in that branch, while I myself switch to reviewing or implementing some other feature.

        When I start VS Code, it often re-opens all the windows, and it is slow as hell right away (on Linux 14900K + fast SSD + 64GB RAM, or on macOS on a Mac Studio M2 Ultra with 64GB RAM).

        I'll save a file and it will be like jank...jank... File Save participants running with a progress bar. (Which, tbh, is better than just being that slow without showing any indication of what it is doing, but still.)

        I've tried to work with it using one window at a time, but in practice I found it is better for my needs to just quit and relaunch it a few times per day.

        I try Zed (and Sublime, and lapce, and any other purportedly performant IDE or beefed-up editor that I read about on this website or similar) like every couple months.

        But VS Code has a very, very large lead in features, especially if you are working with TypeScript.

        The remote development features are extremely good; you can be working from one workstation doing all the actual work on remote Linux containers — builds and local servers, git, filesystem, shell. That also means you can sit down at some other machine and pick up right where you left off.

        The TypeScript completion and project-wide checking is indeed way slower than we want it to be, but it's also a lot better than any other editor I've seen (in terms of picking up the right completions, jumping to definition, suggesting automatic imports, and flagging errors). It works in monorepos containing many different projects, without explicit config.

        And then there's the extensions. I don't use many (because I suspect they make it even slower). But the few I do use I wouldn't want to be without (e.g. Deno, Astro, dprint). Whatever your sweet set is, the odds are they'll have a VS Code extension, but maybe not the less popular editors.

        So there is this huge gravity pulling me back to VS Code. It is slow. It is, in fact, hella fucking slow. Like 100x slower than you want, at many basic day-to-day things.

        But for me so far just buying the absolute fastest machine I can is still the pragmatic thing to do. I want Zed to succeed, I want lapce to succeed, I want to use a faster editor and still do all these same things — but not only have I failed so far to find a replacement that does all the stuff I need to have done, it also seems to me that VS Code's pace of development is pretty amazing, and it is advancing at a faster clip than any of these others.

        So while it may be gated in some fundamental way on the performance problem, because of its app architecture, on balance the gap between VS Code and its competitors seems to be widening, not shrinking.

    • the_duke 14 days ago
      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.

      • whalesalad 14 days ago
        Sublime Text 3 is still one of my favorite editors. I use VSCode lately because of its excellent "Remote SSH" integration - but when it comes to latency sublime has it beat.

        Zed does not feel fast on my machine, which is a 13900K/128gb ram. It is running in xwayland though, so that could be part of the problem. It feels identical to vscode.

        • wheresmyshadow 14 days ago
          Sublime Text gang, raise up.

          I was always a fan of Sublime Text and I moved away from it once because VSC felt more "hassle-free". The extensions just worked, I didn't need to go through endless JSON files to configure things, I even uncluttered its interface but at the end of the day I returned to good old Sublime Text. Now with LSPs it requires way less tinkering with plugins. I only wish it had just a little bit more UI customizability for plugins to use (different panes etc). Maybe with Sublime Text 5 if that ever comes.

          Also about the speed: VSC is fast but in comparison... Sublime Text is just insta-fast.

          • pjmlp 13 days ago
            It is hard, when so many in our industry are cheapstakes and don't want to pay for their tools, like in every other profession.

            They rather suffer with VSCode than pay a couple of dollars for Sublime Text.

          • ziml77 14 days ago
            ST4 is my go-to for quickly viewing and editing individual files. It really is instant compared to VSC.

            I don't really run ST with any complex plugins though and leave cases where I want those for VSC. The ones I have installed right now are just extra syntax highlighting and Filter Lines (which I find very handy for progressively filtering down logs)

            • whalesalad 14 days ago
              I still use ST for opening huge files. 9 times out of 10 if a huge file cannot be opened in any other editor, I will open it in subl and it will be just fine.
          • ElectronBadger 14 days ago
            I'm all for Sublime Text and Merge, my daily drivers for all kinds of writing..
          • ilrwbwrkhv 14 days ago
            I have used Sublime Text my entire pro programming career. Before that I used emacs for a while.

            I love it and will not switch it for anything. It is maybe one of the best pieces of software ever made. A lot of the things such as multiple cursors, command palette etc where first popularized by ST.

            Today, I use it to write Rust, Go, web stuff and with LSP I get all the autocomplete I need. I also use Kitty as a separate terminal (never liked the terminal in editor thing).

            Things like Cmd-R and Cmd-Shift-R to show symbols in file and symbols in project work better, faster and more reliably than many LSP symbol completions.

          • g8oz 14 days ago
            I feel the same way about Notepad++
            • whalesalad 14 days ago
              notepad++ is a respectable editor but sublime defeats it at everything except price.
        • jwells89 14 days ago
          Sublime's focused/minimalist UI is nice. VS Code sometimes feels like it tries to do too much.

          My ideal editor would probably be something like a variation on Sublime Text that's modeled more closely after TextMate while keeping the bits that make Sublime better (like the command palette).

          • whalesalad 14 days ago
            Sublime is the better Textmate. What would you do to subl to make it more like mate? I used textmate for years and years before switching to ST and it was a drop-in replacement.
            • jwells89 14 days ago
              The two are pretty close, but between the two TextMate feels more like a golden era OS X desktop app thanks to several small differences and tiny Mac-isms, and I'd like Sublime to have that feel too.
              • the_other 14 days ago
                I also feel TextMate had the nicer overall UX. When I first tried Sublime, TextMate had the better text rendering (IMO). Sublime has more features but still doesn’t feel as slick somehow.

                I’ve recently returned to Sublime from VSC. I prefer VSC’s UI for following links to definitons/references, but in most other ways I prefer Sublime’s nimbleness.

        • correct-horse 14 days ago
          | It is running in xwayland though

          It definitely isn't on my system, and I did not touch the configs at all; are you sure about that?

          • whalesalad 14 days ago
            Fairly positive due to blurry cursors, but I have no way to verify.
            • ndiddy 14 days ago
              If you run xeyes and the eyes follow your cursor when it's above the application you want to test, it's running under xwayland. If they don't follow your cursor, the application is running under native Wayland.
              • whalesalad 14 days ago
                Welp, looks like it is running native wayland yet the cursors are blurry. The only time I have ever experienced that is when an app is running under xwayland.
              • 369548684892826 14 days ago
                finally a use for xeyes?
                • ndiddy 14 days ago
                  I don't use vanilla xeyes but I use the Window Maker dockapp version (https://bstern.org/wmeyes/) to make it easier to find my cursor on the screen.
                  • shrimp_emoji 14 days ago
                    Ha. KDE 6 has something like if you jiggle the cursor a certain way, it temporarily grows larger.

                    Better than Windows's function of "hide all my windows"...

                    • whalesalad 14 days ago
                      I think every OS has this feature. Sometimes it is hidden in an accessibility menu and needs to be turned on.
                    • BrandoElFollito 14 days ago
                      Pressing some key a few times in Windows highlights your cursor. I just can't remember what it was (Ctrl I think)
                      • jacekm 14 days ago
                        Yup, Ctrl twice.
                • lagniappe 14 days ago
                  I always run xeyes in any net-enabled gui. iykyk.
            • executesorder66 14 days ago
              If you run xlsclients it will list all applications running through xwayland.

              [0] https://archlinux.org/packages/extra/x86_64/xorg-xlsclients/

              • whalesalad 14 days ago
                Oooh, thank you this is very convenient. Confirmed zed is not listed here.
      • barnabee 14 days ago
        I use Helix and feel the same way. The pickers/fuzzy finder particularly have no equal for speed in any editor I’ve found. (Zed seems pretty fast but I didn’t get on well enough with it to find out how it performs with more serious use.)

        fwiw I’ve also found the configuration overhead much lower with Helix than for pretty much any other editor I’ve seriously used.

        • danielvaughn 14 days ago
          This makes me want to use Helix, because while I love the idea of a terminal editor, I'm not the kind of person to whittle away a day screwing around with my config files.
          • zamalek 14 days ago
            Helix has been stalled for a few months, and there are issues that make it frustrating to use at times. For example, :Ex and friends have been relegated to the plugin system (the root cause of the stall, it hasn't been merged). I still prefer it to the config overhead of nvim (as well as the kakoune-style movements!), but the paper cuts have hit a threshold and I've started writing my own text editor (I'd probably use Zed, were it not for lack of kakoune movement support): https://youtu.be/Nzaba0bCMdo?si=00k0D6ZfOUF8OLME
            • dorian-graph 14 days ago
              Stalled how? There was a release a couple of months ago. There's another on the way. There are regular changes merged in. There's been foundational changes (events) made to enable new features. The plugins are being worked on, and whilst the speed may not be for you, that doesn't mean its stalled?
            • spiderice 14 days ago
              The Helix community is the worst part about Helix. Especially the not so benevolent dictator of the project. Way too many comments like “if you don’t like how it’s done go use a different editor” instead of listening to feedback. That’s fine if they don’t care about adoption (they publicly say they don’t), but an actively hostile community doesn’t give me confidence in the editor, despite it being quite nice.
          • lytedev 14 days ago
            It's the main reason I switched from Neovim. I didn't want to maintain a thousand lines of Lua of stuff to have a good baseline editor. I only wanted to maintain my configuration idiosyncracies on top of an editor with good defaults. I think there are Neovim distributions that accomplish mostly the same thing, but then I fell in love with Helix's Kakoune-inspired differences.

            Give it a try! It's lovely.

      • satvikpendem 14 days ago
        Zed is still quite a bit slower than Neovim in my experience.
        • ungamedplayer 14 days ago
          Neovim is quite a bit slower than cat and echo.. in my experience.
      • hn92726819 14 days ago
        > people just have very different tolerances for latency and slowness

        I've honestly never considered this and it's genius. I have always been surprised when people recommend kitty as a "fast" terminal when it takes 200ms (python interpreter) to start up, which is unbearable to me.

        But yeah, people sometimes just open a couple and see speed in other areas that I don't care about.

    • giamma 13 days ago
      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/

    • hamandcheese 14 days ago
      > 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.

      • IshKebab 14 days ago
        And the remote SSH and C++ extensions, though that actually has a good alternative in the Clangd extension.

        I'm kind of ok with it tbh. As a monetisation strategy it's not the worst, and I have no expectation that they just do all this for free.

    • silisili 14 days ago
      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.

      • nicce 14 days ago
        Did you have some plugins in vim? It is very odd if it was slower in this scenario.
        • silisili 14 days ago
          Not to my knowledge, outside of whatever Debian comes with. Keep in mind this was on a Chromebook - so it would have been running in a VM on a rather memory restricted system. That said, VSCode would have been running in the same parameters.

          Just found the file. 42MB on a single line. Takes 5 seconds to open in vim, and about 3 seconds for the right arrow to move the cursor one char over. Nothing like gedit, but slower than I expected.

          • tschumacher 14 days ago
            I'm pretty sure this is syntax highlighting. It's a known issue to be slow for large files in Vim because it is synchronous. Try starting Vim with syntax highlighting off:

                vim -c 'syn off'
            • silisili 14 days ago
              Yep that helps a ton, thanks. Now it behaves more like nvim, and cursors around much faster -

              $ time vim -c 'syn off' tt.json

              real 0m3.277s user 0m1.690s sys 0m0.349s

              • j1elo 14 days ago
                This makes sense. I recently learned that VSCode is clever enough to automatically disable some features (which includes syntax highlighting among I guess other things) when it detects that the file is too big according to some heuristics (like probably, length of the longest line, or maybe just total size of the file).

                So IMO I think vim is being "too dumb" here and should be able to adapt like VSCode does. But, meanwhile, if you want to test under equal conditions, you can disable VSCode's optimization by disabling this setting:

                Editor: Large File Optimizations

                Or directly in settings.json:

                    "editor.largeFileOptimizations": false
                • maccard 14 days ago
                  > But, meanwhile, if you want to test under equal conditions, you can disable VSCode's optimization by disabling this setting:

                  Disabling the advantages of one application vs another is just kneecapping the superior editor IMO.

              • tschumacher 14 days ago
                Interesting. I expected it to be near instant without syntax highlighting but it's still slow.
                • davorak 14 days ago
                  It is odd that it is slow. On my 2019 macbook pro


                  new more realistic example: time vim -c 'syn off' <64 MB>.txt vim -c 'syn off' <64 MB>.txt 0.41s user 0.20s system 32% cpu 1.848 total


                  Here is my first, pre edit, example which is invalid. The file was a zip and my install of vim was not opening as text or binary

                  % time vim -c 'syn off' <48 GB file> vim -c 'syn off' <48 GB file> 0.03s user 0.03s system 2% cpu 2.380 total

            • goosejuice 14 days ago
          • nicce 14 days ago
            Just curious, what of you do the same with bare neovim, for science?
            • silisili 14 days ago
              Sure, just tried it. This is time to open, show the initial contents, then exit. nvim is much faster to cursor around, except when you hit the opening or closing of a json block it hangs a bit, so I'm guessing it has some kind of json plugin built in.

              $ time vim tt.json

              real 0m5.910s user 0m4.120s sys 0m0.343s

              $ time nvim tt.json

              real 0m2.894s user 0m1.372s sys 0m0.292s

              • nicce 14 days ago
                I did some research and it seems that this particular slowness is due to single line file and if there is some syntax highlighting used with vim/neovim, it reads the line completely to do it correctly.

                VSCode reads only the visible content and does not load everything for that line. It tokenizes the first 20k chars of the line at maximum, defined by the "editor.maxTokenizationLineLength" setting.

          • iso8859-1 14 days ago
          • crabbone 14 days ago
            > on a single line

            This makes a world of a difference when your editor is configured to wrap lines, or clip or w/e.

            You probably happened to have VSCode configured to do something that mitigates the problems of having an extremely long single line, while Vim was not configured to do that.

            In case you don't want to investigate the problem, but want to make a more "fair" comparison: use a language that you are comfortable with to format the file with linebreaks and indentation and then load it in different editors.

            • maccard 14 days ago
              > You probably happened to have VSCode configured to do something that mitigates the problems of having an extremely long single line, while Vim was not configured to do that.

              Defaults matter.

              • nicce 14 days ago
                For mainstream users. Particularly in the case of vim, the end-user is more likely the figure out that this is a configuration problem and can be adjusted.
      • angra_mainyu 14 days ago
        For this kind of stuff Sublime has always been extremely good.

        But I still struggle to find a reason to not use neovim, it's replaced all my editors.

      • satvikpendem 14 days ago
        Weird, I had the exact opposite experience. I had a large Markdown file I was editing and VSCode would simply hang or crash when opening it. Neovim on the other hand actually was able to navigate and edit just fine.
      • wraptile 14 days ago
        I work with giant jsons every day and always have to fall back to nvim as vscode is terrible. Vscode even has a default size limit where it disables editor features for json files larger than a few megabytes.

        Nvim works flawlessly tho even with syntax highlight and folding.

      • ThinkBeat 14 days ago
        I believe VsCode has told me several times that the file i want to open is too big.
        • tills13 14 days ago
          It's more of a suggestion/question than a hard limit though, no? "Are you sure you want to open this 4GB file?"
    • sensanaty 14 days ago
      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.
      • theoperagoer 14 days ago
        +1 for the Jetbrains gang.
        • Aeolun 14 days ago
          The plus side for using Jetbrains is you can switch to literally anything else and it’ll feel lightning fast.
    • anonzzzies 14 days ago
      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.
    • microflash 14 days ago
      > 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/

    • MrJohz 14 days ago
      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.

      • Aeolun 14 days ago
        Have to agree on the VCS story. I’d switched over to using Zed more or less permanently, but I eventually moved back because I kept having to open Intellij to resolve conflicts.
        • worthless-trash 14 days ago
          As I don't use either, can't you just open the file and look for

          >>>> and <<<< and resolve them in whatever editor you need ? or do these editors do something else that helps with merge conflicts ?

    • varispeed 14 days ago
      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.

      • hyperbrainer 13 days ago
        I just want to point out that most keyboards hav a latency at 10-20 ms[1], so 1 ms is impossible.


        • NoahKAndrews 13 days ago
          That includes the physical travel time, which is an extremely important caveat.
          • hyperbrainer 13 days ago
            Sure. But that is what the experience is, right? When I press a key, the entire end to end latency is what I care about.
      • whalesalad 14 days ago
        I agree with you -- but aiming for 1ms performance is pretty hard. That is 1/1000th of a second. Your keyboard probably has higher latency than that. Physics cannot be defeated in this regard.
        • garblegarble 14 days ago
          Expanding on this, there's a detailed analysis of the various contributors to editor latency (from keyboard electronics to scanout) by one of the jetbrains devs at[1]. They show average keypress-to-USB latency for a typical keyboard of 14ms!

          1: https://pavelfatin.com/typing-with-pleasure/

      • scblock 14 days ago
        A typical 60 Hz screen refresh is 16.7 ms
        • jay_kyburz 14 days ago
          If you haven't tried a 144hz or even a 240hz gaming PC, you should. You can really feel the difference dragging things around the screen.

          (I'm not sure I would notice typing, but for dragging windows around I could never go back to 60fps.)

          • Ygg2 13 days ago
            You can notice higher frame rates if you're in a competitive FPS, not a code editor. Unless you are playing CS2 in Emacs.
          • mirpa 14 days ago
            I can certainly tell difference between 60 and 120 Hz in fast paced games, but I would not notice it in UI.
            • FireBeyond 13 days ago
              I thought so too, but for a while I had 2 144Hz monitors on my Mac Pro[1] and very much noticed it in the UI, window dragging was smoother, browser scrolling too, absolutely noticeable.

              [1] Then Apple released the Pro Display and Big Sur and people wondered "how does the math work for a 6K display and bandwidth?" The answer, they completely fucking broke DP 1.4. Hundreds of complaints, different monitors, different GPUs, all broke by Big Sur to this day just so Apple could make their 6K display work.

              My screens could do 4K HDR10 @ 144 Hz. After Big Sur? SDR @ 95 Hz, HDR @ 60Hz. Ironically I got better results telling my monitors to only advertise DP 1.2 support, then it was SDR@120, HDR@95Hz.

              Studiously ignored by Apple because they broke the standard to eke out more bandwidth.

      • silisili 13 days ago
        I grew up a damn good HPB Q1 player at 250ish ms.

        If you type and wait for the letter, I could see that being annoying. My brain works more in waves, my hands type a block and it's there on the screen. I've never once thought of character latency, but maybe that's my HPB roots.

      • bigstrat2003 14 days ago
        Honestly I don't think that the problem with VSCode is speed, even. It's bloat. It uses gobs of RAM just to open up a few text files. I compared it to Sublime Text a while back and it was something like 500 MB (for Sublime) to 1-1.5 GB (VSCode). That's not acceptable in my view.
      • goosejuice 14 days ago
    • dijit 14 days ago
      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.

    • danielvaughn 14 days ago
      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.
    • yoyohello13 14 days ago
      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.

      • whalesalad 14 days ago
        but vscode is open source: https://github.com/microsoft/vscode

        and there are third-party builds from the community that disable things like telemetry: https://vscodium.com/

        • screcth 14 days ago
          The problem is that many parts of the ecosystem require that you use the official MS build.

          You can't connect to the Marketplace and some extensions outright can't be used with a custom build.

          • vorticalbox 14 days ago
            You can however down the extension from the website and install it from the terminal.

            codium --install-extension {path to .vsix}

            • KETHERCORTEX 14 days ago
              You are able to do so, but is it allowed by the website's terms of service? It may say that you are granted the license to extensions only with Microsoft builds of vscode.

              Microsoft isn't a stranger to distribution restrictions and software usage limitations. I remember uploading Visual C# Express 2010 (freely downloaded from Microsoft's website, without license keys) to a local file sharing website to ease the downloading for my local study group and got a letter from Microsoft's lawyer to take it down.

              After that our study group transitioned to Mono with Monodevelop.

              • Arnavion 13 days ago
                An actual example is that the Python LSP extension on the offical marketplace has some "DRM" that makes it pop up a fatal "You can't use this extension except with the real VSCode" error message. People have been playing whack-a-mole with it by editing the obfuscated JS to remove that check, or by using an older version from before they added the check. https://github.com/VSCodium/vscodium/discussions/1641
              • whalesalad 14 days ago
                Terms of service? Who cares.
          • maccard 14 days ago
            If you're idealogically opposed to Microsoft's editor, that doesn't seem to be a problem to me.
        • yoyohello13 14 days ago
          Sorry, I should have been more specific and said FOSS. VSCode is still encumbered by the weight of a mega corp. It's like saying Chrome is open source. Sure it is, but it still exists to serve the corporation that owns it.
          • TiredOfLife 14 days ago
            It's MIT licensed. So it's more FOSS than FOSS
            • correct-horse 14 days ago
              It's free software in letter, but not in spirit. True free software doesn't lock out non-official builds for zero technical reasons.
              • bigstrat2003 14 days ago
                The software is free, the extension site is not. I agree that's a shitty practice by MS, but it doesn't somehow make VSCode not free software.
              • fragmede 14 days ago
                what about vscodium? for that reason, what was iceweasel?
                • janice1999 14 days ago
                  vscodium and VSCode forks are legally prevented from using the normal VSCode extension site. They have their own: https://open-vsx.org/

                  As far as I know Chrome forks are not blocked from using extensions from the Chrome Web Store.

                • nicce 14 days ago
                  There is some sort of vendor lock-in VSCode. It at least used to be extremely difficult to make GitHub Copilot to work with codium. There is something closed source in VSCode that makes the difference.

                  It was so difficult to maintain, that I ended up switching to VSCode. So the ”lock-in” worked.

            • o11c 14 days ago
              It isn't 1860 anymore, "the freedom to take freedom away" no longer counts.
              • hollerith 14 days ago
                Tortured analogy.
              • novagameco 14 days ago
                In what way is VSCode comparable to enslaving human beings?
                • tristan957 14 days ago
                  Having the freedom to take away freedom does not make a society more free.

                  MIT takes freedom away from end users at the expense of the developer's freedom.

                • shrimp_emoji 14 days ago
                  It uses indentured neural networks to write code for you. You're a neural network! You just have rights because you ain't digital (and way larger and possibly using quantum effects). Smh
        • 0cf8612b2e1e 14 days ago
          You mean except for all of the good plugins. Or the ability to use a custom plugin store. Last I read, the open builds struggled with removing all of the MS telemetry and some may still be leaking.
        • chx 14 days ago
      • kiitos 14 days ago
        I, too, prefer to cut off my nose to spite my face.
  • CapeTheory 14 days ago
    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.
    • jitl 14 days ago
      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.

      • VoxPelli 14 days ago
        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...

        • tjoff 13 days ago
          And you need to login using a Microsoft-account. Even if both computers are on the same LAN.

          That part leaves a terrible taste in my mouth. Also debugging in a collaborative session has been broken for years now for us.

    • lbhdc 14 days ago
      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.
      • goosejuice 14 days ago
        Indeed, Tuple is a better solution. That said, I think Zed is a great text editor.
    • lexoj 14 days ago
      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.
  • jchw 14 days ago
    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:


    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.

    • mikaylamaki 14 days ago
      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
      • jchw 14 days ago
        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.
    • brunoqc 14 days ago
      > It doesn't work at all on NixOS

      Doesn't it work with:

        zed-fhs = pkgs.buildFHSUserEnv {
          name = "zed";
          targetPkgs = pkgs:
            with pkgs; [
          runScript = "zed";
      Still not ideal though.
      • jchw 14 days ago
        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.
    • benfrain 14 days ago
      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
    • 1attice 14 days ago
      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.

      • winternewt 14 days ago
        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.
        • ajitid 14 days ago
          • winternewt 14 days ago
            Apparently yes. I tried installing xdg-desktop-portal-gtk at first, but that didn't work. xdg-desktop-portal-kde did.

            But now I get issues that are likely due to problems with downloading language server binaries and running them, as the parent comment indicated. When I open a Rust project it says "Language server rust-analyzer-2024-07-08 (id 1) status update: Failed to load workspaces."

            Also, it dumps core every time I quit. :)

          • jchw 14 days ago
            This is almost definitely the problem they're facing although I think that description is a little bit odd. It's missing the operative word: "portals". It's the XDG desktop portals service that is involved here. What you need to ensure is that you have a desktop portal provider set up that provides org.freedesktop.impl.portal.FileChooser. What's kind of neat about the way xdg-desktop-portals is architected, you can pick and choose different implementations for different services. This is especially useful outside of desktop environments where you might need to use e.g. the wlr provider for screenshots and screen capture, but you still want e.g. KDE file dialogs.

            It's unfortunate that the documentation for XDG desktop portals (and generally, setting up a complete desktop setup when using compositors like labwc or Sway) is relatively poorly documented. I have my feelings about the pervasiveness of DBus services everywhere but overall I like desktop portals.

        • dindresto 14 days ago
          NixOS 24.05 contains an older version of zed, as feature updates are generally not backported to stable NixOS releases. Try running the package from nixos-unstable instead.
          • winternewt 14 days ago
            Well that got rid of the core dump each time I quit, and it fixed the language server issues. So together with the portals configuration it seems to be working as well as it can.
            • 1attice 14 days ago
              [OP] yeah I'm using nixos-unstable too. I should have mentioned that
  • llagerlof 14 days ago
    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.

    • mintplant 14 days ago
      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

      • rustyminnow 14 days ago
        What are your undo settings? I set undofile and undodir, but not sure if it's unlimited.

        One issue I have is if nvim is closed and the file is touched by some outside process (say git pull) it clobbers the history. Do you know if there's a fix to that?

    • sa-code 14 days ago
      Sublime works this way and I do appreciate it
      • mhuffman 14 days ago
        Just an fyi, I have shot myself in the foot with Sublime's version of this. I became dependent on using unnamed/unsaved documents for quick notes, then at some interval I would clean up. And because Sublime would remember, I could rest safe that they would be there even if closed and reopened until I cleaned them up myself. Well, I also got so hooked on Sublime, I set it as my default system text editor. Then, (more than once), I would click a downloaded text file or something that would open in another window. Then after browsing or something I would be back in my original Sublime window. Close it for the day and as I was closing other windows realize there is another Sublime window still open with that document that I read early ... and all my other temp notes were gone! If you are good at grepping you can still find the files cached on your system with a little work, but something to watch out for. Or just get used to saving files somewhere.
        • eviks 13 days ago
          Yes, never trust features like these for anything important, we're just not in that era of computing where losing user state is a cardinal sin. Had the same issue.

          Though you could use a shortcut to quit the editor instead of closing windows

      • shitlord 14 days ago
        I have a tab in Sublime Text for my todo list, which I created several years ago and never bothered to save. It's a great feature for indecisive procrastinators.
    • misternugget 14 days ago
      Working on it!
    • rbanffy 14 days ago
      I wouldn’t mind auto saving and allowing me to undo changes from the previous session.
    • ziml77 14 days ago
      Even Windows Notepad supports hot-exit now.
    • zelphirkalt 14 days ago
      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.
      • emporas 14 days ago
        Emacs definitely does this. I have saved many files from power outages. M-x recover-file, but the user has to recover the file right away when he opens it again or else a new auto-save will overwrite the old one. I think that's the case.
      • jhoechtl 14 days ago
        While I love Emacs it's not like this. Scratch buffer? C-c C-x and all is gone without any warning.
        • worthless-trash 14 days ago
          Scratch is (I think) intended for use for executing 'this session' elisp code as the buffer is set to lisp interfactive mode, not intended for where you store your scratch text.

          Other buffers behave differently, maybe scratch isn't useful for a large number of emacs users, however scratch is working as designed.

    • stavros 14 days ago
      Is this if you close the entire editor? If you just close the file, do the changes remain next time you open it?
      • 369548684892826 14 days ago
        Just if you close the entire editor. Editors with this feature, if you close the file it will ask if you want to save changes, click no and the changes are lost.
        • stavros 14 days ago
          That's very good UX, I really like that. I wonder why it's not more widespread.
          • vunderba 14 days ago
            It's more common than you would expect in IDEs: VS code, sublime, notepad++, though I would love to see it adapted to other types of software such as audio, graphic editors, etc.
    • TiredOfLife 14 days ago
      Jetbrains ides even have something like a shadow git.
    • TremendousJudge 14 days ago
      Atom worked that way as well
  • dinozarw 13 days ago
    > 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...

    • admax88qqq 13 days ago
      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.

      • hyperbrainer 13 days ago
        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.
        • oneshtein 13 days ago
          It's time consuming only if author interested in good UX. If author wants to use their users as alpha-testers, then he can spent a minimal amount of time on packaging.
      • blub 13 days ago
        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.
        • oneshtein 13 days ago
          Linux distributions are doing this for 30 years.
    • paride5745 13 days ago

      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

      • slim 13 days ago
        but then I will need curl | sh to install snap :(
    • fortyseven 13 days ago
      Versus what? Everything you install involves trust at some point.
      • oneshtein 13 days ago
        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.
      • lyu07282 13 days ago
        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.
        • pilif 13 days ago
          Of the three distros I know to more detailed extents, Debian, Arch and RedHat, none of those make it easy to install and keep updated a third-party package through the built-in package manager.

          In all cases, signatures and repositories need to be configured, often requiring both root access and usage of the CLI and in all cases much harder than running an installer script (which might be doing exactly these steps).

          To achieve easy means of installing using distro package managers means including the application in the distro itself, but now it's beholden to the distro's software update policies and thus stuck on that specific version for years or even decades.

          That is not what a v0.something of an end-user centric desktop application wants for themselves.

      • kaba0 13 days ago
        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

        • pilif 13 days ago
          True, but where's the difference between downloading a binary and executing it vs. downloading a script and executing that which will then download a binary and execute it?

          In both cases, you trust the publisher and in both cases the publisher gets equal access to your machine.

          Oh - you mean you're downloading the source code, then audit it, then compile it and only then you run it?

          That's super great. That has saved you from the xz backdoor and all other supply chain attacks and will be of great help to you in the future. Let's hope no backdoor ever slips past your code review.

          • ramon156 13 days ago
            The difference is that i prefer flatpak (:
  • apatheticonion 14 days ago
    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


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


    • iamnbutler 14 days ago
      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.

      • apatheticonion 13 days ago
        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
    • jitl 14 days ago
      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.
      • iamnbutler 14 days ago
        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.

  • dcchambers 14 days ago
    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.

    • omneity 14 days ago
      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.
      • omnimus 14 days ago
        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.
      • metaltyphoon 14 days ago
        Same. It also mean when toggling the bar what moves is the bar not the code.
      • ku1ik 14 days ago
        Same here! Also, when it’s on the right toggling it doesn’t move the code panes left and right.
    • mikojan 14 days ago
      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",
  • vanarok 13 days ago
    Tried installing on arch Linux, it wouldn't start and I gave up on the idea
  • rckt 13 days ago
    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.

  • tomerbd 13 days ago
    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.
    • ramon156 13 days ago
      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
  • brokegrammer 14 days ago
    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?

    • saratogacx 14 days ago
      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.


      • neurobashing 14 days ago
        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.
        • mikebelanger 14 days ago
          Maybe there will be forks that remove all the collaboration stuff. I can't imagine it'd be that hard.
      • dathinab 14 days ago
        i.e. very similar to how other editors approach it

        e.g. vscode uses network features to make people use the non fully open source version instead of codium (and it's otherwise subventioned by MS to reach the part of the editor/programmer market visual studio can't reach but IMHO if it wouldn't be that is also how they would bring in the money)

    • the_gipsy 14 days ago
      be cool and gain traction, to later extract profits?
  • secondary_op 14 days ago
    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.
    • llmblockchain 14 days ago
      I only use editors written in C, as God intended.
      • daghamm 14 days ago
        Correction: written in C plus some LISP, as God intended.
        • thrwymsss 13 days ago
          Heretic! Slander!

          The prophet wrote the divine language Perl! LISP is the language of the devil!

      • tarruda 14 days ago
        This might seem funny until you read Ken Thompson's "trusting trust" paper and realize that bootstrapping Rust is a so overwhelming task that someone implemented a Rust compiler in C++ for this purpose: https://github.com/dtolnay/bootstrap

        I mean, who knows what kind of malware is transparently being injected in all Rust programs out there.

        • umanwizard 14 days ago
          Nobody wrote a C++ compiler for this purpose; they wrote a Rust compiler (mrustc) in C++.

          > I mean, who knows what kind of malware is transparently being injected in all Rust programs out there.

          FWIW, using Guix it is very straightforward to build the rust toolchain fully bootstrapped starting from mrustc and gcc.

          • tarruda 14 days ago
            > Nobody wrote a C++ compiler for this purpose; they wrote a Rust compiler (mrustc) in C++.

            Edited the comment

    • Gormo 14 days ago
      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/
    • colinsane 14 days ago
      `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?
  • anotherevan 14 days ago
    Amused that it is already an official package for Arch Linux.


  • sriram_malhar 13 days ago
    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.

  • sauercrowd 14 days ago
    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?

    • taosx 14 days ago
      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.
    • mikaylamaki 14 days ago
      As a Zed developer, our killer feature is the parallel programming that our software enables. It's like pairing without the terrible parts.
  • foresto 14 days ago
    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.
    • jchw 14 days ago
      GPUI is very cool, they have blogged about it before.


      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.


      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 :(

      • iamnbutler 14 days ago
        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.

      • foresto 14 days ago
        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.
    • jenadine 14 days ago
      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.
      • foresto 14 days ago
        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.
  • 3836293648 14 days ago
    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.
  • poetril 14 days ago
    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.
  • WuxiFingerHold 14 days ago
    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.

  • dario_od 14 days ago
    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

    • abhinavk 14 days ago
      I have been using it on Windows (native) after building it from source. Just for quick editing. It hasn’t crashed on me yet.
    • shanselman 14 days ago
      same. :(
    • daghamm 14 days ago
      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.

      • bozey07 14 days ago
        That seems a bit rude. You get the QA you paid for - zero.

        And nevertheless, whenever Windows software doesn't work in Wine, you shouldn't think "Wow, how did you fuck that up?". They never promised it'd work in WSL.

        • daghamm 14 days ago
          I disagree.

          They are on front page of HN with "zed on Linux is here". We got to have some standards, don't you think?

          • Carrok 14 days ago
            One could easily reply an equally snarky answer of “Use a real OS, not MSFT spyware. We got to have some standards, don’t you think?”
          • jorams 13 days ago
            It's pretty self-evident that Linux support can't be expected to mean Windows support. If something is broken in the Windows simulation of a Linux GUI stack you should be complaining to Microsoft, not to the developers of a program that works fine in a normal environment.
          • umanwizard 14 days ago
            WSL is a pretty niche version of "Linux". I would guess that close to 0% of what makes it to the front page of HN had a QA team that explicitly tested it on WSL.
      • kelnos 14 days ago
        Maybe they didn't do any on Windows, because this is for Linux, not Windows. WSL is still not Linux. They do appear to have Windows build instructions, though[0]?

        [0] https://zed.dev/docs/development/windows

      • oblio 14 days ago
        > Of course, zed has always felt like an osx first project with linux/windows being second class citizen.

        Unless I'm missing something, it doesn't even run on Windows...


        • tills13 14 days ago
          You can build it yourself for Windows iirc
      • crabbone 14 days ago
        I've not heard of QA in open-source projects... unless it's something peddled by a big corp (eg. Chrome, Go, VSCode etc.)

        You are lucky if there's some automated unit testing, but that's as far as these things go. Programmers don't like, don't know and don't want to know how to QA. Also, they generally look at QA with contempt... so, unless forced to, they won't do it.

  • vondur 14 days ago
    Surprised they didn't make it a FlatPak. Probably would anger some, but it would work with most Linux distributions.
  • lbhdc 14 days ago
    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?

    • wolfadex 14 days ago
      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.
      • unshavedyak 14 days ago
        Wait, Zed is a modal editor? All i've seen is that it has vim mode, which most editors have and i generally find it insufficient.

        Granted these days i still prefer Kakoune style modal editing (i use Helix, currently), so not sure i could move back to Vim style anyway. Nonetheless if Zed has real, first class support i'd be interested... but a second class compat layer is not sufficient in my view.

        How's it work for you?

        edit: https://news.ycombinator.com/item?id=40929169 this post suggests it's lacking. Which is always the problem to me with emulation :/

        • satvikpendem 14 days ago
          It's not a modal editor, it just has a modal (vim) emulation mode.
      • thesuperbigfrog 14 days ago
        >> I'm also very much enjoying the modal editing, which VSCode lacks.

        The VSCode Vim plugin works great:


        • wolfadex 14 days ago
          When I specified the modal editing I was referring to how the workspace search in Zed brings up each result in an editable "window" allowing me to make edits across my whole project from 1 tab. VSCode's workspace search feels much more limited in comparison.
          • thesuperbigfrog 14 days ago
            That sounds like an interesting feature. Could you provide a link that gives more information about it? I am not finding it in the docs.
            • mikaylamaki 14 days ago
              We call them 'multibuffers' :D


            • wolfadex 14 days ago
              I'm not seeing it in the docs, maybe I should write up a little something on my editing experience!

              Also to correct my self, I think I mistakenly said `modal` when I should have said `buffer` earlier.

              So searching across the project brings up your results in multiple buffers, each about 5 lines (expandable to more) and you can do all of your normal editing within each/all of the buffers.

              If I happen to write something up, I'll try and remember to share it in this thread.

              • thesuperbigfrog 14 days ago
                That is a unique feature. Most editors I have used use the search as a way to jump to buffer locations of the matches.
      • Zambyte 14 days ago
        FWIW Emacs also fits that bill.
        • wolfadex 14 days ago
          It does, though I found learning and setting it up to be more complicated. My preferred editor is one that's very simple to setup and use (e.g. Sublime, VSCode, Zed, nano). Emacs is cool, and maybe someday I'll get around to using it but so far it hasn't met my needs.
          • Zambyte 14 days ago
            Fair enough, I have personally spent a decent chunk of time configuring my Emacs setup (though it has mostly stabilized at this point). You may be interested in checking out Doom Emacs[0] if you want to take a stab at it in the future. It sounds like it would be an out of the box experience closer to what you would want.

            [0] https://github.com/doomemacs/doomemacs

    • nequo 14 days ago
      Besides speed, the other killer feature that Zed focuses on is collaborative editing:


    • pcthrowaway 14 days ago
      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

    • barrell 14 days ago
      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

    • choilive 14 days ago
      Its killer feature seems to be speed. Otherwise I dont see much of a reason to use it over VS Code.
      • gavmor 14 days ago
        Have you had much success with VS Code's multiplayer extensions? I've found them buggy to the point of useless, but maybe things have improved. Zed, on the otherhand, is developed by people who understand pair programming, which is my priority.
        • choilive 14 days ago
          No not much experience there since multiplayer editing has never really been a part of my personal workflow (mostly a lot of screensharing), but I can definitely see that being useful for people that use it regularly.
        • cmiles74 14 days ago
          Not the OP but I tried hard, looking for an easy pair programming solution. Worked decently a couple of times and inexplicably failed most of the time.
          • gavmor 14 days ago
            This is why I'm excited to try Zed. I regularly "pair" via Pop, but keybindings and lag make it hard to switch seats, so we basically decide at the beginning of the session who is going to hog the keyboard, and that's a crippling dynamic.
      • griftrejection 14 days ago
    • threatofrain 14 days ago
      No killer features, just nice ergonomics and speed out of the box. I use it as my Vim replacement.
      • nickorlow 14 days ago
        What motivated you to switch to it from vim?
      • boomskats 14 days ago
        Do you find it to be faster than vim/neovim?
        • vehemenz 14 days ago
          The Vim emulation is pretty far behind JetBrains, VSCode, and Sublime Text. I wouldn't compare it to Vim as a replacement at this point.
      • renewiltord 14 days ago
        Do you use it for Rust? Does it do "Show usages" well when the usages are through a macro?
    • drcongo 14 days ago
      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.

  • xylon 13 days ago
    No syntax highlighting for Clojure :'(

    No Emacs keybindings :'(

  • keb_ 14 days ago
    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!
  • purpleidea 13 days ago
    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.

  • levkk 14 days ago
    > 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.

    • skavi 14 days ago
      I believe they mean “physical” as in not implementing in software. So integrated GPUs are perfectly fine as well.
      • PhilipRoman 14 days ago
        IMO for a graphical program that's fine, but in general I really hate hard requirements for a GPU which I've seen in the wild multiple times. Just simulate the darn thing in software, I don't care if it takes 10x longer, I have all the time in the world.
        • kvark 14 days ago
          I don’t think there is a hard requirement in the code. It may work well on lavapipe (software Vulkan).
      • colinsane 14 days ago
        yes. it's working fine for me on 9 y/o integrated intel graphics.

        but it's kind of still a weird statement to make. i thought it was generally the OS's job to supply the vulkan layer, and that mesa -- which just about every linux OS will be using -- provides pretty robust software implementations of those things as fallback. what would cause them to require a "physical" anything?

  • alberth 14 days ago
    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

  • ceving 13 days ago
    Is there an Emacs keymap?
  • marcodiego 14 days ago
    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?
  • satvikpendem 14 days ago
    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.
  • 1bent 14 days ago

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

    • andrewl-hn 14 days ago
      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.

  • zikani_03 14 days ago
    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.

  • Thaxll 14 days ago
    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?

  • insane_dreamer 14 days ago
    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.
  • trostaft 14 days ago
    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.
    • kvark 14 days ago
      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.
  • gullevek 13 days ago
    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

  • riiii 14 days ago
    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.

  • flurly 14 days ago
    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.
  • 1oooqooq 14 days ago
    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.

    • sphars 14 days ago
      Unfortunately, they've switched out their Zed fonts for IBM Plex: https://github.com/zed-industries/zed/pull/13596
      • 1oooqooq 14 days ago
        lol. Of course they would change the one thing i thought was great. and they bumped ligatures to eleven on top of the change. sigh.

        future generations will look at our silly use of ligatures like we look at comic sans.

  • captn3m0 14 days ago
    Pretty nice to see aarch64 packages for so many distros. Sublime packages are x64 only, so this will go well with my Asahi setup
  • kristianp 14 days ago
    Zed's dead, baby.
  • calebjosue 13 days ago
    I would love to give it a try but I am using WSL2 at the time being, so maybe in the future.
  • sys_64738 14 days ago
    I never got these new type editors compared to EMacs.
  • burnte 14 days ago
    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.
    • joeldo 14 days ago
      You can review the bash script first. Regardless, they provide a few different installation options https://zed.dev/docs/linux
    • Buttons840 14 days ago
      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?

    • noisy_boy 14 days ago
      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.
  • lexoj 14 days ago
    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.
    • bogwog 14 days ago
      > 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?

      • lexoj 13 days ago
        Lazyvim or pycharm search functionality. Even vscode is better in that regard, though it kinda requires using mouse. (I love sublime btw, except for searching)
    • iamnbutler 14 days ago
      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.

      • lexoj 13 days ago
        When searching I get almost entire file snippets with the search content and scrolling through them would take forever. In comparison see Lazyvim or IntelliJ products search UI, (even vscode is OK, though it requires mouse a bit), you should be able to scroll through found lines, and while you do that you can see the surrounding context of the selected line.
      • lsllc 13 days ago
        nvim+lazyvim+telescope (which uses ripgrep and/or fzf). Fantastic, that's the gold standard for finding files, grepping, looking for references to variables etc. Love it.
  • w-m 14 days ago
    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).

  • thesurlydev 14 days ago
    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.

  • unshavedyak 14 days ago
    I'll have to figure out how to get it on NixOS. Always the challenge with Nix lol.
  • natemcintosh 14 days ago
    Anyone else get ~60-70% CPU usage when moving the mouse around? And no GPU usage.
  • croemer 14 days ago
    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.
  • cassepipe 14 days ago
    vim mode in the json settings:

    "vim_mode": true,

  • fire_lake 14 days ago
    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.

    • mirpa 14 days ago
      I think you need extension which will integrate language server. I installed extension for Haskell and it works out of the box.
  • DarkCrusader2 14 days ago
    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
            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.
    • mikojan 14 days ago
      > 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.


    • kelnos 14 days ago
      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.

    • jarule 14 days ago
      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.
  • ElectronBadger 14 days ago
    I couldn't find anything resembling "Send code to REPL", so no Zed for me.
  • llagerlof 14 days ago
    How to install/activate extensions? I saw that exists a directory called "extensions" in the repository.
    • simlevesque 14 days ago
      There's an extension ui in the app.

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

  • kokada 14 days ago
    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

    • oynqr 14 days ago
      Can you even do GPU acceleration without dynamic libraries on Linux?
      • kokada 14 days ago
        This is a good question. It is not like the current `zed` binary is linked to anything that is needed for 3D rendering:

            $ ldd zed.app/bin/zed
                linux-vdso.so.1 (0x00007ffed63f6000)
                libgcc_s.so.1 => /nix/store/bihw7p4zdqwyxmnc8h67c06lnjkvdan8-xgcc-13.3.0-libgcc/lib/libgcc_s.so.1 (0x00007fb5def3c000)
                libpthread.so.0 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libpthread.so.0 (0x00007fb5def37000)
                libdl.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libdl.so.2 (0x00007fb5def32000)
                libc.so.6 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib/libc.so.6 (0x00007fb5ded3b000)
                /lib64/ld-linux-x86-64.so.2 => /nix/store/m71p7f0nymb19yn1dascklyya2i96jfw-glibc-2.39-52/lib64/ld-linux-x86-64.so.2 (0x00007fb5df05d000)
        However it may well be that this is dlopen during runtime, and for it to work correctly you need to use the same libc as the one in the system.
  • 29athrowaway 13 days ago
    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.

  • TaylorAlexander 14 days ago
    Here I am still using Atom in 2024.
  • perryizgr8 14 days ago
    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.

  • rareitem 14 days ago
    FYI, to launch Zed, run `'~/.local/bin/zed'`
    • whalesalad 14 days ago
      If .local/bin is in your PATH you would be able to fire it up with just `zed`
  • rwdf 14 days ago
    Anyone got this working in WSL? Using WSLg perhaps?
  • insane_dreamer 14 days ago
    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).
    • simonw 14 days ago
      Instead it's a creation of the team who built Atom, Tree-sitter and Electron. Pretty solid resume!
    • romwell 14 days ago
      I can vouch for "Learn C The Hard Way" as well :)
  • TiredOfLife 14 days ago
    On Steam Deck it just exits, or rather it and the old node.js it bundles stays in memory. But no UI.
  • pmarreck 14 days ago
    Any word on whether this can be installed from the nixos repo?
  • dabber21 14 days ago
    neat! just installed it in podman, so far so good
  • refulgentis 14 days ago
    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.

    • mikaylamaki 14 days ago
      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
  • jak2k 14 days ago
    Now they just need a flatpak…
  • WhereIsTheTruth 14 days ago
    I gave it a fair try


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


    - 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

    • nilslice 14 days ago
      > - 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!

    • kelnos 14 days ago
      > 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.

      • WhereIsTheTruth 14 days ago
        It doesn't really matter, it's open source with a growing community already, so it can only keep going if the company dies
  • hi_dang_ 14 days ago
    Zed Shaw started a company called Zed Industries?
    • ebrescia 14 days ago
      LOL no. The Zed founders are the guys who built Atom and Electron (and Treesitter): Nathan Sobo, Max Brunsfeld and Antonio Scandurra.
  • Brechreiz 14 days ago
    Is this better than VS Code?
  • AndyKelley 14 days ago
    > 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.

    • NormenKD 14 days ago
      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...

      • AndyKelley 14 days ago
        I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact with the graphics driver, or the ability to require permissions from the user to do certain things.

        I do think that my work contributes to help with this use case. Looking elsewhere on this thread I see that they are having problems fetching and running a nodejs binary successfully. Fortunately, nodejs is a piece of software that can be built and distributed statically. I have not packaged up this one in such a manner but I have done a proof of concept with CPython: https://github.com/allyourcodebase/cpython

        That said, if they want to allow users to install Zed through a system package manager, they will need to cooperate with the system and rely on system nodejs instead of trying to fetch it at runtime. Fetching and running software at runtime is fundamentally incompatible with the core mission of Linux distributions (curation, vetting, and compatibility patching of all software that is to be run on the system).

        • logicprog 14 days ago
          > I sympathize with the situation that Zed developers are in. They are thinking of the user experience first and foremost, and when trying to distribute on Linux, faced with an overgrown, chaotic landscape that utterly fails to provide the basic needs of application developers, such as the ability to distribute a binary that has no dependencies on any one particular distribution and can open a window and interact with the graphics driver, or the ability to require permissions from the user to do certain things.

          But Linux does provide a very simple and easy way to do this — Flatpaks. They're completely distro-independent, allow you to package up and distribute exactly the dependencies and environment your program needs to run with no distro maintainers fucking with it, allow you to request permission to talk to the graphics drivers and anything else you need, and you can build it and distribute it directly yourself without having to go through a million middlemen. It's pretty widely used and popular, and has made the silent majority of Linux users' lives much better, although there's a minority of grognards that complain endlessly about increased disk usage.

          • kelnos 14 days ago
            Maybe I'm just old-fashioned, but I don't like Flatpak (or Snap or AppImage). They still don't seem to have solved all the desktop integration issues. I do not like running apps that bundle their own dependencies, because I don't trust the app developers to be on top of security issues. I trust Debian maintainers (despite mistakes in the past) to keep my system's base libraries up to date and patched. Why would I trust some random developers of some random app to do the same?
          • doublepg23 14 days ago
            The best part of Linux’s single universal packaging system is there’s three of them.
            • logicprog 14 days ago
              Sure, but all of them are actually universal, so it doesn't matter which one you choose, unlike their being multiple regular package formats.
              • doublepg23 14 days ago
                It seems to me the most neutral one is AppImage. Flatpak being the favorite of “not-Ubuntu” people and Snap being only preferred by Ubuntu…but still having a huge user base due to their enormous market share.
                • tjoff 14 days ago
                  People don't prefer snap, they are forced into it.
        • aidenn0 14 days ago
          I have a shell script that will recursively copy and rewrite the rpaths of every shared-object that all elf files in a sub-directory reference to bundle it up. It obviously can't handle dlopen(), and ld-linux cannot be specified as a relative-path to the executable, but it works for many binaries.

          Of course that has the problem that vendoring always has; you have pinned every dependency, which is great for making the software work, but you miss out on security updates.

    • the_duke 14 days ago
      > 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.

      • correct-horse 14 days ago
        Almost 70% of the male population in my country smokes. Should I take up smoking because everybody else does it?
      • Palomides 14 days ago
        >I don't want to end up with 15 different third party apt repositories

        I would love to add 15 different third party apt repositories, I wish more projects used them, you're running whatever binary they give you anyway

        I guess this is just another example of how hard it is to please all linux users!

        • the_duke 14 days ago
          Running a binary in userspace is quite different from giving a third party unconstrained root access to your system though.

          To be fair though, with the lack of security and isolation on Linux a malicious binary can already do a huge amount of damage.

    • janalsncm 14 days ago
      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

      • deadbunny 14 days ago
        > Pipe to sh is simple, transparent

        Not so transparent[1]. Packages from a package repo are signed, usually with keys not stored on the same server so if someone nefarious breached a server they can easily replace a bash script, they can't re-sign and replace a package.

        Sure it's safe if you download the script then review it then install it, but hey, you reviewed it last time, it's probably unchanged, what's the harm of piping it directly to bash next time you need to get set


    • logicprog 14 days ago
      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.
      • figomore 14 days ago
        There is already some support to flatpak, but it's not distributed on flathub yet. You have to build by yourself https://github.com/zed-industries/zed/blob/main/docs/src/dev...
        • logicprog 14 days ago
          Were they not aware of `flatpak build-bundle`? They could have just built it once and ran that command on the result and then put that on the archives of their repository and been done with it. It's not like a regular package build where there are different system conditions to keep an eye on. It would work no matter what.
      • insane_dreamer 14 days ago
        Because then you have a dozen other people who say "why didn't they just make a ___"
        • logicprog 14 days ago
          But that's literally already true, and at least with Flatpak they'd only need to make a single package to support all distributions and system configurations, whereas what they're already doing is supporting 15 different packaging systems and distributing a fragile install script that more people will have problems with. So this objection makes literally zero sense.
      • kelnos 14 days ago
        Flatpak is just yet another form of fragmentation though.
        • logicprog 14 days ago
          It isn't, though? Unlike the other packaging formats, it actually works across distros and independent of system setups, so if you choose it, you aren't limited to a specific distro or group of distros like the other packaging formats. Therefore, if you choose it, you don't have to deal with any further fragmentation of the Linux desktop. So yes, while you are "technically" correct, which is the best kind of correct, you're practically speaking quite wrong. It may technically be just another packaging format, but unlike the other ones, it completely removes the need to worry about fragmentation entirely if you adopt it, whereas if you use a bass script, various system configurations will conflict with it, and if you use a discropackage, then you'll keep helping to make new packages for various discros.
    • maxbrunsfeld 14 days ago
      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.
    • agilob 14 days ago
      >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

    • pkage 14 days ago
      This is a fairly common way to install tools on Linux. Tailscale, Homebrew, Pi-hole and many others offer installations in this way.
      • AndyKelley 14 days ago
        The same criticisms apply to Tailscale, Homebrew, Pi-hole and all those others.
        • usr942568903890 14 days ago
          > The same criticisms apply to Tailscale

          No it doesn't.

          Tailscale's shell script is entirely optional and installs a distro/package manager specific package. It also doesn't mess with your PATH variable.

          They maintain packages for most popular distros as you can see here https://pkgs.tailscale.com/stable/.

          The sibling comments are just spreading misinformation because those people were too lazy to actually look anything up.

      • nicce 14 days ago
        While it is fairly common way, it does not mean that it is good way.
      • lagniappe 14 days ago
        Not an argument.
    • hypeatei 14 days ago
      > you can't distribute with a shell script for installation

      Why not? It worked for me.

      • drdaeman 14 days ago
        There are two schools of thought. One strives for correctness, even if that requires extra effort. Another is "anything goes as long as it somehow kind of works more than it doesn't."

        (Actually it's most probably a spectrum rather than a binary division, but I'm no philosopher or sociologist, so for example's sake I'll operate with this simplified model here.)

        The world en masse is generally preferring the latter (picking the easiest solutions, no matter how shitty they are - that's how we ended up with what we have today*), but among the engineers there are a significant number of people who believe that's how things should be.

        There are numerous issues with copying and pasting `curl | bash` invocations from random webpages: all sorts of potential security issues, the installed software (if it works) could be installed in a way different from how your OS/distribution does things (or from your personal preferences), leading to all sorts of future issues, etc etc. Someone probably has a good write-up on this already. But - yeah - on the other hand, it works for number of people.


        *) And, of course, the opinions if what we have today is "good progress" or "unbearable crap" also vary.

        • correct-horse 14 days ago
          | among the engineers there are a significant number of people who believe that's how things should be

          There are close to zero people who tend to think like that among actual engineers. That's why we have reliable transportation and bridges and skyscrapers that work for (soon to be) centuries. On the other hand, we have lots of them among self-professed "engineers" who have changed many monikers over the past couple of decades and will probably call themselves "gods" in a few more years down the line.

          • drdaeman 14 days ago
            > There are close to zero people who tend to think like that among actual engineers.

            Oops. My apologies - I meant exactly that, that a significant number of engineers believe in correctness and sound approaches, but I had a brain fart writing that comment. It should've been "believe in the former".

            No idea about how many non-software engineers take various shortcuts, though. But I think there's a non-negligible number of electronics engineers who do so - I'm not an expert in that field, but it's not unheard of skipping coupling capacitors or using a resistor divider instead of a voltage regulator to cut down the costs (because that still works... until it doesn't, of course).

            • kelnos 14 days ago
              Don't apologize; GP is being a pedant in order to pick a fight. The "real" definition of "engineer" doesn't matter; your post makes just as much sense if you'd instead used "software developers".
              • correct-horse 14 days ago
                It might be a cheap word in the US, the precise definition matters in many countries.
          • kelnos 14 days ago
            Can we please instead interpret people's comments in a charitable manner, as we can reasonably assume they were intended, not in the manner that allows us to pick pedantic fights with them?
        • RamRodification 14 days ago
          >There are two schools of thought. One strives for correctness, even if that requires extra effort. Another is "anything goes as long as it somehow kind of works more than it doesn't."


          The world en masse is generally preferring the latter (picking the easiest solutions, no matter how shitty they are - that's how we ended up with what we have today), but among the engineers there are a significant number of people who believe that's how things should be.*

          I often have trouble articulating this at work. I will steal this and use something like it when advocating for correctness as opposed to shitty short sighted solutions. Thanks

        • TiredOfLife 14 days ago
    • igorguerrero 14 days ago
      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.
      • nmstoker 14 days ago
        I agree they probably don't have bad intentions. But other options still seen better than the one liner.

        Even just as a two liner leaves people a copy of what they ran if something goes awry.

    • odo1242 14 days ago
      • LocalGauge 14 days ago
        This also includes the link to the tar files, so, you dont need to read the bash file to download tar file. The ones who are interested in this issue will spot this page, anyways. Maybe, they can make it more convenient for visitors to check this page.
    • usr942568903890 14 days ago
      > 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.

    • charles_f 14 days ago
      Honestly, I still take that as an improvement over having to recompile it
    • DEADMINCE 14 days ago
      > 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.

    • vanviegen 14 days ago
      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

      • AndyKelley 14 days ago
        My interest is not in using this text editor as a consumer, but in guiding software development culture in general, particularly when it comes to installation of Linux applications.

        Some talks I have given on this topic:



        So, I think "entitled" is the wrong insult. "arrogant" would be more accurate.

        • jayde2767 14 days ago
          "Opinionated" is more appropriate. Ignorance often accompanies arrogance. Opinion, to me, at least contains a degree of knowledge.
        • jarule 14 days ago
          You've dedicated your adult life to massaging ABIs and openly admit your "non-polished" solution is an idealistic holy grail, and yet you expect some text editor with a non-existent path to profitability to have hewn to your every private thought about Linux binary versatility, and that sir is bullshit.
  • whalesalad 14 days ago
    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

    • deciduously 14 days ago
      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.
      • pkage 14 days ago
        A lot of the backlash is around the tool downloading and running an arbitrary shell script which could contain anything, and overlooks the fact that that shell script then downloads an opaque binary which could also contain anything. If you're paranoid about security read the code and build it from source, otherwise curl | bash is trusting the authors just as much as any other method.
        • cogman10 14 days ago
          Probably the biggest problem with the `curl | sh` approach is it bypasses package maintainers. I agree it's really no different than if you compiled malicious code yourself (or pulled in a 3rd party bin repository). However, one of the functions of a package maintainer is finding/being notified of security issues.

          I'm thinking of the recent xz attack. Imagine how bad that would have been if xz was commonly installed via `curl | sh`.

          All this is to say `curl | sh` is probably fine if the org is reputable, however, you should be having second thoughts if this is a repo ran with a bus factor of 1.

          • jrpelkonen 14 days ago
            Yet the xz attack specifically targeted the packages and nothing else. And it worked, to a point. All I’m saying package maintainers are human and can’t detect everything.
        • Levitating 14 days ago
          I think for most it's not a security issue but a system maintainence one. Where does the script install what?
      • whalesalad 14 days ago
        Sure, but that convenience will come to bite you later. What happens when you want to update it?

        Their full install docs is like 5 lines of code so it is much preferred to do it that way. Every distribution is different. The ideal install here would be to add a unique apt repo for zed and then it becomes part of my normal update process. Updating a binary in a directory is not the end of the world... but I would prefer to know that upfront versus needing to hunt down where it was placed in order to do the updates.

        edit its 4 lines. seeing this is much preferred to parsing a bash script that is intended to support all distributions:

            wget https://zed.dev/api/releases/stable/latest/zed-linux-x86_64.tar.gz
            mkdir -p ~/.local
            tar -xvf zed-linux-x86_64.tar.gz -C ~/.local
            ln -sf ~/.local/bin/zed ~/.local/zed.app/bin/zed
      • jtriangle 14 days ago
        Suggesting that users install software outside of official repos isn't more convenient than using a repo and standard package management tools. As soon as there's an update, you'll learn exactly why that is the case.
    • porphyra 14 days ago
      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.
      • fao_ 14 days ago
        "reading a script" is actually a worse user experience on Linux than just using repositories or flatpak, though. It's pretty rude of software developers to put the onus on users to verify that they're not doing something outright malicious in terms of the installer.
        • shepherdjerred 14 days ago
          Are you not concerned with the software developers doing something outright malicious in the software itself?
          • BanazirGalbasi 14 days ago
            Most repositories have some sort of vetting process as far as I'm aware. In the case of Zed, because it's open-source, it can be examined more completely, although I don't think it's expected for every update to be heavily scrutinized.

            In the end, at some point you either have to inspect every line of code yourself or trust others to have done it for you. Package managers fall into the latter category.

        • janalsncm 14 days ago
          Instead of pasting it in terminal, I opened a new tab and read it. There’s maybe 200 lines, most of which aren’t relevant to my platform. Didn’t see anything unusual.

          I then proceeded to install tens of thousands of lines of code I didn’t read onto my machine.

          My point? People really seem to be bike shedding this install script bit. If I was a malicious actor I wouldn’t be hiding the bad parts in the install script.

          • whalesalad 14 days ago
            200 lines versus the actual install steps which is 1. wget the tarball, 2. extract the tarball to .local/bin, 3. done, or a few more steps to add the desktop file.
        • jfvinueza 14 days ago
          so you feel offended by this
    • bscphil 14 days ago
      It's already in the Arch Linux repositories, which is pretty cool: https://archlinux.org/packages/extra/x86_64/zed/
    • deepsun 14 days ago
      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.

      • whalesalad 14 days ago
        I am less concerned about it being malicious and more concerned about it doing something I do not want re: how the software is installed. Installing software from the distributions package manager is always preferred to doing something manual. When it comes time to update the app, I would prefer to not have to do that in a roundabout way.
      • abhinavk 14 days ago
        > Yep, it's the same as running random code with root permissions.

        It doesn't require root. You can read it before you run.

        • whalesalad 14 days ago
          "reading before you run" eliminates all convenience of the one liner. Their linux docs are way better because it shows you exactly how to do it on a per-distribution basis. when it comes time to update the software I would prefer to know how exactly it is installed so that I can update it correctly.
          • rad_gruchalski 14 days ago
            > when it comes time to update the software I would prefer to know how exactly it is installed so that I can update it correctly

            Then read the script you complain about.

            • deepsun 14 days ago
              I do it from time to time, but it's time-consuming (proper install scripts are long), defeating the whole goal of "one-line installer".

              With proper installers I never read it's install scripts.

            • whalesalad 14 days ago
              Three months from now I won't remember using the script to install it. And the contents of the script could completely change. This is not a helpful take.
              • fragmede 14 days ago
                I find organizing and saving files to disk is a great way to save things I won't remember. Maybe you could try that?
              • rad_gruchalski 14 days ago
                This is not a helpful take for you. The same method works fine for me over the last decade. Taking notes helps, having some helper scripts helps. If one’s invested in a technology, one finds a way to remember.
                • ericjmorey 14 days ago
                  You just described how the script is less convenient to meet the preferences of the commenter you replied to.

                  A debian package relieves them of the overhead you describe by having a few people do the work for anyone else that uses the package.

                  • rad_gruchalski 14 days ago
                    Debian packages are often old. Hence people found a way around.

                    > You just described how the script is less convenient to meet the preferences of the commenter you replied to.

                    Well… no. The person I reply to doesn’t say anything about preferences. They want to know how to update the software, the script is the best reference.

                    • shrimp_emoji 14 days ago
                      > Debian packages are often old.

                      What about AUR or Fedora packages? ;D

                • whalesalad 14 days ago
                  I am glad to hear you have room in your life to tend to idiosyncracies like this.
                  • rad_gruchalski 14 days ago
                    It’s part of the job. That’s one of the things I’m paid for.
                    • whalesalad 14 days ago
                      Paid to screw around with your editor installation? Or paid to edit code.
                      • rad_gruchalski 14 days ago
                        You know nothing about what I do. Keep editing code. You just grind on an infrastructure brought to you on a silver plate? Like an editor is the only thing we have fuck around with.

                        That script for the editor is code, too…

                        • whalesalad 14 days ago
                          I do it all brother. Infrastructure is the fun/easy part.
    • figomore 14 days ago
      There is some support to flatpak already, see https://github.com/zed-industries/zed/blob/main/docs/src/dev...
    • igorguerrero 14 days ago
      I hope it gets packaged, on NixOS there's a package already on stable and unstable.
    • abhinavk 14 days ago
      It's a basic download and extract script. Also creates directories as per XDG spec.
  • Arch-TK 14 days ago
    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.

    • Quot 14 days ago
      > 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.

      • Arch-TK 14 days ago
        I would damn hope you can configure/disable this. But why is it the default?

        And if the answer is "discoverability" then where is the default-on fuzzy find, default-on command palette, default-on context menu, etc?

        My point was not to claim Zed was bad because I had the ignorant misapprehension that it was incapable of being cleaner, my point was to ask why people desire such a cluttered workspace by default? Most people I see using these editors _don't_ disable all this clutter.

    • eviks 13 days ago
      > 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?

      • Arch-TK 13 days ago
        There's the relative number line etc, but I've never actually encountered a situation where I felt the need to make a jump to a line number on the screen and didn't do it with basic vim motions instead. Every time I'm going to a specific line number, it's because I'm following an error message that references a file and line number.
        • eviks 13 days ago
          Moving 15 lines up is a basic vim motion
    • aidenn0 14 days ago
      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).
      • Arch-TK 14 days ago
        I think lots of people are comfortable with smaller fonts, but I find myself genuinely straining my eyes too much and getting headaches if I go smaller than this, and I already wear glasses (although I should probably update my prescription).
        • aidenn0 14 days ago
          Oh, there's no "right answer" to font size, but the fact that my size would work on a 1200p screen (and many of my coworkers have significantly larger screens and younger eyes than I) could go towards explaining why the sidebar is on by default and the gutter is so huge.
    • dbalatero 14 days ago
      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.

    • brunoqc 14 days ago
      You can close the left dock (ctrl+b for me). The gutter is still huge, though.
  • Sesse__ 14 days ago
    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.
    • Gormo 14 days ago
      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.

    • maccard 14 days ago
      > 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.

    • tedunangst 14 days ago
      Apparently opening files is so complicated it requires an external helper program. https://zed.dev/docs/linux#opening-files-does-not-work
    • ajstarks 14 days ago
      Re: #2, use

      "buffer_font_weight": 600

      in the settings.json to fix the font rendering.

  • zoogeny 14 days ago
    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.

    • 1oooqooq 14 days ago
      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

      • zoogeny 14 days ago
        Komodo had some promise, in kind of the same way the original hype about Perl 6 had promise. For its time, it had features that were not widely available in other editors. However, I found it to be slow and buggy. And that was compared to Eclipse which was notoriously clunky. (Note: a quick look at the modern Komodo Editor, which appears to still be actively developed, looks much closer to a Visual Studio Code clone and is nothing like I recall the original)

        I recall it was pitched as a slightly lighter alternative to eclipse and intellij but initially geared towards Perl development (with plugin support for all languages). However, that kind of middle-ground wasn't popular at the time and devs mostly split into the full featured IDE camp or the stripped down editor camp.

        Editor hype cycles come and go. That's part of the reason I am so jaded when I see a new cycle start for a new editor.

  • assimpleaspossi 14 days ago
  • llmblockchain 14 days ago
    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.
  • lofaszvanitt 14 days ago