Live data from Hacker News

We Have to Start Over: From Atom to Zed

zed.dev

51–60 of 243 posts

Re: We Have to Start Over: From Atom to Zed

#51

Great interview! Love how much thought is being put into what you “gold-plate”. I’ve always felt that my best work comes around on round two (or three or four…). Curious what you are planning for the ability to script the configuration? I haven’t played with zed much yet; is it possible today? Would something like Neon [1] help bridge the gap from VSCode and old Atom users? [1]: https://github.com/neon-bindings/neon

> This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable. The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.

- Brooks, Mythical Man Month

It is always interesting to see v2. I have witnessed cases where they are catastrophic due to feature overload but also cases where they are phenomenal because they are streamlined and lean.

I also wonder, with all the tooling available now at least in the space of web apps, if this quote notion of danger applies as much to v1s as I have seen v1s remarkably bloated these days. I often have to purposefully seek out tools that do less.

Re: We Have to Start Over: From Atom to Zed

#52

I used Zed for a while. The biggest performance improvements I noticed, compared to VS Code, were in start-up times and the opening of files. Sure, Zed feels snappy in those areas, but I feel VS Code is simply not that bad speed-wise when it comes to everyday coding. Especially, in the era of M1 Macs. Zed may win the battle in the longer term, but I feel slow performance has to truly annoy the fuck out of the user to…

For our team, VS Code is reaching that point. The Macbooks can’t keep up with VS Code’s decay.

Unfortunately Zed lacks good defaults (like a way to change tabs without the mouse) and certain vs code features like snippets. Makes it difficult to transition a team which has been dependent on Vscode and which has absolutely no interest in spending our days configuring tools

Re: We Have to Start Over: From Atom to Zed

#53

I tried out the editor because of this post: it looks very promising. Unfortunately I can't use it because it doesn't have support for remote hosts/devcontiners. That feature of VScode is critical to my workflow, as I don't actually want to program on a Mac host, but rather use my Mac as a portal to the VMs and containers I actually code on. It massively helps with segmentation of my projects and improves my security…

I love this about VSCode. I wish Pycharm could easily do this without sending the code away for processing.

Re: We Have to Start Over: From Atom to Zed

#54
post #10

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.

> 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.

Re: We Have to Start Over: From Atom to Zed

#55
There was an editor I forgot the name might of been Omnivim, which was coded in ReasonML, but compiled natively to a UI, and supported VS Code plugins, which is still wild to me.

Anyway, development kind of died off on it, it had insane potential in my eyes.

Hopefully Zed can achieve a similar feat (more likely targetting VS Code plugins?) or some other rich plugin ecosystem.

Re: We Have to Start Over: From Atom to Zed

#56
post #10

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.

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.

Re: We Have to Start Over: From Atom to Zed

#57
post #10

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.

> 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…

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.

Re: We Have to Start Over: From Atom to Zed

#58

There was an editor I forgot the name might of been Omnivim, which was coded in ReasonML, but compiled natively to a UI, and supported VS Code plugins, which is still wild to me. Anyway, development kind of died off on it, it had insane potential in my eyes. Hopefully Zed can achieve a similar feat (more likely targetting VS Code plugins?) or some other rich plugin ecosystem.

It was onivim2. Iirc it was a one-man show, and stopped when funding dried up. I also hoped to see a a lot from it. Maybe the dev took too much work on his plate, with an unproven language with limited libraries?

https://github.com/onivim/oni2

Re: We Have to Start Over: From Atom to Zed

#60
post #23

Fantastic interview where you really get into the mind and mindset of the developers for how they approach development from many different angles. Highly recommended. I only have one disagreement with them. . . > the perfect name for a text editor in Zig is already taken: Zed No, it’s “Zag”. ;)

> I only have one disagreement with them. . .

> > the perfect name for a text editor in Zig is already taken: Zed

> No, it’s “Zag”. ;)

Except that `zed` contains `ed`, precursor to `ex`, `vi`, and `edlin` yet still around:

`ed` is a line editor for Unix and Unix-like operating systems. It was one of the first parts of the Unix operating system that was developed, in August 1969. It remains part of the POSIX and Open Group standards for Unix-based operating systems, alongside the more sophisticated full-screen editor `vi`.

https://en.wikipedia.org/wiki/Ed_(text_editor)

While `ag` (the silver searcher) is fantastic, Zed's more about editing code than searching code:

https://geoff.greer.fm/ag/

Post reply on HN