HN Explorer

Ask HN: Is Vim still worth learning?

49 points by harco ↗ HN
Dear HN community,

since there are quite some comments highlighting the effectiveness of a good VIM setup and muscle memory of 10+ years, I would like to know your opinion on starting to get into it now (end of 2022).

For context: I'm a backend developer with 10+ years of experience, mostly using Java IDEs, and lately some vscode (for go, typescript, rust). I have some knowledge in vim, and can use it for basic text editing, but I still use the arrows for navigation, and found the "hjkl" navigation difficult. I'm somewhat experienced using linux and the terminal, and would be curious to dig deeper into more terminal-based workflows.

The question is: do you think it's worth the effort to learn using VIM more deeply today? The goal would be to at least be able to do the go and rust coding in vim, it doesn't need to be a full Java IDE. Bonus points for an opinion about "If yes, do you think VIM is still fine, or rather neovim? Or something fresh like helix?"

Thanks a lot!

92 comments

[ 2.4 ms ] story [ 157 ms ] thread
ggm
Previously I would have said yes but if you aren't destined for systems administration, you can install tools which suit your muscle memory and workload better. VS or atom?

40 year vi and Emacs user btw. I miss classic vi. Nvi isn't quite there and small aspects of Vim grind my gears.

ZeroGravitas
If you're using vscode there's a book about learning vim inside it that's worth a look:

https://www.barbarianmeetscoding.com/boost-your-coding-fu-wi...

Core pitch:

> You may be wondering... Ok. If Vim is so good then... Why not just use Vim instead of Vim inside Visual Studio Code?

> Great question! The truth is that setting Vim to work with a feature set similar to modern text editors is not a trivial task. Features likes code completion, code navigation, in-editor error messages, etc, although supported by Vim don't work perfectly out of the box.

> Visual Studio Code and Vim together offer a very sweet spot that balance the ease of setup and super rich development user experience of Visual Studio Code with lots of the amazing features present in Vim.

> The translation is not yet perfect though. And if you're an experienced Vim user you may find some features missing. But all in all, VSCodeVim offers a very pleasant Vim experience outside of Vim.

reginol
Yes, but only the minimum necessary to use it reasonably effectively, as a last resort if you end up on a system without any other editors.

Using it as a daily driver is a waste of time when there are much more pleasant editors to do your work in, these days.

ndsipa_pomu
For system admin work, knowing the basics of vi can be really useful when you're suddenly faced with a non-booting system, but you don't need to know much - how to exit being the classic issue. I use vi/vim for really basic editing tasks and switch to something easier for anything more involved (geany being my current choice).
msla
I came in to say this: Learn basic vi (not the extended stuff Vim added) and you'll rarely be out a text editor, even on very stripped down systems. (In my experience, only nano is more common, and that comes with a keystroke cheat sheet at the bottom of the screen while you're using it.) Learn Vim if you actually like vi and want a more featureful experience in the same basic paradigm.
ndsipa_pomu
For my sins, I've worked on an old HP-UX system back in the Before-Times and that once required knowledge of vi to get it booting - no nano on that system.

For more modern systems, you can end up in BusyBox and not have access to nano (I think you can specify that vi gets included in BusyBox).

johlits
I use the Visual Studio VIM extension and I love it when I don't have a mouse. Keyboards change layout but the QWERTY keys stay the same.
Faaak
Same here. I was an ardent vim user for 10+ years. Then I found VSCode and switched entirely to it.

However, the VIM extension allows me to keep some vim efficient shortcuts which I found are faster than not using them (i.e. I try not to use the mouse at all).

And of course, it's useful when you must ssh into a server sporadically

peterbraden
Yes definitely. Vim will be around for the rest of your career, long after VSCode or other IDE's have come and gone. Investing in tools and workflows that are properly open source, and have serious longevity has a big payoff.
rob74
Maybe... but OTOH, the IDEs that come after VSCode will still follow the UI guidelines that have been established for GUI tools during the last ~40 years, e.g. having menus where you can find out which functions are available, and then memorize the shortcuts for the functions you use most often, rather than having to learn everything "up front" before being able to become productive. I suspect one reason for the longevity of vim is the time that you have to invest in learning it...
ratg13
OTOOH, GUI tools often tie you to a specific workstation setup.

VIM is already installed everywhere you need it and does not require you to have a workstation with a GUI

kstenerud
> GUI tools often tie you to a specific workstation setup.

VS Code and Android Studio can run on all major desktop operating systems, and more cross-platform IDEs are coming out.

> VIM is already installed everywhere you need it and does not require you to have a workstation with a GUI

