Live data from Hacker News

Leaving Neovim for Zed

stevedylan.dev

241–250 of 331 posts

Re: Leaving Neovim for Zed

#241
post #55
post #12

I initially loved Zed. But as their focus has shifted to building Collaboration & AI features, and still haven’t yet nailed just being a good/great base editor, its become less useful to me. I still have a lot of hope for Zed. But for the time being, I’ve switched back to my old editor & IDE … and I’ll try Zed again at a much later date.

To paraphrase an old quote, "every new text editor grows until it is bloated with collaboration and AI features." Thank god we still have vim and Emacs.

I'm still happy with vim/nvim as daily work tools (also currently exploring kakoune and helix... because why not).

Think of vim/nvim setup as a one time process: a bit complicated, but once done then you are ready to go. Of course, I use text editors for... code editing. No need to turn it into an IDE or mail client or whatever.

Re: Leaving Neovim for Zed

#242

I’m going to somehow misuse this discussion to ask for the readership help about something: I don’t understand the appeal of VSCode or more exactly I don’t understand the appeal of the text editor propped with plugins to be a semi-IDE so I guess that would also include Neovim with plugins. In my career, I have used text editors including vim which I still very much enjoy and both Eclipse and IntelliJ when I used to c…

I love IntelliJ, but VS Code has much better support for frontend technologies and TypeScript.

Until you work on a front end code base that's meaningfully large

Re: Leaving Neovim for Zed

#243
post #62
post #41

Most of the negatives mentioned (fragility, bugs, plugins breaking often) are specific to neovim. It's one of the reasons why I am and will always keep using vim instead of neovim. Vim is a much more mature ecosystem, less chasing the newest "plugin du jour", my vimrc is stable, based on a few dozen plugins which are feature complete and rock solid stable.

neovim is what happens when the javascript kids decide to "improve" one of the best editors ever created. The entire Lua ecosystem standing on 50 unstable plugins that provide the entire kitchen sink, yet do not even have a 1.0 version is nightmarish. Follow any guide and either everything breaks, or you get an hodgepodge of automagic popups, stuff that autodownloads, flash messages and useless features that are comp…

Neovim is perfectly usable without installing 50 plugins.

Re: Leaving Neovim for Zed

#244

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…

> The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect. Just my person…

> Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use

And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.

> Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens!

No. It happens only because you're used to Emacs and Vim, and unused to an IDE.

> So that’s what days were like. A bunch of tiny frustrations, and a bunch of tiny successes. But they added up.

And those frustrations are rampant in the Emacs/Vim world. People pretend they are not there because of this false notion that only those two are the sign of a great programmer.

By the time I've done my coding, project-wide refactoring, and looked up half of a project's code most Emacsers/Vimers are still stuck trying to find all references with a full-text search.

There's a reason VSCode's LSP took the world by storm

Re: Leaving Neovim for Zed

#245
post #104
post #94

Earlier quoted context omitted.

I feel like using this extension is a little buggy. Especially around undo / redo actions being captured in “format on save” type actions that happen thanks to jslint or other tools.

Yes I've tried to use the neovim plugin many times - but always run into some annoying bug, usually due to an interaction with another extension or VSCode feature. It has >400k installs though so it must be working for some people.

> but always run into some annoying bug, usually due to an interaction with another extension or VSCode feature.

That has generally been my experience using VSCode, unfortunately.

Re: Leaving Neovim for Zed

#246

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…

It’s not just about typing out code even though being able to do that quickly is more valuable than you realize.

There are plenty of other areas where typing efficiently facilitates thinking about software.

- Writing clear notes and design documents helps in developing ideas.

- Writing documentation.

- Writing commit messages and issue descriptions.

- Writing emails and messages when communicating with others.

Typing efficiently is only one factor here, communicating clearly and efficiently, reading comprehension… these are also important. But typing slowly impedes development of those related skills as well.

Re: Leaving Neovim for Zed

#247
post #244

Earlier quoted context omitted.

