Yup. Especially since it's written in Rust... Like why? Rust has a great cross-platform story.
they've written a custom GPU framework to achieve the performance the level of performance they have. it's currently only compatible with macos, but is being ported to other operating systems.
Why in the world wouldn't you just use Vulkan? Then it would still be portable to other platforms with probably still good performance, no?
vulkan is a graphics api, not a framework. their framework is using vulkan.
This is wrong. Their framework uses metal, which is an apple only graphics API.
My bad, I was referring to the new Linux implementation which is using Vulkan, which was not clear. The MacOS implementation only supports Metal, as MacOS does not support Vulkan natively. I assume the Vulkan implementation will also be what is used for the Windows build.
How much GPU performance do you need for text?
For sure. If 32-year-old vim can handle multi-GB files smoothly, you don't need a GPU.
I guess if you are committed to supporting a hard to support platform, may as well get it out of the way first?
But yeah, seems like a pretty poor release.
Looking forward to the memes once this dies
(Zed's dead)
Sounds cool! Too bad it's only on MacOS atm
They wrote their own GUI toolkit (oof) and it's hardware accelerated (argh), so OS portability is going to be unusually difficult unless they planned for it from the beginning. No mention of that in the article, so I doubt they did.
They already have very experimental Linux support. You have to build whole app yourself though. I'd say that in month or two we'll get a binary.
You can track Linux porting progress in this issue
Anybody got a nix flake though?
How did Zed get so much publicity? Do they happen to have a lot of funding or something? I've seen a million of these posts and I'm just really uninterested, as does a big portion of comments I see.
I'll be watching this one. It looks nice. Please come to Linux. I do loves me my vim. I did not like setting it up as much as I thought I would to be an IDE. I'm sorry I was mean Zed.
Yes, that was mean, because nobody is able to make another editor as powerful as vim.
Time will tell for sure, but helix is looking really good and once they have support for plugins I'm rather sure it will be a very, very powerful editor.
I don't think helix will ever catch up to a lot of vims lesser know features of which there are a lot. I think that's by design as well, I think that helix wants to have a smaller surface area than vim and for a lot of people that will be the right choice. I personaly use ex-commands for example, or the quickfixlist fairly often so for me I have a hard time imagining helix not feeling like a step down power-wise (as nice as multiple cursors are).
VSCode has way more features than Vim. Including the ability to run Vim inside the IDE. Or Emacs.
Sais no-one that knows vim, thou it have a vi-like mode that is missing most advanced vi-trixs.
I've been trying out Helix as of late. It's a bit different than vim, but I'm beginning to like it.
Helix's autocomplete is too bad for me to be able to like it
what do you mean? Helix uses LSP servers, usually the same ones used by Vim and VS Code.
were you using it without the LSP's installed? If you were, then you would only get completion based of the treesitter grammars, which would be very limited.
no, the autocomplete trigger is rly bad and triggers when moving the cursor around instead of when you actually type
It's a documented problem and they are working on fixing it
Ah I see. I usually only move the cursor when in command mode, so that might be why I haven't noticed it. That's unfortunately an issue I've noticed in a lot of editors. In fact, because Zed is so fast, the auto completion is super obnoxious atm and constantly flashes at you while you type.
Honestly even if they had coded this to anything other than MacOS I wouldn't use it, I'm not too keen on learning a software that's developed by a team that archived their previous project, given how popular atom was when they decided to archive it it concerns they could just do the same with this one.
On the plus side, the fact they stopped Atom development has allowed our community fork of Pulsar to flourish and it has seen loads of active development over the last year. I do find it hard to blame the original team, it was clearly a Microsoft thing to make sure they put all focus on VSCode.
I’m assuming it was a MS decision
I tried it briefly. It certainly is a lot snappier than Atom ever was, I'll give it that. Seemed to be pretty good with Python, but when I opened some C++ source, it went around reformatting my indentation and replaces tabs with spaces. I will have to see if there is a way to disable all that, as I found it obnoxious.
If I wrote an IDE and detected tabs I'd just have it delete the codebase
It was more than just tab conversion. For example, it decided on its own that:
if(...) {
...
}
else {
...
}
would look better like:
if(...) {
...
} else {
...
}
I mean I guess I could live with that, but really? I imagine there's some config where you can disable all this, but it just doesn't seem worth some giant git commit every time I touch a file with the editor.
Ah I think I found it. I need to go:
{
"format_on_save": "off"
}
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.
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 | w3
I'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:
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.
And
Seems contradictory
Yup. Especially since it's written in Rust... Like why? Rust has a great cross-platform story.
they've written a custom GPU framework to achieve the performance the level of performance they have. it's currently only compatible with macos, but is being ported to other operating systems.
Why in the world wouldn't you just use Vulkan? Then it would still be portable to other platforms with probably still good performance, no?
vulkan is a graphics api, not a framework. their framework is using vulkan.
This is wrong. Their framework uses metal, which is an apple only graphics API.
My bad, I was referring to the new Linux implementation which is using Vulkan, which was not clear. The MacOS implementation only supports Metal, as MacOS does not support Vulkan natively. I assume the Vulkan implementation will also be what is used for the Windows build.
How much GPU performance do you need for text?
For sure. If 32-year-old vim can handle multi-GB files smoothly, you don't need a GPU.
I guess if you are committed to supporting a hard to support platform, may as well get it out of the way first?
But yeah, seems like a pretty poor release.
Looking forward to the memes once this dies
(Zed's dead)
Sounds cool! Too bad it's only on MacOS atm
They wrote their own GUI toolkit (oof) and it's hardware accelerated (argh), so OS portability is going to be unusually difficult unless they planned for it from the beginning. No mention of that in the article, so I doubt they did.
They already have very experimental Linux support. You have to build whole app yourself though. I'd say that in month or two we'll get a binary. You can track Linux porting progress in this issue
Anybody got a nix flake though?
How did Zed get so much publicity? Do they happen to have a lot of funding or something? I've seen a million of these posts and I'm just really uninterested, as does a big portion of comments I see.
I'll be watching this one. It looks nice. Please come to Linux. I do loves me my vim. I did not like setting it up as much as I thought I would to be an IDE. I'm sorry I was mean Zed.
Yes, that was mean, because nobody is able to make another editor as powerful as vim.
Time will tell for sure, but helix is looking really good and once they have support for plugins I'm rather sure it will be a very, very powerful editor.
I don't think helix will ever catch up to a lot of vims lesser know features of which there are a lot. I think that's by design as well, I think that helix wants to have a smaller surface area than vim and for a lot of people that will be the right choice. I personaly use ex-commands for example, or the quickfixlist fairly often so for me I have a hard time imagining helix not feeling like a step down power-wise (as nice as multiple cursors are).
VSCode has way more features than Vim. Including the ability to run Vim inside the IDE. Or Emacs.
Sais no-one that knows vim, thou it have a vi-like mode that is missing most advanced vi-trixs.
I've been trying out Helix as of late. It's a bit different than vim, but I'm beginning to like it.
Helix's autocomplete is too bad for me to be able to like it
what do you mean? Helix uses LSP servers, usually the same ones used by Vim and VS Code.
were you using it without the LSP's installed? If you were, then you would only get completion based of the treesitter grammars, which would be very limited.
no, the autocomplete trigger is rly bad and triggers when moving the cursor around instead of when you actually type It's a documented problem and they are working on fixing it
Ah I see. I usually only move the cursor when in command mode, so that might be why I haven't noticed it. That's unfortunately an issue I've noticed in a lot of editors. In fact, because Zed is so fast, the auto completion is super obnoxious atm and constantly flashes at you while you type.
Honestly even if they had coded this to anything other than MacOS I wouldn't use it, I'm not too keen on learning a software that's developed by a team that archived their previous project, given how popular atom was when they decided to archive it it concerns they could just do the same with this one.
On the plus side, the fact they stopped Atom development has allowed our community fork of Pulsar to flourish and it has seen loads of active development over the last year. I do find it hard to blame the original team, it was clearly a Microsoft thing to make sure they put all focus on VSCode.
I’m assuming it was a MS decision
I tried it briefly. It certainly is a lot snappier than Atom ever was, I'll give it that. Seemed to be pretty good with Python, but when I opened some C++ source, it went around reformatting my indentation and replaces tabs with spaces. I will have to see if there is a way to disable all that, as I found it obnoxious.
If I wrote an IDE and detected tabs I'd just have it delete the codebase
It was more than just tab conversion. For example, it decided on its own that:
would look better like:
I mean I guess I could live with that, but really? I imagine there's some config where you can disable all this, but it just doesn't seem worth some giant git commit every time I touch a file with the editor.
Ah I think I found it. I need to go:
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.
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:
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).
I'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:
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.
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.
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.