The chances of you having a workstation without a GUI over the past 30 years has been pretty small unless you're a sysadmin.

iso1631
> The chances of you having a workstation without a GUI over the past 30 years has been pretty small unless you're a sysadmin.

I spend a lot of time in the terminal and in vim (13 terminals open at the moment)

I don't think I've used vim on a guiless terminal for a decade. The only thing I'm on a physical server for is for installing on bare metal with no ilo - which means a 640x480 text installer, USB stick, and a keyboard to type in the IP and gateway (although Ubuntu has broken that as of this year). Once that's done the install is automatic, and then I can ssh into it a few minutes later.

10 years ago maybe I used the terminal to edit things like /etc/network/interfaces to change network settings once in a blue moon. That's hardly a full featured use of vim though.

However I do ssh into servers and edit files on those servers, and vim is on every server I connect to. I believe vscode will work transparently to do that though, editing over the ssh connection.

peterbraden
I don't think that's true. There are precious few UI guidelines that persist, and GUI design has been on the forefront of many fads. Looking at the touch-first UI of today, I have very little confidence that a GUI will look anything like it does now in 10 years.

Meanwhile, I can use vim over ssh from an iPad if I need to - my tools have come with me.

Tenoke
Yeah, switching from Sublime Text to VSCode had basically 0 adjustment period.

I'm not particularly worried about switching to the next one someday nor do I feel like I'm missing out for taking 15m longer per year for the rare server editing of files compared to if I had spent 100+ hours learning vim.

thiht
That holds on paper but I'm not sure I agree.

I've used Notepad++, Sublime Text, Atom, and Visual Studio Code. Each of these has introduced game changing improvements (ST has popularized the command palette, Atom allowed high quality, well integrated, and easy to write extensions, VSCode improved upon Atom with way better performance, brought LSP, and drastically improved the remote dev experience). They have in common that switching from one to the other is extremely easy. When VSCode dies, it's because something better has emerged, I'll just have to install the VSCode keybindings on this new editor and I'll be good to go. Because this new editor will adopt the common conventions that everyone use, unlike Vim.

I've used Vim for a year, became pretty efficient with it, but it always feels like it's playing catch-up with other editors. And the modal editing feels more like a gimmick than something really improving productivity. I sometimes open Vim to do some data cleanup, because Vim moves make it easier than writing a script. But when writing code I never think "damn, typing 3dd would be so much faster than selecting 3 lines and hitting delete"

uticus
Agree with improvements available in other editors.

But disagree with this:

> I never think "damn, typing 3dd would be so much faster than selecting 3 lines and hitting delete"

I actually do think that all the time, and get annoyed when I have to take the second or so to move away from the keyboard to find the mouse/trackpad.

Need to delete three lines, starting with line 54 at the top of your screen? 54gg 3dd

I would never reach for my mouse for that unless I had to.

flashgordon
This. Only thing is I dont even "think" about "3dd" and just do it. Great thing about VIM (and possibly emacs too) is that all the things the others improved can be brought to VIM and usually is. Writing plugins is O(1) no?
chezelenkoooo
Yeah I disagree with the shade on vim motions. I'm trying to use them everywhere and even went looking for a vim and slack integration.

In fact I believe the motions are way more universal than any particular editor's key bindings. There's plugins and extensions for vim motions in almost all editor's I've used barring some database specific UIs.

tmarice
We need an interface to translate our thoughts into the computer, and the keyboard and the mouse are a necessary evil for now. But if you chose a career of software development, you should strive to minimize the friction that interface introduces.

In my opinion, Vim/Emacs are the best way to make that interface as easy to operate as possible, since it completely removes the mouse from the equation. Along those same lines, I felt so much liberated after switching to i3, insomuch that I try to replicate the experience on MacOS, after switching over for work.

EDIT: Also, the obligatory "You don't grok vi" SO answer: https://stackoverflow.com/questions/1218390/what-is-your-mos...

johncoltrane
For context, I have been using Vim as my main driver for 12+ years, now, and I have been heavily involved with the ecosystem (patches, plugins, support, etc.) for most of that time.

Learning enough Vim for it to pay off in terms of productivity and whatnot is quite a journey. If you are committed, it might take a couple months to follow chapters 1-12 and 20-32 of the user manual, which will put you in a better position than most Vim users. If your goal is really to be able to use Vim for Go and Rust projects, then there is no way around that first step, but if you somehow don't go all the way, then what you have learned will surely come handy next time you have to use Vim so there is no loss, here.

> do you think it's worth the effort to learn using VIM more deeply today?

I did that and I really love where I am. Will it click for you? I have no idea.