> The average developer averages 10 lines of finished code per day. And even with a raw 10x that amount to account for variance, changes, debugging etc, you'd be at 12 lines PER HOUR. Being generous at a full 80 chars per line, you have a maximum of 1000 keypresses per hour, or an average of one every 3 seconds. Even doubling your typing speed or keyboard response time would have no discernible effect. Just my person…

> Emacs `M-x sql-connect` is much easier for me to do than to look up, in VS Code, what shortcut has been assigned to the extension I use And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for. > Each time I want to do something in the IDE I switch focus from the code to the IDE. When in Vim or Emacs, that never happens! No. It happens…

> And the knowledge of `M-x sql-connect` came to you how? In a dream? Commands in Emacs are undiscoverable unless you know what to look for.

It's one command that implements autocomplete which gives you access to the entire system.

> It happens only because you're used to Emacs and Vim,

That's my entire point! I learned the majority of Emacs and Vim commands well back in the mid-90s.

> and unused to an IDE.

Objectively not true, if you had read the entire comment.

> People pretend they are not there because of this false notion that only those two are the sign of a great programmer.

I think you have a chip on your shoulder about this. You read my post as some sort of attack on IDEs so responded with an attack of your own.

My point was about little frictions all adding up. Sure, there's a steep learning curve in learning a programmable editor, but you only climb that curve once.

It just takes much less memory to remember 4 verbs and maybe 6 nouns in Vim to perform navigation, than learning 4x6=24 shortcuts for similar functionality in Jetbrains/Eclipse/Vs/VSCode/etc.

I'm just explaining why needing to remember fewer things is the path of least resistance for me; whatever argument you are talking about involving signs of great programmers is beyond the scope of what I am saying.

Re: Leaving Neovim for Zed

#248
post #229

A lot of editors are being discussed here but I see nobody has mentioned Kate (KDE's Advanced Text Editor) [1] in the conversation yet, so I'm doing it. Kate is a very mature and capable editor, and even if I only use it on Linux I'm glad to know that it is also available on macOS and Windows. It natively supports LSP and has much, much more to offer in terms of project management, support for build system, support f…

Yes, it's a great editor. It's one of the members of "Great, but Unknown Tools" group.

I use it for mainly writing small Go programs in these days. Bigger projects are promoted to Eclipse.

Re: Leaving Neovim for Zed

#250
post #198

> I was already a keyboard maximalist from previous jobs where I learned speed = productivity I've never understood this. In over 30 years in the industry, I've not once held a job where my keyboard speed had a noticeable effect on my productivity. Even when I had to type one-handed for a month, my productivity was unchanged. The average developer averages 10 lines of finished code per day. And even with a raw 10x th…

I think typing speed is important during bursts. If you can type out a function name really quickly (autocomplete also helps of course) then you can continue your thought process with less interruption than if you were slower. > 90% of software development happens in the mind. The small amount of time spent actually writing it out seems kinda silly to optimize for. So you're saying that 10% is spent typing, which doe…

Yes, quite so, but it probably has almost nothing to do with absolute typing speed.

There’s a marginal difference between an editor where you can type quickly and one where you can only type fast.

We’re not talking about the difference between 300 wpm and 10 wpm.

I bet if you measured, you would see, at best, a marginal difference between the speed of input between editors.

Ie. The point is that, that marginal difference probably has no meaningful difference in your productivity.

What makes the difference is probably how it affects, for example; flow.

If your flow is interrupted by the editor hanging or waiting for some bs lang server lag, or having to update a vim plugin, you are being interrupted.

…and studies show that interruptions do have a meaningful impact on productivity.

This is why editors that let you type fast do not improve productivity for everyone. Some people get flow in other ways.

Fast typing is not a universal metric for productivity, and it’s absolutely a diminishing returns thing to optimise for.

It’s probably fair to say that if you have a moderately fast editor, going to a super fast editor makes no difference to most people.

…but going from an editor that freezes or forces you to spend your time upgrading plugins, probably does; because interruptions like that are probably universal flow destroyers.

Post reply on HN