The reason Vim has outlasted every other editor in my workflow is that the editing model is a language, not a set of buttons. Commands compose: an operator plus a motion, so ciw changes a word, dt) deletes up to the next paren, yi" yanks whatever sits inside the quotes. Once that grammar is in your hands you stop thinking about keystrokes and start thinking about edits, and the speed that comes from that is hard to give back once you have it. The fact that some flavor of vi sits on essentially every Unix and Linux box is the other half of why it stuck. I SSH into a server I have never seen before and Vim is already there, behaving the way it does on my own laptop, which means the muscle memory I built once keeps paying off on machines I do not control and cannot install anything on.
It starts instantly and it stays out of the way. I type vim and a file name and I am editing before a heavier tool would have finished drawing its window. It barely touches memory, which matters on the tired jump boxes and cramped containers that always end up being the thing you have to work from, and it opens files that make graphical editors stall. Tailing a multi gigabyte log to find what just blew up is a normal Tuesday, and Vim loads enough of it to be useful without falling over. It is not a flashy tool. Dependable is the word I want for it, and it has earned that over years of not letting me down at the wrong moment.
The search and replace engine is the feature I would miss most in day to day work. The full regex syntax behind :%s means a rename or a reformat across a file is one line, and ranges let me scope it to exactly the block I care about instead of the whole buffer. The global command, :g/pattern/ followed by another command, is the part people underrate. I use it to run an edit on every line that matches a pattern and leave the rest untouched, which turns a tedious manual pass into a single instruction. Macros cover the cases too irregular for a substitution: record once with q, replay with @, and a fiddly repeated change across two hundred lines is finished in a handful of keystrokes. This is the point where the editor stops being a text box and becomes a small automation tool I keep in my hands.
Diff mode is the piece that quietly justifies keeping Vim set as my git mergetool. It lines up two, three, or four versions of a file with the differences highlighted, and :diffget and :diffput move changes between them without me hand copying anything across. Resolving a merge conflict during an SSH session, on a box where no graphical merge tool exists, used to be the kind of thing that made me want to get back to my own machine first. Now it happens in place, in the same window I was already working in, with the same keys I use for everything else.
Because it needs nothing more than a text connection, Vim fits the way I actually work rather than fighting it. It runs inside tmux, survives a dropped link when the session is held open on the far end, and behaves identically whether I am at my desk or three hops deep behind a bastion on a high latency link. Remote desktop and GUI editors are miserable on a bad connection. A terminal and a keyboard are all this asks for, and on the days things are going wrong that is usually all I have to work with.
Customization is real, with the honest caveat that you are the one doing the building. My .vimrc is a single file in a git repo, so a new machine goes from a stock install to my full setup in about a minute: clone, symlink, done. The split windows (:sp and :vsp), the buffer list, the named registers, and the quickfix list for driving edits off a grep are the parts of that setup I lean on hardest, and once they are wired the way I think, the daily experience is fast and quiet. Plugins extend it further through native package loading or a manager like vim-plug, though that is a project you maintain over time rather than a store you shop in once.
The newer Vim9 scripting dialect is a genuine step up, and I say that as someone who wrote plenty of the old vimscript and never enjoyed a minute of it. Config and plugins written in it load noticeably faster and read more like a conventional language, with proper scoping and closures instead of the quirks that made the legacy version a chore to debug. And the whole thing is free and open source, with no account to create, no telemetry phoning home, and nothing nudging me toward a pro tier. The licensing even routes donations toward children's charity work, which is a pleasant thing to know about a tool I run all day. The community maintaining it now is clearly committed to keeping it alive, and that counts for something when you are building a long term habit around a piece of software. Review collected by and hosted on G2.com.
The real cost of Vim is the first few weeks, and it is steep. The modal model that makes it fast later makes it baffling at the start, and I have watched new teammates get stuck trying to do something as basic as quit the thing. There is no discovering it by clicking around, because there is almost nothing to click. What works is starting people on vimtutor, handing them a deliberately minimal config so they are not also fighting a wall of plugins, and sitting with them through the first setup so the early friction lands on someone who can answer "why did it just do that." The investment pays back well, but it is heavily front loaded and there is no honest way around that.
Out of the box, Vim is a text editor and not an IDE, and turning it into one is squarely on you. There is no built in language server support and no Tree-sitter, so the features a modern editor ships with by default, go to definition, completion that actually understands your code, rename across a project, all arrive through third party plugins. The usual routes are coc.nvim, which works well but drags in a Node runtime you then have to keep installed and updated, the Vim9 LSP plugin, or ALE, and the configuration styles between them do not line up, so moving from one to another means relearning the wiring from scratch. My standing advice to my own team is to pick one stack, put it in the shared dotfiles, and stop there, because the choice paralysis costs more than the setup does. It is still more assembly than an editor that simply includes this, and on a heavy codebase you feel that difference daily.
A papercut that bites at exactly the wrong moment is clipboard handling, which depends on how the binary was compiled. On a stripped down server build without the right flag, the system clipboard register does not work at all, so a yank stays trapped inside Vim and never reaches the OS clipboard. The first time it catches you, you are switching to your browser wondering why paste is empty. Checking the build with a quick version query tells you whether the support is even there, and installing a fuller package usually fixes it, but it is an odd inconsistency for a tool that is otherwise so reliably the same from one machine to the next.
The last thing worth naming is the direction the ecosystem is drifting. A lot of the newest plugin work is being written for the fork rather than for Vim, so some of the more experimental tooling shows up there first and lands later, or sometimes never, on the side I use. The mature plugin set still covers everything I need for actual work, and the gap is not a practical problem today, but it is a trend, and if your appetite runs toward the bleeding edge of editor tooling you will feel it pulling the other way. Review collected by and hosted on G2.com.