> If yes, do you think VIM is still fine, or rather neovim? Or something fresh like helix?

- Vim (not VIM) has been in active development since 1991 and it is not showing signs of slowing down. It is more than fine.

- Neovim is merely a fork with different goals. At a low level, the two tend to diverge more and more but when it comes to the core user-facing stuff like Ex commands, modes, operators, motions, etc. there is practically no difference.

- Helix seems promising but it is far less ubiquitous than Vim.

Everything is worth learning, whether you have an immediate use for it or not.

snapdaddy
As an emacs user, I support this comment. I think the main point is that there is a long-term benefit to learning multi-use text editors. Yes, it is painful at first, but the dividends are repaid over time.

As for VI vs emacs - both are good. I would search YouTube for 'Top 10 VIM plugins' and 'Top 10 emacs packages' and see if either grab your attention and go with that.

realharo
What do you expect out of it?
growt
If you just want to learn the basics, you'll be faster with a "modern" editor with mouse and some basic keyboard shortcuts. But if you really master Vim, I would say it's faster and more powerful than any modern editor (and you can use it as an extension in VSCode). For me it's mostly navigating ( 213gg - takes you to line 213, $ - end of line, t) - next closing parenthesis,% jumps to opening closing parenthesis or similar when you're on it, and so on). Macro recording: qe - records macro in "e" ... do vim stuff ... q ... 10@e - execute your macro 10 times. Text substitution with regular expressions (:%s/th(i|u)s/that/g). I think it's not about "hjkl" navigation, that is a probably the tiniest improvement in speed (not lifting your fingers from the home row). But if you master the navigation part and learn how to solve more complex editing tasks with macros and regular expressions, then you'll be a lot faster than in a regular editor.
wereallterrrist
You could just use Helix instead. `hx --tutor`. It enables the functionality of a 12-hour tuned Vim, out of the box, except faster and with less crashes / weird plugin interactions.

OP mentions they're open to comments about Helix... but you do you yall. The comment isn't hyperbole, I used vim for 15 years, but again, whatever.

snarfy
Try running vimtutor.
animuchan
IMO learning Vim today is absolutely worth it. Vim is a sort of "lowest common denominator" thing in text editing, it works great for SSHing into remote machines, `docker exec` into containers, and making changes when sitting next to a coworker who uses an insufferable (or badly configured) GUI editor.

As for the second question, differences between regular vim and neovim largely don't matter for learning vim, as the bulk of the changes is behind the scenes. Some plugins will depend on a specific vim version, but your muscle memory probably won't.

julvo
Yes 100%. Using the vim bindings for VS Code and that works great. Makes working without touching the mouse really enjoyable. Also being familiar with vim is a great fallback option if you're sshed into a remote machine.
ftrobro
I found that for Go development vim is really good. I tried Sublime, Atom and VSCode for Go development on Mac, but didn't feel comfortable with how slow they were, especially when trying to dig into an SQL dump. It could take a minute for the SQL dump to load. In contrast to that, vim can load and jump to any line in a MB-sized SQL dump instantly. Another great thing about vim is that you won't need to use the mouse/touchpad, though as others have mentioned there are vim-plugins for VSCode etc if that's what you want.

Vim package suggestions:

scrooloose/nerdtree - File tree navigation. jeetsukumaran/vim-buffergator - Work in buffers instead of tabs. fatih/vim-go - Jump to definition, format, auto-import, build and jump to error lines inside vim, etc.

worldsavior
Vim is fast, in performance and in productivity. Every key has a purpose, which you can define it to whatever you want, and create your own macros.

Everything is a shortcut, which makes it very easy to navigate, replace and much more. For example, replacing is very easy in vim: you can use substitution, r key, while in other IDEs you need to go to a menu or press on some button or other but not as easy in vim. For me navigation in vim changes my productivity, in terms of getting to EOF, end of line or other. This is my personal opinion, but you might feel more comfortable with a normal IDE.

Also note that learning vim can take some time and patience is a must.

Aachen
> [I] found the "hjkl" navigation difficult

That's because you're doing it wrong! Hjkl are fallbacks to move a few characters, it has only a minor advantage over arrow keys are is probably not worth the effort of re-learning how to move a cursor.

I would not recommend learning that as your first vim move. Just stick to cursors for moving individual characters at first.

