Had a look at the About page, and the live coding feature does sound useful. I'm sure the guys are excited; it's a fun project. You get to write algorithms, optimise performance, and do GPU programming. But who needs another text editor that will probably never reach feature parity with Vim and a terminal multiplexer.
I would guess most developers do not use vim. Pretending that vim is the universally loved editor that every developer has agreed upon using seems pretty disconnected from the real world.
VS Code came up out of nowhere pretty recently, and is used by a lot of people, so that shows that there is (or was, but still post-vim) opportunity for a new editor. Whether Zed is able to gain momentum to cater for the long-tail that other developers do remains to be seen, but I'm pretty keen to see more products trying to compete for users.
I found a SO poll from 2021 result listing percentages of respondents IDEs [0]. There's overlap, so developers can use more than one, but Visual Studio Code is at 71%, Visual Studio at 33%, Notepad++ at 30% and vim in in 5th place at 24% (IntelliJ is at 29%).
VSCode came out of nowhere and took the market share previously held by Atom and Sublime Text 2
The folks I know who use Emacs or vim (including me) are by and large still using those tools since before Atom and Sublime got popular. We just have LSP, now, like VSCode does.
And VSCode came about mostly from Microsoft's push. They wanted an "in" for non Microsoft languages, and VSCode gave them that, as well as a Microsoft-provided environment for dotNet on Linux / Mac. This meant that JavaScript / Node developers could still be folded into Microsoft tooling (telemetry) without forcing them into the crushing heaviness of Visual Studio on Windows.
It was a really slick play. Still, it was an overall positive for the profession, and you can still use VSCodium without the telemetry.
I moved from vim to vscode. The main driver was an easier time writing extensions.
I've tried to switch to neovim twice since and gave up. Lua is nice and I did get into that the first time. Crashing and errors were rife though. The second time, which was very recently, it seemed like everything had changed again, all completely new plugins etc. And I struggled to do some basic stuff, I guess I've just forgotten the more in-depth file/window management. So it goes.
I'm primarily developing Elixir and Javascript and a few years ago I switched from Emacs/Spacemacs to VS Code. What pushed me over the edge were projects like VSpaceCode (basically replicating Spacemacs keybinding and menu system) and edamagit (replicating Magit). I've tried Zed and I'm quite optimistic about it, but so far not willing to put the work in to replicate enough of my setup.
I feel like these classic editors are good to know just for general education like writing cursive. If you end up on some barebones system you will know how to edit a config file and exit. But for day-to-day it's all IDEs nowadays.
The line between "IDE" and "text editor" has blurred to the point where I'm not sure they're super useful terms anymore. When I used vim up till about 2019, I had it configured with all the toys to the point where it wasn't all that far off of where my VSCode setup is today.
Also, you know, insert Emacs joke here assuming if you still have enough RAM to post, etc.
It's even blurrier when you realize how many people are using LSP. Emacs with elgot is literally just a different UI in front of the same IDE tooling as VSCode.
The editor wars are over and everyone won because of separation of concerns. Yay!
I don’t believe there’s a useful distinction, at least for more advanced editors. For instance, I’m not aware of anything you can do in, say, PyCharm that you can’t do in Emacs or Vim. I don’t mean that in a curmudgeonly way like “nothing I care about, because we don’t need those fancy features to write a pageful of Fortran on my 1997 laptop”. I mean, I don’t know of a single feature of any kind that doesn’t exist on essentially all modern editors.
In emacs your repeat commands are C-u <number> <other command>. Your selection would be C-space C-s func M-b.
M-b causes it to go back to the beginning of the word and search ends, you can still adjust the selection with other movements. It's not as tight as V?<regex> but it's still composable.
Or you use evil mode and get those vi-style bindings in the editor.
EDIT: Actually, playing around with your `V?` command doesn't it select that entire line rather than to that pattern? So the emacs equivalent would actually be: C-space C-M-s ^func C-e
Well, ok. I’m specifically talking about what might count as an IDE feature. Vim and Emacs can run in a terminal, but that’s not a defining characteristic of an IDR. More like, everything can do interactive debugging, and syntax highlighting, and code completion, edit-time error flagging, etc. etc.
Parent seemed to believe that it's a waste to write another editor/IDE because vim already exists. Prevalence of other more popular editors disagrees with that.
In my opinion I wish more editors would become a face to Neovim which can run in a headless mode, allowing you to not have to emulate VIM at all, but take full advantage of it and all its plugins. It still kills me JetBrians chooses to maintain what VIM users call an awful plugin that simulates VIM, when they could just implement a Neovim front-end natively into their IDE, giving them the edge of "we fully support Neovim and all it brings" which is a much bigger selling point than, we have a VIM-like plugin.
I did not know this. My google/brace/ddg foo is failing me. Do you have a link to the full reference on how one would use headless neovim to provide a full headless vim with a GUI wrapped around it?
I'm thinking it would be nice if my Lazarus IDE supported Vim commands.
> But who needs another text editor that will probably never reach feature parity with Vim and a terminal multiplexer.
Feature parity with Vim is not meaningful in my opinion. LSP evened the playing field enough for all editors to the point where you can daily drive anything and be no less productive than most.
Use whatever you like and helps you get the job done. That includes Vim too, but I'm getting sick and tired of people acting like using Vim is some kind of irreplaceable boon. Becoming a better thinker will make you an exponentially better programmer than any tool.
Vim is just an example. My point was that code at the end of the day is just text, and there's only so many features you need to be able to write/compile/edit efficiently in 99.9% of the cases. Any new power tools for text editing will end up taking more time to learn and remember than be of use.
I'm not so sure. The fact that were editing the code as text and not as mutations and annotations on its syntax tree has always struck me as a sign that we're still in the stone ages when it comes to expressing ourselves precisely to a computer.
The basic model of computation is the turing maching, and it’s a symbol manipulating one. So editing text is at the core of what computing is. You could go a step higher to edit tokens and that’s what VIM does, albeit imperfectly due to tokens not being a finite set.
I'm not sure what you mean by "tokens not being a finite set". I suppose there's the theoretical issue of token length being potentially unbounded, but whatever problems your editor has with that, your lexer will likely also have. For any finite length file, there is a finite number of tokens, and once you parse it, you've got a much smaller list of symbols plus a convenient address for each one. I don't think it's a practical issue.
Vim's understanding of tokens makes some reasonable assumptions, but unless you've configured the textobjects plugin to talk to a properly configured language server, you're working on vim's presumed tokenization and not a tokenization that's native to whatever the underlying language is. Helix tries to bundle this in by default, but it still doesn't feel like a first class citizen.
As for turning machines, not since the 80's have the tokens that appear in our editors been the tokens that are manipulated by our processors. There are typically a myriad of bytecode translations or compiler optimizations or parser hijinks between what you're editing and what you're running. It's the AST that matters to the code author, and the AST is a tree, not a string.
We need to get to the point where you can directly annotate on a function parameter:
> this function is slow when this parameter is > 100
...such that the annotation sticks to that parameter, however the viewer has chosen to render the text.
The best we can do at present is to sprinkle some text nearby leave the problem of deciding which parameter and which function are referenced an exercise for the reader. This then necessitates that we preserve the way the text appears, which prevents us from presenting it differently based on the view context (e.g. maybe the reader prefers different units, timezones, or a language which flows their text differently than the author).
> you're working on vim's presumed tokenization and not a tokenization that's native to whatever the underlying language is.
LSP can be the foundation to a paradigm of code editing instead of text editing. I want the kind of integration we have with Smalltalk IDE like Pharo and the SLIME plugin for Common Lisp and Emacs.
> It's the AST that matters to the code author, and the AST is a tree, not a string.
I'd take variable inspection (not sure it's the real term) before AST manipulation. More often than not, I'm more worried about the result of data processing than the processing itself. Such capability exists in live programming, such as the system itself. And I believe this kind of rapid feedback is a much better experience.
If you're using languages that are themselves closer to the syntax tree, then you're part of the way there. Lisps do that. Editor features for most lisps typically include manipulation of syntax-tree-level features like moving forms around. (Emacs comes to mind here.)
I can't think of a nice way to express what I think of vim, but I think your general point is apt.
Some pretty full-featured editors already exist that people are happy with or, perhaps, have at least gotten used to. Where does a new editor fit in?
It's neat that it's "multiplayer" but that's an edge case.
I'm also not convinced by the business model. Do people really want channels, calls and chat integrated with their code editor? Personally, I have an almost visceral negative reaction to the idea but maybe that's just me.
This might be one of those things like monitor refresh rate where you can only really tell the difference if you've experienced the better version for a while, but I haven't ever felt slowed down by the speed of VS Code.
I do think it's something like that. Things can quickly get to the speed that feels "fast enough" that they don't feel subjectively slow, but can still be sped up by a couple orders of magnitude. If you Ctrl-F something and it takes a few hundred ms, you probably don't feel like it was slow, but in reality the "speed-of-light" for this operation was probably orders of magnitude faster than it happened on your device. Once you experience something close to the theoretical speed, it's really hard to go back to something you thought was perfectly fine before. And you start noticing that everything feels slower than it "should"..
I think of something like grep, where if I tried to grep a large hierarchy it'd be really slow and I'd sorta reason to myself "well yeah it's a lot of files in a large tree, of course it'll be slow!". Then I installed ripgrep and suddenly what I thought was a reasonable speed was shown to be unreasonably slow!
Every now and then I switch back to Apple's Terminal app, and I'm blown away at how much faster it is at just typing than iTerm it is, and how much nicer that is.
it is actually faster and snappier to use on a beefy M2 max, on the same hardware zed starts up in half the time. the difference is very noticeable. of course it is much less configurable and doesn't work with a lot of things VS Code can do easily.
> Startup would have to be terrible for me to bother.
that's just the first noticeable difference.
but there have been instances lately where opening, editing and saving the file took me less time with zed than just open it in VS Code and waiting for it to be ready for inputs
> VS Code starts in under a couple of seconds
I am talking about relative speed differences. Imagine you open the same code base and the editor is ready in half a second. going back to the "slower" one would be unbearable.
now admittedly zed is no way near to the extensibility of VS Code so it is probably doing less and that's where probably much of the speed difference comes from, but it can't really be overlooked once you experienced it.
I have. I have some huge Markdown documents I've needed to load and VSCode cannot render them without becoming super slow. In contrast, vim gets it done.
Am I wrong in thinking that "topic hidden" means this specific post, and that future posts related to Zed (such as a cross platform announcement) would still show up for them...?
Or even worse, you own a Mac (say, through work), but aren't entirely in the Apple ecosystem and don't want to relearn everything and fight muscle memory every time you switch devices.
I have (but or course Apple make it hard to do so you need third party software). But that doesn't help with special mac only software that has it's own style, like Arc or Zed.
Most people who say “all editors have vim keybindings just use that” miss the fact that bindings or not, a lot of vim’s functionality is just not available on other editors.
And that Vim is more than its keybindings, despite the often repeated jokes.
Tabs, window splits, search and countless other details may work very differently, and usually not completely with the keyboard.
I think they mean compared to cross-platform apps that feel equally weird on every system.
There’s some talk in the Mac world about “Mac-assed Mac apps”. I use BBEdit as my main editor because it feels right. The default shortcuts are like every other Mac app. You can use standard Mac tools like AppleScript to automate it. It uses the same fonts, widgets, and menu systems as everything else. It’s made for that environment and it shows in a million ways.
VSCode is a marvel of engineering and I love that it exists. It also feels uncanny-valley “off” on my Mac in ways that make my brain itch, so I don’t use it. Same with Obsidian: it’s a brilliant app, but it bugs me. It’s not bad in any way, it’s just not the right choice for me.
One of the people I admire for their programming skill works on a raspberry pi. I use my work MacBook through ssh because I prefer Sway to MacOS's window manager. We are many and varied.
