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 <i>at all</i> on NixOS, so it's just wasting its time and our bandwidth constantly downloading and trying to update binaries that will never run.<p>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:<p><a href="https://github.com/zed-industries/zed/issues/12589">https://github.com/zed-industries/zed/issues/12589</a><p>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.<p>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.
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.<p>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.<p>Notepad++ works that way, and it is an amazing feature.
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.
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<p>EDIT:<p>Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild<p><a href="https://github.com/zed-industries/zed/blob/main/crates/gpui/src/platform/mac/window.rs">https://github.com/zed-industries/zed/blob/main/crates/gpui/...</a>
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.<p>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.<p>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.
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.
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:<p>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.<p>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.<p>Eventually all the little inconveniences wore on me and I switched back to VSCode.<p>I will probably try it again after a few more releases to see if it feels better.
> To install Zed on most Linux distributions, run the shell script below.<p>> curl <a href="https://zed.dev/install.sh" rel="nofollow">https://zed.dev/install.sh</a> | sh<p>Please stop telling people to curl pipe scripts into their shell...
I'm never using this editor unless it can install itself and work completely offline, without going for downloads and making web requests , it is crucial, especially after totally not related xz fiasco and the white house praise for rust.
I installed zed a couple of days ago, tried it for a Java project. It was soooo bare-bone that it vanished from the drive shortly after.<p>Maybe I'm doing something wrong, I got java/maven plugins but there is no XML highlighting. Java does have highlighting but that's it... OH, and and I installed it this time and I noticed "downloading json-language-server"... (it was there before probably but didn't notice)... like WTF - didn't even ask if I want to... utterly rubbish experience.<p>For a simple text editor I prefer BBedit on mac, which is native and blazing fast. And for something slightly more complex I usually end up with `code <file>` to quickly edit it...
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.<p>What's the business model here?
Amused that it is already an official package for Arch Linux.<p><a href="https://archlinux.org/packages/extra/x86_64/zed/" rel="nofollow">https://archlinux.org/packages/extra/x86_64/zed/</a>
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".<p>Great feature but there's a lot more stuff I need for a truly outstanding editor, what are the novel pieces?<p>The bar is ridiculously for editors (vim & emacs configurability, vscode just works, jetbrains can do it all) - what will/does it bring to the table to compete?
I downloaded ZED for a quick play-around, but was quite shocked to find out that editing and saving a file runs an auto-formatter on it _by default_...<p>Whoever thought that was a great idea obviously has never worked with version control, with other people on a project? Sorry, but this is such an obviously wrong default setting, I'm surprised nobody pointed this out before?
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.
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.<p>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.<p>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.<p>So Zed didn't work for me, but I'm sure it will work for somebody else.
I've kept my neovim config, vscode, and zed configs in parity for a while now. To the point that the keybinds and behaviors are the same (or as simliar as they can be) across all three. In my personal experience zed is eating into the time I use vscode, but not really touching neovim as much. It really has come a long way, and I'm excited I'll be able to use it on my Linux machine without having to jump through hoops.
Zed seems like its gotten a lot of buzz on HN, and its great to see new players in the space.<p>For those who have used it, what are some of the killer features?
Tried it with mangohud and scrolled up and down a 100-line c++ file with no lsp enabled. 30fps. Absolutely not ready yet. Not sure I'm willing to leave Emacs, but gpui looks cool and I hope someone makes a fast Emacs client with it some day.
Sadly I can't run it in WSL.<p>thread 'main' panicked at crates/gpui/src/platform/linux/wayland/client.rs:143:51:<p>called `Result::unwrap()` on an `Err` value: UnsupportedVersion<p>note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
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!
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.<p>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.<p>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.<p>It's such a technically hard feature to develop but just doesn't seem to have any utility for me.
Zed is nice and all, but I simply cannot trust a VC backed editor of all things. Eventually, enshittification <i>will</i> occur and I really don't want that to happen to one of my core daily programs.
Whirlwind week.<p>First, Zed found to allow silent (non-consented) background binary downloads [0]<p>Now, launching on Linux.<p>Both of which are big news in its own right.<p>[0] <a href="https://news.ycombinator.com/item?id=40902826">https://news.ycombinator.com/item?id=40902826</a>
> Zed requires a physical GPU with a Vulkan 1.3 driver.<p>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.
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?
There's much to like about Zed. Not only the technical parts, but also how transparently the communication is: <a href="https://zed.dev/blog/zed-is-now-open-source" rel="nofollow">https://zed.dev/blog/zed-is-now-open-source</a><p>To keep things simple yet powerful is the key to find their place in the market IMO. Don't know about the rendering speed (never had issues with other editor), but that's a bonus anyway.
There's something interesting with the light mode / default theme I got after downloading and opening on Apple silicon:<p>Sidebar contrast is too low, yet, spot on for the wrong contrast ratio target (3.0, for fill, versus 4.5 for text/bg).<p>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.<p>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 <i>really</i> appreciate the effort here.<p>Fuzzy/opinionated territory:<p>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.
Sounds great; downloading it now to try.<p>To the Zed folks here, can you please add a little line to say that it is an editor, for people like me who are not in the loop. There's nothing clear on the landing page or on the docs page that indicates it is so. The video shows an editor, but plenty of software has built in editors.
My first impression is the dark mode color contrast is poor compared to VSCode defaults (I tested a few things with CCA Colour Contrast Analyser). I'm sure this is all configurable but it was off-putting to me. I'm still interested in spending more time checking out Zed.
<a href="https://en.wikipedia.org/wiki/Atom_%28text_editor%29#History?wprov=sfla1" rel="nofollow">https://en.wikipedia.org/wiki/Atom_%28text_editor%29#History...</a><p>I found the zed website unhelpful, but if wikipedia is to be believed, it's a successor to the Atom text editor
I gave it a fair try<p>Cons:<p>- 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<p>- text still looks a bit blurry on low DPI screens<p>- doesn't support LSP properly, completion items are missing some data<p>- Rust for plugins.. this is painful, compare it to Sublime Text's python API, it's night and day..<p>Pros:<p>- Fast and responsive<p>- UI is simple yet effective<p>- drag&drop layouting, something i wish Sublime Text had..<p>- built-in terminal<p>- built-in Debugger (not yet ready)<p>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<p>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
Is (Python) debugging on the roadmap somewhere for Zed, or will this remain out of scope?<p>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).
Awesome. Been looking for a next-gen Atom for coding. I use PyCharm most of the time, but sometimes its overkill with its eternal indexing ... :) So I often find myself bringing up SublimeText for working on individual files as opposed to a whole project.
Love it. My VSCode takes 3GB of RAM and that's a single window with like 5 files open at one time. I've long been looking for a good-enough replacement (though I don't think I'll be able to leave debugpy for a while)
As a longtime vim user text editing is not an unmet need or unsolved problem. Lack of time, energy to execute on everything is a much bigger problem. And the very biggest and most dangerous unsolved problems I can see on all our plates involve democracy and climate.<p>Heck I'd like to "solve" all issues with public restrooms in the US, for example, or the lack of planning for trees or shade or water conservation, first, before I'd spend time on Yet Another Hip New Text Editor. The latter is perhaps several hundred slot ranks down (at most generous to it) in my priority list.
I don't know if it's just me but vscode feels like it isn't as fast as it used to be. The terminal also keeps getting messed up on Linux.<p>Will definitely try one this out!<p>Although the amount of plugins and community knowledge of vscode is immense.
I don't really like their editor, but their fonts (based on iosevka) is my 2nd favorite (after Mensch).<p>And their opensource development mode is the best one I've seen so far! So many nice choices.
I do not get the focus on collaborative editing (surely niche?) while the Remote Development in VS Code (in which "remote" can mean in a docker container running on your local Docker, or a container elsewhere, or a whole-ass other computer you own, or a rented computer/instance in le cloude) seems like such a more game-changing feature, similar in some ways but probably less work.<p>And make that the thing you charge for. ¯\_(ಠ_ಠ)_/¯
Zed's focus on high performance might be misplaced. Compared to editors like VSCode, the performance boost feels marginal. To convince developers to switch, the emphasis should be on enhancing the overall developer experience. Marginal speed gains alone aren't enough to make me move away from VSCode, and I don't care if a tool is written in Rust or any other language.
Generally a big fan of Zed. Super fast and quite innovative in their grep UI. My biggest current gripe is Zed's filesystem watchers are either broken or misconfigured on Mac. If I do a `git rest --hard` via terminal or github desktop UI, zed doesn't detect it and I'm forced to do a hard reset of the app to get back to a synced state.
I don’t think I could ever switch to a windowed app as editor, vs a TUI, eg neovim. The remote story is never great for me. It forces your editor to slowly bloat to become your entire IDE. Native remote dev using tmux is so nice. Can anyone persuade me otherwise?
On one end of the spectrum, you have programmers who use Visual Studio Code or Atom or one of the other Electron-based code editors (<a href="https://en.wikipedia.org/wiki/Electron_(software_framework)" rel="nofollow">https://en.wikipedia.org/wiki/Electron_(software_framework)</a>), and at the other, you have programmers who use vim or even vi (<a href="https://en.wikipedia.org/wiki/Vi_(text_editor)" rel="nofollow">https://en.wikipedia.org/wiki/Vi_(text_editor)</a>).<p>Now, me personally (and this is just one man's tiny and insignificant opinion in a sea of billions of people!),<p><i>I personally, am slightly more inclined to give a slight bit of additional weight to the opinions of people closer to the vim/vi side of editor use, than I am to give to people on the Electron-based side...</i><p>My humble apologies if this offends anyone.
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.<p>You don't see that kind of behaviour from Microsoft and Apple.
It worked well out of the box, but the font rendering is a bit off. Using x11, not wayland.<p>The default font was a bit small on a 4K resolution by default, but it was easy discover how to enlarge it.<p>Opening a Rust project worked flawlessly without any configuration at all.
I started using this a few hours ago and so far am really pleased with the experience. Vim keybindings mostly work as expected and TS integration works great oob. I can totally see this becoming my primary editor going forward.
I tried on Intel GPU ( dell xps 9305 ) with Ubuntu 20.04 and it does not open a window, with --foreground that's what I got:<p>zed --foreground<p>MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0<p>Is there even more debug available?
Looks like someone was already maintaining an ebuild for Gentoo <a href="https://gpo.zugaina.org/app-editors/zed" rel="nofollow">https://gpo.zugaina.org/app-editors/zed</a>
Installed it on my Fedora 33 box running the AMD drivers from the kernel and a 6800 GPU and I can game no problem with proton and steam but Zed ran very very slowly. Sluggish. Immediately uninstalled. :/
Fantastic news. I've enjoyed using Zed on Mac for Go development, it just feels snappier than VSCode. I hope to try the Linux build over the weekend.<p>I am also tempted to try out their gpui library, might just cure my Rust aversion.
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.
If I understand correctly I need a graphical card - my current linux laptop does not have one. Until I upgrade to a newer model I will uninstall my copy of zed.dev - couldn't even launch it.
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.
Selection color is not particularly good with comments: <a href="https://i.imgur.com/ExeT7Ne.png" rel="nofollow">https://i.imgur.com/ExeT7Ne.png</a>
To save you time: If you're on macOS, you can install with<p><pre><code> brew install --cask zed
</code></pre>
The docs don't make it very clear that the cask is available via homebrew.
The only reason why I dropped (and Im not alone) using Zed is the arcaic UI sublime-like search functionality. Please revisit that part because I really want to use ZED.
Super excited for this project. Especially since it's available for Linux now.<p>I still use the JetBrains products as daily drivers but always keen to use new tools like this.
Does anyone know what is their monetization plan, or if they even have one? Editor with even this much polish takes a lot of time and effort. How is it being funded? Can we expect useful features to progressively get locked behind subscription as it grows in popularity (a la Gitlab)?<p>Edit: Nevermind, found it - <a href="https://zed.dev/faq#how-will-you-make-money" rel="nofollow">https://zed.dev/faq#how-will-you-make-money</a>. Interesting charter.<p><pre><code> 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.
</code></pre>
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.
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.<p>[1]: <a href="https://zed.dev/docs/linux" rel="nofollow">https://zed.dev/docs/linux</a>
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).
"real programmers" just use vim<p><a href="https://xkcd.com/378/" rel="nofollow">https://xkcd.com/378/</a>
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 ...<p>Yeah ...<p>I'll stick with VScode, might be slow but works
> To install Zed on most Linux distributions, run the shell script below.<p>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.<p>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.<p>For example, I see that the shell script downloads a tarball and unpacks it to `~/.local`, then tries to mess with my PATH variable.<p>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.<p>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.
Really dislike the one line installer. How is it installing? Flatpak? Adding an apt repo? Manual install?<p>Fortunately docs go into better detail, <a href="https://zed.dev/docs/linux" rel="nofollow">https://zed.dev/docs/linux</a><p>I'm on Debian anyway so who am I kidding expecting this to be in apt :D
I really don't get why this is the modern editor style of choice.<p>20% (35 chars) of screen space permanently wasted on a always on file browser (meanwhile the animation showcases fuzzy finding)<p>4% (7 chars) of screen space permanently wasted by line numbers (why are the numbers cut off on the right?)<p>2.7% (5 chars) of screen space taken up by a gutter<p>So 27% of screen space effectively dead 99% of the time.<p>Why do people do this to themselves?<p>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).<p>Why does the "modern text editor" waste so much screen space?<p>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.
First impressions:<p><pre><code> 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?
</code></pre>
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.
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.<p>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.
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.