The real magic is in going back/forward words (b/w/e) without needing to reach for control at the edge of your keyboard, jumping to an exact point you need (f/F/t/T) if it has a unique character (like the ')' within 'if (uid == 0)'), moving between paragraphs ({/}), going to matching parens/braces/brackets (%), going to the next/previous word under the cursor (*/#), etc. This is what will make you faster, not the switching from arrows to hjkl.

And that's just cursor moving. For editing, things like S to replace the line or C to replace the rest of the line after the cursor, di) to cut the part within parentheses and p (paste) it elsewhere, repeating the previous action with dot, searching with n/N instead of a function key, all those things are what makes vim nicer as a text editor. One of the least-appreciated things that I also use a lot is filename completion with ctrl+xf (sysadmins, take note!).

But I don't recommend learning everything at once. If you know how to go into insert mode (i), how to leave insert mode (escape), and how to save a file, then you basically have the equivalent of a text editor, especially with mouse mode enabled (the default nowadays, I think). From there, learn one command every week. Takes 1 minute per week and you'll know more vim than 99% of developers within a year.

Or go a bit faster and try to learn one command every morning, or every second day perhaps. Try it for one month and see if you want to go back to standard editors. Odds are, you'll want the best of both worlds, start looking for vim key binding plugins in IDEs, and end up like me with missing vim after all because those keybind plugins are usually not so great ^^'

> mostly using Java IDEs, and lately some vscode (for go, typescript, rust)

Do you need intelligent autocompletion, debugging, and other such IDE features?

There are plugins that, so far as I know, can do a lot of what an IDE can do, but I have never bothered to set them up myself. It all seems hacky and niche, but others can tell you more if this is the type of things you're looking for. I am not a real developer myself but I write a lot of scripts (things small enough to keep a full understanding in my head) as well as documents (reports for pentests) in vim, and for that it is perfect.

gjulianm
> There are plugins that, so far as I know, can do a lot of what an IDE can do

I want to add that the converse is true too: there are a lot of plugins (for IDEs) that do a lot of what Vim can do. I personally use the neovim integration for VSCode and it's really nice.

Aachen
Have you used the real vim a lot in the past? More than a few days of trying it out, I mean.

Probably you replied around the same time as I edited in:

>> Try it for one month and see if you want to go back to standard editors. Odds are, you'll want the best of both worlds, start looking for vim key binding plugins in IDEs, and end up like me with missing vim after all because those keybind plugins are usually not so great

It might just be me who got too used to vim bindings by now so that the suboptimal implementations are annoying. Or maybe the vim bindings in VSCode are particularly good, I haven't tried those. (I've tried them in real visual studio in ~2015 and it was so bad that I ended up using plain visual studio instead, then went back to plain vim on linux after my C# internship.)

gjulianm
The VSCode neovim plugin is really good because under the hood it's just using neovim to manage the buffer, so everything that works on Neovim works on VSCode. It's true that some plugins are suboptimal but the VSCode one (and the one for Sublime when I used it) are really good.
lloeki
> things like S to replace the line

what is this barbaric default binding, s/S shall be bound to the indispensable vim-surround! ;)

built in text objects are already nice combined with modifiers (e.g cw, ciw, caw, cW, ciW, caW), ramping it up a little bit with argument (ca, cia, daa), surround (cs"', cs([, ci", ca", viWS<tag>, dst), and indent (vii>) is stupidly powerful.

Once the [verb][modifier]{object} pattern clicked for me my mind was hopelessly infected and I could not ever go back to non-vim editors.

To me that's the risk of learning vim: if it starts clicking for you (which it may not, as pure personal fit, not elitism) then it becomes excruciatingly annoying to edit non trivial amounts of text and not have vim.

Aachen
Most people I know (including many linux users) regard me as a vim pro relative to them, and I still have barely an idea what most of these do. Or what surround is. Might want to explain a little for the rest of us mortals ;)
tomn
Surround is a plugin which adds more text objects: https://github.com/tpope/vim-surround

cs"': change surrounding quotes, e.g. "foo" -> 'foo'

cs([: change surrounding brackets, e.g. (foo) -> [ foo ]

( cs]) would omit the spaces)

ci": change in quotes, e.g. "foo" -> "" (in insert mode between the quotes)

ca": change around quotes, e.g. x"foo"y -> xy (in insert mode between x and y

viWS<tag>: add tag around current word using visual mode, e.g. foo -> <tag>foo</tag>

dst: delete surrounding tag, e.g. <tag>foo</tag> -> foo

It's really good. I'm not familiar with argument.

lloeki
Sure. Here's a quick rundown of how it works (in my mind at least, might not be 100% technically exact):

Vim normal mode commands have something like this structure, a bit like a sentence:

    [verb][modifier]{object}
There can be a bit of implicit in this sentence, e.g [verb] and [modifier] are optional. {object} is mandatory, final, and "commits" the normal mode command without having to press something such as Return.

