Neovim has a reputation for being the editor you adopt when you want to spend a week configuring your editor instead of working. That reputation was fair in 2021. In 2026, it's partially fair — the onboarding cost is real but it's bounded in a way it wasn't before.
I switched eighteen months ago. I'm writing this after running it on three production projects. Here's what's actually true.
What Changed
The lazy.nvim plugin manager and the proliferation of distribution configs (LazyVim, AstroNvim, NvChad) changed the initial setup story significantly. You can have a working, LSP-enabled, treesitter-powered Neovim configuration in about an hour if you start from one of these. This is a meaningful improvement over "write your init.vim from scratch."
The LSP integration, powered by nvim-lspconfig, is the other major change. Language server support that used to require careful manual setup is now largely automatic. TypeScript, Python, Go, and Rust all work well out of the box.
The Actual Onboarding Tax
Here's the honest version: one week to be functional, one month to be comfortable, three months to genuinely prefer it. That's what I experienced and what matches the reports of people I've talked to who switched in the last year.
"Functional" means you can edit code without the editor fighting you. "Comfortable" means you've stopped looking up common keybindings. "Genuinely prefer it" means the modal editing model has become the thing that feels wrong when you're forced to use something else.
If you leave before month three, you'll probably leave with a negative impression. Most people who switch and abandon do so in weeks two or three, which is the hardest part of the curve.
What's Still Rough
Debugging. The DAP (Debug Adapter Protocol) integration has improved but it's still more friction than VS Code's built-in debugger for most languages. For Python and TypeScript debugging I occasionally still reach for VS Code. This is the clearest remaining gap.
Initial project setup with multiple language servers sometimes requires manual intervention. The automation is good but not perfect. You will, at some point, need to read documentation for something that isn't working.
Why It's Worth It
The speed argument is real but overstated in online discussions. Yes, it's fast. The more important thing is that the editing model — modal, keyboard-driven, composable — scales with task complexity in a way that mouse-driven editing doesn't.
Refactoring a function using composed motions is faster than equivalent mouse operations, not because of raw speed but because the operations are composable and memorable. You build a vocabulary of editing operations, and that vocabulary compounds.
After eighteen months, I don't think about the editor. That's the actual endpoint. The week-one friction is real; the month-eighteen invisibility is also real.