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.
Oh, thank goodness. Yeah, that's going to be a major quality of life improvement for me. I had a feeling it'd eventually make its way into Zed eventually, but when I initially read the issue I was under the impression that there was no plans to add options around this, which I found confusing.
If any zed devs are in this thread: I highly highly suggest that any auto-download or upload (be it telemetry, plugins being downloaded, and worse: plugins uploading god knows what) is opt-in or at the very least easy to opt-out.
The eagerness to download stuff without my consent at the moment precludes me from using this e.g. in a job that touches a sensitive proprietary codebase.
This is a non-starter for many larger companies. With supply chain attacks being what they are currently, this would directly prompt Security teams to block this outright.
And with that all my interest is gone and I won’t bother with zed.
I highly recommend Little Snitch or opensnitch to protect oneself from rogue developers. Yes, anybody downloading things or uploading things without my consent is a rogue.
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.
I just tried it on NixOS 24.05. It starts, but nothing happens when I click "Open a project" or Ctrl+O. It's as if it lacks the ability to show a file selection dialog.
I really wish they would bundle up the basic Language Servers with the download (HTML, CSS, TypeScript) so it at least has parity with VSCode in this regard
Just a suggestion. One of the best features of pure text editors (and incredible, not all of them implement it) is autosave keeping the "unsaved" state of the file.
For example, if you make some changes in a file (new or not), don't save the changes, close and open the editor, the state of the opened files are kept like I never had closed the editor. The unsaved files are still unsaved. New edited files are still there, unsaved, ready to user manually save them.
Notepad++ works that way, and it is an amazing feature.
Similarly, I have unlimited persistent per-file undo turned on in Neovim. I can open any file I've edited previously and walk through the full history of how it got there. With Undotree [0], I can even navigate branching paths in development. I don't know how people live without this.
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?
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.
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.
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.
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.
I have fallen in love with Zed on Mac, so glad to see it will still be an option when I switch back to Linux. My main concern is the collaboration features; just seems like a nonsensical addition. I have zero influence over what editors my teams use, and I work with dozens of different people on collaborative development every year - I'm not going to be persuading anyone to switch, and so that feature is just dead code and security risk. Even if I worked on a small and consistent team, I don't think the value-add justifies the complexity and risk.
For what it's worth, other major code editors Jetbrains and VS Code also offer real-time collaboration built in. For Jetbrains, it's a paid feature. For VS Code, it's free.
I love the VS Code implementation (haven't reviewed the other two). If I'm pairing with someone remotely, I don't have any issue having them download VS Code. We provide a config in our project repo for VS Code, so it's really quick for people to get set up enough to join the real-time collab session with me. `brew install visual-studio-code` and then `code .` in our repo, plus OAuth with Github to authenticate the collaboration feature.
I think it really is great. Makes pairing much easier, and really speeds up drugery like refactoring 500 cases where it doesn't quite make sense to do a codemod. It's not quite like the upgrade from Word97.exe to Google Docs since we have git, but it feels similarly amazing to "just" to be talking about some code, click the other user's icon to jump right to their cursor and help them get unstuck.
I personally bounce between VS Code, Xcode, and nvim+tmux, and I don't have a problem with keeping a "lowest common denominator" editor around for collaboration or pairing. I also keep a regular keyboard at my desk so I don't force people to type on my Glove80/Kinesis Advantage.
My experience with the VS Code implementation has been constant desyncs between the editor state on the different users computers. At least some of them I could reliably reproduce by using language server commands.
The main reason I'm excited for zed is for an editor that built this in from the beginnings and has the same feature with less bugs.
As someone who hates Microsoft, I just wish that other colleagues wouldn’t force me to use their editor to collaborate. I wish there was more effort to build something editor agnostic.
I have felt similarly about collab tools. Even if the tools in an editor look cool, someone on the team is gonna get left out because they use a different tools. It feels a bit like the wrong layer for the collab tools to live.
Absolutely agree, the collaboration features put me off a bit. I think it can very well become a very successful and popular editor without those features. Perhaps they can invest in those feature when they have a much bigger market share.
The collab features are actually what got me to try it, and why it’s still installed on my machine.
I have no reason to use Zed over Kakoune or VS Code for working on my own (open-source VS Code, so no Liveshare).
I wanted to work on code with someone a few weeks ago, and we both downloaded Zed and started collaborating very quickly. It was a very smooth experience.
What does Zed use as the UI toolkit? Looking at the code they have a handmade UI toolkit called gpui. Does that map directly to OS/DE specific GUI bindings? I can't find where that's happening
EDIT:
Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild
> Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild
I grew up developing Windows apps using the native Win32 API:s, and there was nothing particularly daunting about it. Using what the OS provides shouldn't be considered such an outlandish idea, and being scared of it is causing stagnation and waste (looking at you, Electron). The code here is only a couple of thousand lines per platform; surely only a small fraction of the entire code base.
I'm not sure how much of it is people being (irrationally) scared vs. looking into native APIs and making the call that it just isn't worth it, given how much messing around you have to do to get basic functionality working vs. the web where you can throw a UI together very quickly to validate an idea.
I've looked into native Linux development a few times, for example, and haven't even been sure what's the best toolkit to use. It feels like you'd have to invest quite a lot in a particular toolkit to even see if it can do what you need, coming fresh from web dev like a lot of people who go for Electron obviously are (myself included).
We have a couple of blog posts digging into gpui, but here is one from just after rewriting and shipping gpui2: https://zed.dev/blog/gpui-ownership
We’ve slowly been building out gpui to be super ergonomic and fluid for us to build the kind of UI we need to.
As a designer that just picked up Rust last February it’s been really nice to have something that is so comfortable to work with without compromising our performance goals.
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.
I wonder if they ever considered using Qt. Not sure what the status of that is for rust projects. Sounds like it does the same as what Z is doing, mapping user interaction to os bindings and rendering the UI using the GPU.
However silly it is, I've always hated the aesthetics of VS Code. I know it's themeable but despite that the overall look and feel just isn't right on MacOS or Linux. That side bar drives me crazy.
I find that out-of-the-box Zed is much prettier and feels more native than VS Code. But for a tool that we spend hours using each day, how it looks and makes you feel really matters.
I am enjoying experimenting with Zed. I have kept my extensions and configuration to a minimum which is a refreshing change compared to the cluster that my VSCode installation has become.
The first thing I do on any VS Code fresh install is to switch the sidebar to the right. Pure heresy for many people, I know. But I want my eyes to naturally land on code, not on a file tree.
Its actually pretty obvious advantage if you are often ctrl+b hide sidebar because instead of jarringly moving start of the line you are revealing code without moving it.
IntelliJ is much slower than any other editor including Zed and VsCode it's much slower to open and navigate, much slower to work with, much slower, it's so slow! but the code completion, refactoring, code navigation, and debugging features and endless other smart features are incredible. For me, that extra intelligence and code awareness boost translates to way faster development overall, even if the IDE itself takes a bit longer to load or work with or consumes huge amount of memory. Sometimes the smarts outweigh the raw speed.
If you're familiar with nvim, you slowly realize how bloated and unnecessary the indexing is in intellij. It makes the experience so awful and for what? A file search feature that takes multiple seconds to find a file in root
Indexing maybe. But there's more: IntelliJ understands your code, and this make more sense for static/strong typed langs. We do a lot of Kotlin and IntelliJ is indispensable.
Same. I was just using (heavily customized) vim for many many years, and was kinda ok, but then I eventually switched to IntelliJ products at work, and while I don't really like the idea of using a product with subscription, I cannot quite switch to anything again, and have to install them even on my personal machine. Didn't try Zed though.
And it's quite annoying that I really don't think that the product I'm actually using is something crazy complicated only an for-profit enterprise can implement. Just the same as in my vim-years, I only need a good editor, that helps me to type less. In interpreted languages (Python, PHP) I don't even use debugger, debugging via print actually feels totally fine to me. What I need seems pretty similar, and is seemingly included into every modern editor I know: vim-keybindings, good "code smell" highlightings, autocomplete & some refactoring automation. The devil is in the details though. Vim emulation is never perfect, but in IntelliJ it's usable, which doesn't happen often. Static-analysis IntelliJ does seems pretty basic to me, yet somehow even that level is usually lacking (also, the ability to disable specific suggestion via annotations in IntelliJ products is great, as I feel like this functionality is only really useful when I strive for 100% "green" status, just conciously disabling what I'm not going to fix). But the most annoying thing is auto-refactoring. I mean, it feels like a simple thing, I never tried, but I think most common refactoring patterns I do daily I could automate quite easily, given I already have basic syntax-tree operation implemented. But somehow even IntelliJ is pretty poor on refactorings, and what I've seen in VSCode plugins is even worse. Again, no idea about Zed. I guess I should try it.
What do you do to make Idea slow? On my computer, everything is blazing fast. Idea is very fast, like 1-2 seconds to open a project and then it's just works instantly. Same about vscode.
I tried zed for a few weeks because I'm generally sympathetic to the "use a native app" idea vs Electron. I generally liked it and its UX but:
1. VSCode is pretty damn fast to be honest. Very rarely is my slowdown in my work VSCode loading. Maybe I don't open very large files? Probably 5k lines of typescript at most.
2. Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.
Eventually all the little inconveniences wore on me and I switched back to VSCode.
I will probably try it again after a few more releases to see if it feels better.
I'm on the same camp, but in the end it turns out we were not putting it to the actual, real, hard-world test.
VSCode is very fast for me, when I open it in the morning and just starting my day.
But once I've opened the main project and 7 support library's projects, and I'm in a video-call on Chrome sharing my screen (which is something that eats CPU for breakfast), and I'm live-debugging a difficult to reproduce scenario while changing code on the fly, then the test conditions are really set up where differences between slow/heavy and fast/lightweight software can be noticed.
Things like slowness in syntax highlighting, or jankyness when opening different files. Not to mention what happened when I wanted to show the step-by-step debugging of the software to my colleagues.
In summary: our modern computer's sheer power are camouflaging poor software performance. The difference between using native and Electron apps, is a huge reduction in the upper limit of how many things you can do at the same time in your machine, or having a lower ceiling on how many heavy-load work tasks your system can be doing before it breaks.
> 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.
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.
It's a Prisoners's Dilemma. Since apps are evaluated in an isolated fashion there is an incentive to use all the resources available to appear as performant as possible. There is further incentive to be as feature-rich as possible to appeal to the biggest audience reachable.
That this is detrimental to the overall outcome is not unfortunate.
> 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.*
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.
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.
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.
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.
> I think people just have very different tolerances for latency and slowness.
I wonder if it's because of a form of "touch typing". I'm not really looking at text appearing as I type. My fingers work off an internal buffer while my mind is planning the next problem. If not so deep in thought to almost be blind, I am reading other docs / code as I type. I am not an ultra fast typist but if I mistype, I can feel it and don't need the visual feedback to know it. I might be this way because I am old and have used tools with lag you measure in seconds.
I only care about latency if it interrupts me and I have to wait and that's typically not typing but heavier operations. I am utterly intolerant to animations. I don't want less I want zero, instant action. I don't want janky ass "smooth scrolling" I want crisp instant scrolling. I have no idea why animations are even popular.
Some of the text-editor latency discussion reminds me of high screen refresh rates for office work. When people "check the refresh rate" they have to do that violent wiggling of window to actually have large content moving faster enough to see a difference. You have to look for it to then get upset about it.
The worse case would be if it's more of an illusion like fancy wines - a fiction driven by context. Lie to someone that an editor is an electron app and they will complain about the latency. Software judgement also has toxic fashion and tribal aspects. Something unfashionable will accrue unjustified complaints and something cool or "on your team" will be defended from them. I'm reminded of Apple fans making all sorts of claims about rendering unaware that they were using Apple laptops that shipped not running at their natural resolution and visibly blurry. Your lying eyes can't beat what the heart wants to believe.
> 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.
> 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.
TS itself is lock-in. I mean, the entire point of JS is that it's portable, and there's certainly no lack of compile-to-JS languages that are already finished and have much more powerful type systems and existing libs/ecosystems.
Enjoy your VScode projects exclusively on Windows a couple years down the road, or rather, contribute to MS' coding ML models to make yourself obsolete even before. Windows already posts home everything it has gathered on you the second it connects to the net, and I'd expect vscode to as well.
But the infanterists in our profession manage to get it wrong, every single time.
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.
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.
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.
> Integration with the Typescript language server was just not as good as VSCode. I can't pin down exactly what was wrong but the autocompletions in particular felt much worse. I've never worked on a language server or editor so I don't know what's on zed/VSCode and what's on the TS language server.
VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.
A few weeks ago I had this giant json text blob to debug. I tried Gedit first, and it just fell over completely. Tried vim next, and it was for some reason extremely slow too, which surprised me.
VSCode loaded it nearly immediately and didn't hang when moving around the file. I have my complaints about VSCode, but speed definitely isn't one of them.
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.
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.
I don't use it as my main editor (I'm far too used to the Jetbrains editors to make the switch, they're just too smart), but it's the best one for CLI apps that use EDITOR, like git. It boots up basically instantly even when it hasn't been launched in a while and I can make my commit messages and immediately close stuff up at the speed of my thought.
In the morning vscode is ok, come noon, it’s the primary thing eating my battery and it’s getting slower and slower; day end it’s unusable. Sure, restart it, I know, but it’s fairly terrible though.
Zed looked pretty cool but the amount of extensions VSCode has makes it difficult to justify a switch. I do think that the SQL extensions for VSCode are pretty terrible, so maybe that's something where Zed can capitalize.
Interestingly the biggest issues we're having with VSCode have nothing to do with the IDE itself and are instead related to the TypeScript language server. There are so many bugs that require the TypeScript language server to be restarted, and there's little the VSCode team can do about that. Made a new file? Restart. Rename a file? Restart. Delete a directory? Restart. Refactor a couple of classes? Might need a restart.
We're also having some serious language server slowdowns because of some packages we're using. And there's not much Zed can do here for us either. It's really unfortunate because the convenience of having a full-stack TypeScript application is brought down by all of these inconveniences. Makes me miss Go's language server.
Yeah, this was mostly my experience. The Zed editor was fast, but it just felt like it wasn't as good as other editors. For me, the version control integration was particularly poor - it shows some line information, but diffing, blame, committing, staging hunks, reviewing staged changes etc are all missing.
There were a bunch of decisions that felt strange, although I can imagine getting used to them eventually. For example, ctrl-click (or jump to usages) on a definition that is used in multiple places opens up a new tab with a list of the results. In most other editors I've used, it's instead opened up a popover menu where I can quickly select which really I want to jump to. Opening those results in a new tab (and having that tab remain open after navigating to a result) feels like it clutters up my tabs with no benefit over a simple popover.
Like you, I'll probably try again in a few releases' time, but right now the editor has so much friction that I'm not sure I actually save any time from the speed side of things.
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.
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.
> 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.
Hah, similar here. I keep trying it out after seeing posts here and there, but I can't seem to switch from VSCode.
For nearly anything I do it is fast enough, it starts in less than 2 seconds, and the main thing I like about VSCode is ability to switch projects with fuzzy autocomplete. That means I can jump between repos also in a few seconds, which is a huge lifesaver given I switch things frequently.
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.
I have a mono repo. There's lot in it. And lot many files. Typescript. Go. Python. I have a lower end mac book Air. Not having any issues with VS code.
Yeah my experience has been that you aren't going to suffer performance problems with VSCode unless you have an incredibly large codebase. Past a certain point I'm sure Vim/NeoVim/Zed are probably much more performant, but the differences in smaller codebases is barely noticeable IME.
My only problem with VSCode is that it's owned by Microsoft. I'm willing to put up with some extra friction if it allows me to escape their ecosystem even a little bit.
My general rule is if I can get at most of what I need from the open source version of something, I use it. Even if it's less user friendly.
Completely agree. Furthermore, you could always just not pipe it to sh, read it first if you care so much. Releasing and maintaining packages across a range of distros is extremely hard and time consuming, and they just released the linux version.
Because you don't know how the script is going to try to install the program. A double-click installer on Windows has a standard approach that results in the program being placed in C\Program Files and the files being tracked and an uninstaller being placed in a centralized location. On Linux, any random "installer script" could spew files all over your /usr or anywhere else with no way to clean them up. This could even break your OS.
The Linux equivalent to double-click installer is ... a double-click installer, Flatpak. Or for even more bonus points, make the app fully portable as an AppImage. In the rare case I can't find what I'm looking for in my distribution repos, I look for an AppImage.
macOS for example checks the crypto signatures of downloaded apps, so it’s much better than randomly executing code from the internet.
I think even Windows does this nowadays.
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
I always see this comment and understand its reasoning, but people who check what they are installing are the same people who can download and check a shell script.
In this case it's 150 rows with spaces and comments and the first one is
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.
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.
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.
Readit News
The thing is, I would just disable it, but you can't, as far as I can tell. There's this somewhat angry issue about it here:
https://github.com/zed-industries/zed/issues/12589
They might have a point but beyond whether or not they have a point regarding the fact that it automatically fetches binaries from the Internet, not having an option to disable it is just cruel.
I still like Zed a lot and I also have a big appreciation for the design of GPUI, which I think is a very well-designed UI library that puts focus on the important things. So, I hope it goes well.
The eagerness to download stuff without my consent at the moment precludes me from using this e.g. in a job that touches a sensitive proprietary codebase.
I highly recommend Little Snitch or opensnitch to protect oneself from rogue developers. Yes, anybody downloading things or uploading things without my consent is a rogue.
Dead Comment
Doesn't it work with:
Still not ideal though.NixOS is listed here: https://zed.dev/docs/linux
For me, works as expected.
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.
[0] https://github.com/mbbill/undotree
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?
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.
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...
The main reason I'm excited for zed is for an editor that built this in from the beginnings and has the same feature with less bugs.
I have no reason to use Zed over Kakoune or VS Code for working on my own (open-source VS Code, so no Liveshare).
I wanted to work on code with someone a few weeks ago, and we both downloaded Zed and started collaborating very quickly. It was a very smooth experience.
EDIT:
Holy sh*t, they actually have bindings for each OS and built a Rust abstraction on top of that. That's pretty wild
https://github.com/zed-industries/zed/blob/main/crates/gpui/...
I grew up developing Windows apps using the native Win32 API:s, and there was nothing particularly daunting about it. Using what the OS provides shouldn't be considered such an outlandish idea, and being scared of it is causing stagnation and waste (looking at you, Electron). The code here is only a couple of thousand lines per platform; surely only a small fraction of the entire code base.
I've looked into native Linux development a few times, for example, and haven't even been sure what's the best toolkit to use. It feels like you'd have to invest quite a lot in a particular toolkit to even see if it can do what you need, coming fresh from web dev like a lot of people who go for Electron obviously are (myself included).
We’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.
Let us know if so - they should just work™, but would love to know if that is not the case.
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.
Thank god I'm not alone. Besides being unsightly, it also looks like a toy.
And it's quite annoying that I really don't think that the product I'm actually using is something crazy complicated only an for-profit enterprise can implement. Just the same as in my vim-years, I only need a good editor, that helps me to type less. In interpreted languages (Python, PHP) I don't even use debugger, debugging via print actually feels totally fine to me. What I need seems pretty similar, and is seemingly included into every modern editor I know: vim-keybindings, good "code smell" highlightings, autocomplete & some refactoring automation. The devil is in the details though. Vim emulation is never perfect, but in IntelliJ it's usable, which doesn't happen often. Static-analysis IntelliJ does seems pretty basic to me, yet somehow even that level is usually lacking (also, the ability to disable specific suggestion via annotations in IntelliJ products is great, as I feel like this functionality is only really useful when I strive for 100% "green" status, just conciously disabling what I'm not going to fix). But the most annoying thing is auto-refactoring. I mean, it feels like a simple thing, I never tried, but I think most common refactoring patterns I do daily I could automate quite easily, given I already have basic syntax-tree operation implemented. But somehow even IntelliJ is pretty poor on refactorings, and what I've seen in VSCode plugins is even worse. Again, no idea about Zed. I guess I should try it.
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.
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.
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.
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.
That this is detrimental to the overall outcome is not unfortunate.
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.*
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.
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.
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.
fwiw I’ve also found the configuration overhead much lower with Helix than for pretty much any other editor I’ve seriously used.
I wonder if it's because of a form of "touch typing". I'm not really looking at text appearing as I type. My fingers work off an internal buffer while my mind is planning the next problem. If not so deep in thought to almost be blind, I am reading other docs / code as I type. I am not an ultra fast typist but if I mistype, I can feel it and don't need the visual feedback to know it. I might be this way because I am old and have used tools with lag you measure in seconds.
I only care about latency if it interrupts me and I have to wait and that's typically not typing but heavier operations. I am utterly intolerant to animations. I don't want less I want zero, instant action. I don't want janky ass "smooth scrolling" I want crisp instant scrolling. I have no idea why animations are even popular.
Some of the text-editor latency discussion reminds me of high screen refresh rates for office work. When people "check the refresh rate" they have to do that violent wiggling of window to actually have large content moving faster enough to see a difference. You have to look for it to then get upset about it.
The worse case would be if it's more of an illusion like fancy wines - a fiction driven by context. Lie to someone that an editor is an electron app and they will complain about the latency. Software judgement also has toxic fashion and tribal aspects. Something unfashionable will accrue unjustified complaints and something cool or "on your team" will be defended from them. I'm reminded of Apple fans making all sorts of claims about rendering unaware that they were using Apple laptops that shipped not running at their natural resolution and visibly blurry. Your lying eyes can't beat what the heart wants to believe.
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.
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.
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.
Enjoy your VScode projects exclusively on Windows a couple years down the road, or rather, contribute to MS' coding ML models to make yourself obsolete even before. Windows already posts home everything it has gathered on you the second it connects to the net, and I'd expect vscode to as well.
But the infanterists in our profession manage to get it wrong, every single time.
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.
[1]https://danluu.com/keyboard-latency/
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.
Dead Comment
VSCode cheats a little in this area. It has its own autocomplete engine that can be guided by extension config, which it mixes seamlessly into the autocomplete coming back from the LSP. The net result is better autocomplete in all languages, that can’t be easily replicated in other editors, because the VSCode augmentations can often be better than what an LSP produces.
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.
But I still struggle to find a reason to not use neovim, it's replaced all my editors.
Nvim works flawlessly tho even with syntax highlight and folding.
Interestingly the biggest issues we're having with VSCode have nothing to do with the IDE itself and are instead related to the TypeScript language server. There are so many bugs that require the TypeScript language server to be restarted, and there's little the VSCode team can do about that. Made a new file? Restart. Rename a file? Restart. Delete a directory? Restart. Refactor a couple of classes? Might need a restart.
We're also having some serious language server slowdowns because of some packages we're using. And there's not much Zed can do here for us either. It's really unfortunate because the convenience of having a full-stack TypeScript application is brought down by all of these inconveniences. Makes me miss Go's language server.
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.
[1] https://theia-ide.org/
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/
For nearly anything I do it is fast enough, it starts in less than 2 seconds, and the main thing I like about VSCode is ability to switch projects with fuzzy autocomplete. That means I can jump between repos also in a few seconds, which is a huge lifesaver given I switch things frequently.
Slack & Teams on the other hand, ouch.
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.
and there are third-party builds from the community that disable things like telemetry: https://vscodium.com/
Deleted Comment
Deleted Comment
> curl https://zed.dev/install.sh | sh
Please stop telling people to curl pipe scripts into their shell...
This is basically the Linux equivalent of download and double click which is a user flow that is underrated for simplicity and usability.
The Linux equivalent to double-click installer is ... a double-click installer, Flatpak. Or for even more bonus points, make the app fully portable as an AppImage. In the rare case I can't find what I'm looking for in my distribution repos, I look for an AppImage.
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
In this case it's 150 rows with spaces and comments and the first one is
# Downloads the latest tarball from https://zed.dev/releases and unpacks it # into ~/.local/. If you'd prefer to do this manually, instructions are at # https://zed.dev/docs/linux.
Then it's a download, extract and copy stuff around, it takes 1 minute to visually parse
If an install script is obfuscated then yeah, I'd skip it too.
[1] Standard “GNU”/linux desktops
Also, cleaner uninstalls. If the software only has access to specific directories, I can be reasonably optimistic that removal will be clean.
Furthermore, it is much more convenient. E.g., I can just winget install vscode instead of having to google download links.
Can Linux have something like the Mac App Store where apps don't have access to the whole system by default?