Let's look at some basic movements:

    w => word (== [A-Za-z0-9_]), forward lookup
    W => Word (== \S i.e not whitespace), forward lookup
    b => word, backward lookup
    B => Word, backward lookup
Without [verb] it's like the implicit [verb] of the sentence is "move", so typing just these indeed results in pure movement:

    w => move (from cursor position to) one word forward
    W => move (from cursor position to) one Word forward
    b => move (from cursor position to) one word backward
    B => move (from cursor position to) one Word backward
With a count modifier

    2w => move (from cursor position to) two words forward
    2W => move (from cursor position to) two Words forward
    2b => move (from cursor position to) two words backward
    2B => move (from cursor position to) two Words backward
With [verb], things are applied to the object. Let's look at some verbs:

    d => delete
    c => change (== "delete + enter insert mode", exit with ESC)
A repeated verb is a shortcut to mean "whole line"

    dd => delete line
    cc => replace line
    d2d => delete two lines
Back to the sentence. It's a bit like the movement implicitly defines a "text range" object: "from current cursor position to movement target". So:

    dw => delete (from cursor position to) one word forward
    dW => delete (from cursor position to) one Word forward
    db => delete (from cursor position to) word backward
    dB => delete (from cursor position to) one Word backward
The interesting part about c instead of doing d+i is that it is going to be "atomic" (end these with ESC to exit insert mode):

    cwfoo => replace (from cursor position to) one word forward with "foo"
    cWfoo => replace (from cursor position to) one Word forward with "foo"
    cbfoo => replace (from cursor position to) word backward with "foo"
    cBfoo => replace (from cursor position to) one Word backward with "foo"
Which is really cool because now you can move to another position and press . (dot) and it will repeat the last normal mode command, dynamically/semantically, like a mini macro. Combine that with search, and incremental search/apply is n to go to the next occurence and . to apply, or n again when I want to skip. Also, u for undo goes back from atomic change to atomic change.

Similar to wWbB there's "find" and "find until" (n is an optional count, defaults to 1):

    [n]f{char} => find nth occurence of character, forward lookup, after character
    [n]F{char} => find nth occurence of character, backward lookup, after character
    [n]t{char} => find nth occurence of character, forward lookup, before character
    [n]T{char} => find nth occurence of character, backward lookup, before character
So e.g some examples, combining two sentences:

    F,dt) => move back to previous comma, then delete (from cursor position to) until next parens
    t)dF, => move to last parens, then delete (from cursor position to) up to previous comma
These are useful to e.g delete arguments! e.g with the cursor somewhere inside parens here:

    foo(42, 123, 345)
Note that d...
throwaway_au_1
>it becomes excruciatingly annoying to edit non trivial amounts of text and not have vim.

I can relate to this. Writing code without Vim feels like punching in a dream. Make sure you're working in an environment where you're allowed to use such tools.. I'm currently not and it stinks.

VintageCool
If you ssh into servers then I think it is worthwhile to learn some vim.
avnigo
Worth it? Absolutely, without a doubt. Should you? Only if you find it fun, especially if you prefer the keyboard to the mouse, although you can definitely use the mouse in vim too.

I would go with neovim over vim nowadays, and if you want something more familiar that will get you up and running more quickly, try AstroNvim [0]. Later on, if you also like to tinker, you can set it all up just the way you like it.

I've heard of vim being called a PDE (personalized DE) [1], and I think that makes a lot of sense.

[0]: https://astronvim.github.io/

[1]: https://www.youtube.com/watch?v=QMVIJhC9Veg

tombh
I've always found it curious that Vim is most often associated with modal editing. I consider it to be so much more than that; highly customisable, huge plugin ecosystem, ubiquitous, lightweight and works in the terminal.

Modal editing never stuck with me, I just ended up writing more and more conventional shortcuts, so much so that I wrote my own "No Vim" mode plugin [1]. Just like VSCode and other editors have "Vim mode", so too does Vim have a "conventional mode".

So don't let modal editing be a factor in your considerations.

1. https://github.com/tombh/novim-mode

throwaway0asd
You can SSH into a remote box and open vim just using your tty.
zadwang
Vi was designed for very slow connections, maybe 300 symbols per second. As such it needed to minimize the keys needed to accomplish a task and maximize user friendliness within such constraints. Turns out that goal is still very much relevant today - although there is a learning process to learn the code book.
dmarchand90
I would start with the vim keybindgs in vscode. Even from a pure ergonomics point of view
Cloudef
Why vim? Works in terminal and over remote shell, is on 99% of machines, no need to setup and lastly fast.