The Creators of the Atom Code Editor Open-Source Zed, Their New Rust-Based High-Performance Editor
The Creators of the Atom Code Editor Open-Source Zed, Their New Rust-Based High-Performance Editor
Nathan Sobo recently open-sourced Zed, a code editor that focuses on performance, integrates AI capabilities, and supports software teams’ collaboration out of the box. For performance, Zed leverages a Rust code base, multicore- and GPU-optimized code, with a custom Rust GUI framework. For collabora...
You're viewing a single thread.
It's strange because how much "powerful" or "high performance" a code editor needs? It's just , a code esitor you can code in notepad lol
You can code in Notepad in the same way you can eat off the floor with your hands. Using better tools is a nicer experience.
As for performance, when one of the world's most popular editor runs on Electron, it's not that hard to see why performance could be an issue when working on large projects on older hardware.
I've never personally had an issue with VSCode's performance, but I'm also fortunate enough to be in a position where I can afford a relatively modern machine. Many others have to make do with what they have, which is why Zed might appeal to them.I mean, I rock JetBrains for a lot of stuff. It's a pig on resources, but man does it have a great feature set.
Electron has other drawbacks than performance as well.
The big one for me is that my workflow is based on vim, where you split tabs into buffers. There is no way to split a tab into windows in VSCode. Only windows into tabs, which is super dumb and annoying because related files are never shown together unless you click a bunch of tabs. Apparently the reasoning for this insane behavior is "yeah well electron is based on chromium so tough luck we can't do shit".
What do you mean by:
There is no way to split a tab into windows in VSCode.
Do you mean, drag a tab out of a window to create a new window? Because if so, you can do that in vscode.
No, literally have one tab with multiple windows inside it (the default for vim).
tab 1 | tab 2 w1 | w2 | w1 | w2 w3 | w4 | w3I'm assuming for your example that only one tab is shown at a time?
In that case, you can do that in vscode, the only difference is the semantics of what is considered a "window", and what is considered a "tab".
To do this in vscode:
Have one window with four panes, and another window with three panes:
Window 1 ┌──────────┬──────────┐ │ │ │ │ Pane 1 │ Pane 2 │ │ │ │ ├──────────┼──────────┤ │ │ │ │ Pane 3 │ Pane 4 │ │ │ │ └──────────┴──────────┘ Window 2 ┌──────────┬──────────┐ │ │ │ │ Pane 1 │ Pane 2 │ │ │ │ ├──────────┴──────────┤ │ │ │ Pane 3 │ │ │ └─────────────────────┘You can then switch between your windows (or "tabs" in your example) by keyboard shortcut.
In vscode, you can make the Panes different files, or even different views of the same file.
You mean a whole different window at the OS level? That's just a way inferior hack to the way vim does it by default.
I've found an issue from 2017 about it and this related one that focuses more specifically on supporting vim-like behavior. This is just, fundamentally, something that VSCode doesn't implement simply because of technical limitations. The extensions that attempt to recreate this behavior are apparently all quite janky.
I mean I don't care, I'm very happy with vim now. But the terribly naive tab support is the reason I left vscode for vim initially. People who have only known "vscode-like" tabs don't know what they are missing out on.
You mean a whole different window at the OS level?
Yes, that way I could switch between windows in a single shortcut, or even place them side by side so I can see both at the same time with other shortcuts.
That’s just a way inferior hack to the way vim does it by default.
Can you explain this more?
Why wouldn't you want window management to be managed by the window manager?
Sorry, I didn't log into this account for a while.
Anyways, I guess in an ideal world the window management could be done fully via the window manager. In practice this doesn't work too well, because that would require a more complex protocol than currently exists. For VSCode for instance, that would require disabling the native tabbing feature (but keeping the native splitting because otherwise I'll end up with duplicated panes such as the file list) and implementing something custom to translate tab operations to sway-wm operations (in my case).
I guess it could work but it's not supported OOTB, and after a lot of work is probably going to end up being a lot more clunkier than what I have going on in vim.
I'll be honest it was surprising how much nicer using GPU accelerated terminal was for me.
If you are in a ui enough snappyness is a nice to have for sure.
That said this is an IDE not just a text editor, the automated tools is what sets the apart.
I could notice the slowness of Atom when I compared it to VS Code. Sublime is also noticeably faster than VS Code, but the gap doesn't feel so wide that I want to jump the ship.
I think it depends on the number of characters in the file that make the difference more noticeable.
You can really see the difference between opening VSCode and Zed, even more so if you compare it to something like JB's Fleet editor.
To be fair, it's not the easiest to compare right now since Zed is lacking a million features of Code, but if all the work they've done keeps it as fast as it is with features like user extensions it will be well worth it.
I usually have ~10 different VS Code windows open at a time (yay microservices ❤️), so having something as fast as Zed would be really appreciated.
Yeah like Atom or VSCode this is more a half-IDE in concept. Assuming it gets enough support it's somewhere between a text editor (but will be more sluggish than pure text editors and struggle with very large files but then you ought to have specialized log viewers for that anyways) and an actual IDE (but have only limited IDE features).
Agreed. It's weird to put the performance of a text editor at the center of PR.
I have sooooo many questions.
Why do they compare a text editor's performance with that of IDEs??? CLion is possibly the slowest of all Jetbrains IDEs because the C++ language is very complex. Choosing CLion makes even less sense because IntelliJ is now public-testing a lightweight C++ CLion spinoff, which is faster than CLion.
Why should I care whether my editor is written with Rust? C was fine as long as I trust the devs on security. Async doesn't matter at all to the enduser...
Besides, if I wanted a snappy editor I just use vim.
My fear is that they might have concluded that all the performance boost they made wasn't important as a text editor, and they are presenting some weird comparison to hide it.
Besides, if you write C++, the bottleneck is not the typing response, but the code analyzer.
It's also not like C++ is a language used by majority of customers. Why not advertise with JavaScript instead? Python? Those are also better fit for text editors. Because statically typed languages like C++ can benefit hugely from a full-fledged IDEs, taking away the room for this text editor further.
It feels like their AI integration is not outstanding (probably not, indeed).
The collaborative editing might not align well with their emphasis on responsiveness, either, because the network latency will be felt. Not to mention that collaborative editing is pioneered by IntelliJ, also.
Why do you need another channel/chat management tool if your team already has a Slack? Why would your team use a chat platform that can be used only by mac users?
As I indicated in my other comment, it's possible that the PC port of their GPUI-based GUI can be far slower due to the heave reliance on Apple Silicon. I even doubt a port is possible in the first place, especially if their code heavily relies on Apple-specific APIs for the Silicon.
And all descriptions of their features are suspiciously vague. How are they better than a marketing scheme to raise the stock price?
Maybe it is going to be just an average editor in the era of remote-office (looking at channels and collab edit), ChatGPT-assists (AI-integration) and async. Maybe it's a proof-of-concept that will soon give ways to another generation of editors.