Ask HN: Vim or Neovim? | Hacker News Reader

Ask HN: Vim or Neovim?

9 pointsendorphine29 comments

Which one should I choose and why? Any reasons to prefer one over the other?

A bit of history for those who missed it.

Neovim was forked in revolt, because Bram, being a BDFL, was reluctant to “async” scripting, afair. Then in version 9 (or was it 8.x?) it still landed and neovim lost its main reason to exist. Talks about merging back were talked for a while. Now it’s functionally just a fork with different everything. I wouldn’t expect better software quality than vim, projects like vim are on another level.

Personally (opinion ahead), I find Vim a proven classic and neovim feels like yet another github project with a never-ending backlog for bells and whistles. Watching youtube videos on how it works with all these rainbow unicorn plugins makes me want to close it immediately. They made exactly that vim that Bram has foreseen and didn’t want it to evolve into, because it falls into the uncanny valley between an editor and an IDE. I believe vim mailing list should still have his message with concerns about that.

Agreed. The async had been all that I was missing. Sticking with vim.

Neovim - modern and well maintained flavor, great dev team behind it, healthy plugin ecosystem, many great features you won't find in vim. Plus everything vim has to offer.

I regularly switch back and forth between the two. I maintain a cross-compatible .vimrc to make those switches simple. I don't even alias, preferring to use either `vim` or `nvim` as appropriate. As a caveat, I generally don't turn it into an IDE. I like a more vanilla experience, and using TMUX to lean on the shell for most typical IDE functions.

If I could state a preference between the two:

Vanilla VIM: Installed on every server I touch, always available, works well even without configuration.

NeoVIM: Slightly better for mixed Clojure/ClojureScript projects (with Conjure plugin) that I'm often working on.

They're the same, just ecosystems. I "grew up" on vim, and I've used nvim in recent times, and there's no substantial difference imo. Mainly it's how they get setup, not how they get used.

Emacs, on the other hand...

Just kidding, I would never use that foul operating system.

> They're the same, just ecosystems.

I'm a long time vim user. I watched someone use neovim, started drooling over the plugins they were using and decided to give it a go. As I understood it neovim was born because Moolenaar didn't want to give up on vim's scripting language. It something you might like to replace. I don't know why he was so attached to it. When neovim made LUA it's scripting language it gave rise to all these plugins, which is what I was drooling over.

Within about 15 minutes of using neovim I hit my first bug. Split screen diff's weren't rendering correctly. In fact they rendered so badly it was impossible to use. Then I hit a few more. That reminded me of one thing I am in awe of in Moolenaar. Vim is a big piece of software, yet I don't ever recall hitting one bug in the underlying engine. He was one mother of a programmer, truly a giant among us.

I owe that guy about 2 million keystrokes.

And he owes you a brand new escape key cap :)

What’s even worse, nvimers seems to ignore bugs that are impossible to miss. The first time I installed neovim, it:

  - couldn’t re-'columns' itself on window resize
  - couldn’t be used as an explorer’s “open with” action (due to nvim-qt/nvim argument forwarding nonsense)
  - another outstanding bug/non-feature that I don’t remember now, but it was just stupid.

Okay, I thought, give it some time. I gave it some time every two years since 2018-ish. Guess what.

And tbh, Lua, really? I mean, it’s better than vimscript, but having such opportunity and choosing Lua is just… no words. It wasn’t even unclear future, the whole point of neovim was making IDE out of it. This is a “typed lang with a rich ecosystem” class of task, not “embedded scripting with no batteries and barely working pm”. I bet that people who actually write plugins wish it was typescript or python multiple times a day.

Lua is the correct choice. It’s not perfect, but there’s nothing better than it.

It’s the fastest scripting language and it’s easy to embed it into the application.

The ‘batteries’ can be found in `:h lua.txt`, they’ve grown significantly each release, and you can even use a package manager.

It's easy to start embedding it. Once you get to metatabled userdata with shared-upvalue methods and registry refs, you wish it was just python.

The ‘batteries’ can be found in `:h lua.txt`

https://neovim.io/doc/user/lua.html

Reinventing iteration, vim.NIL, empty dict, utf-8, etc. Sorry for the snark, but I'm not surprised in the slightest and have no other emotion for that. They could have that and a whole world of packages and tools out of the box by using virtually any language except Lua.

do you have any other language in mind that can be embedded into the editor like lua? i remember that sublime text had python, but i don’t remember anything relevant from then.

What do you mean by like Lua?

Most scripting languages are embeddable. lang.exe and /usr/bin/lang are just cli frontends to lang dlls and do baseline embedding like `exit(luaL_dofile(L, argv[1]))`, which is one of Lua’s selling points until you start actually binding it to your runtime and this simplicity drowns in necessity of reinvention.

I’ve embedded Perl, Python, Lua in real projects. Didn’t touch Node.js, but pretty sure it embeds as well as long as you’re happy to deal with C++. Judging by the experience with C++ modules for node, it’s not that bad, but not that trivial either. Python, js, ts are all fine candidates with massive mature ecosystems.

Technically, all you do in embedding is: set up the interpreter, define some modules (or globals), these modules export objects or functions which are implemented in C via embedding API. Then you run scripts from strings or files. These scripts use these modules, e.g. vim .get_tab(3) .get_cur_window() .set(“filetype”, “sh”), or you can add metatable/class sugar on top of it. Nothing unique to Lua there.

Lua is small (44k), much simpler and easier to consume than python, supports multithreading, and much faster too if you consider luajit. I don't know when the neovim project adopted lua, but python got a jit this year.

The lua-users[1] website has some (rather outdated) comparisons.

[1]: http://lua-users.org/wiki/LuaComparison

It’s simpler until you need basic functionality, then it’s immediately too simple, as the link above shows. People want dicts, arrays with nil, text buffers and so on.

Multithreading in Lua is done through locking every index access (e.g. `print(t.a.b)` does four locks). It’s not that multithreading everyone wants and it is off by default behind a compile-time flag. This index-locking approach is trivial and only serves a few specific use cases. Neovim doesn’t seem to use it (because locking every “.” sucks). https://stackoverflow.com/questions/3010974/purpose-of-lua-l...

As for JIT, you have to spin few thousand times in the same loop before it kicks in. It doesn’t just magically speed things up, as it has a very noticeable upfront cost. I think it’s arguable whether this load pattern exists in a usual editor-plugin setting, maybe yes, if you e.g. implement a whole langserver in Lua. But in general, interpreter speed doesn’t matter at all for what is mostly glue code. Neovim doesn’t have its text management core written in Lua to make it matter here.

Also note that Lua is fast because its design choices allow that. Once you ignore these choices, it’s slow again. For example __newindex fires only once. To make an “active object” which always fires newindex, you proxy it via {} and it becomes pythonic. Strings are always interned, so if you work with long strings, you’re constantly recalculating hashes and trashing the heap. So you need a userdata with a buffer with a metatable and everything. Plugin code is naturally “highly embedded”, so JIT stumbles upon embedding API and stops making difference due to “exits”. It’s a very thin line to walk along even if you want that performance.

A hotloop in luajit has 56 iterations. http://luajit.org/running.html

Idk when was this, but i use nvim on the terminal and it is fine, feels faster than vim, even.

And vim has bugs too, I have a list of nags that just aren’t going to be fixed on vim that were fixed on neovim.

Imho both are just fine.

Neovim.

* "Modern" codebase. * General purpose scripting language (Lua, instead of Vimscript, which is a DSL). * Greater (and mostly maintained) extension ecosystem.

Vim is nice on ssh'd servers.

Trying neovim has been on my TODO list for a while, but I never had an actual reason for it. What's better about it that will make me want to switch? I don't care about the fact that internally it's Lua instead of Vimscript: I'm not writing code in either. All that I can see is that I'm going to adapt to the differences, which is a downside.

I just use Vim. No reason to get Neovim when it's effectively the same for my usecase, just with extra steps. Vim is already installed anywhere and feels super light.

If I wanted a fancy editor, I would just use VSCode (which I do). Vim is best for lightweight and simple uses imo, plus ssh.

fwiw, VSCode has annssh mode to edit and run remotely and even inside a dev/docker container

NeoVim, if only because lua > vimscript.

Start with Vim if these are the only two options. Vim is more battle tested and has seen more days.

ed, man. man ed!

Awww... it's TECO for the win!

  iHello World
  $ewhello.txt$ex$$

  C:\teco>type hello.txt
  Hello World!
  
  C:\teco>

https://github.com/mikewarot/teco

went from vim -> nvim -> VSCode + vim extension

I get to keep my motions and modes, get better support for normal IDE features, and a bunch of extras like being able to view images, pdfs, markdown

Neither. Stick with VScode unless you have a lot of free time and nothing better to do. Otherwise neovim if you're entering the ecosystem from scratch

Vim does it all and well!

for the functions I use with vi, don't feel the differences, LOL

Reply on news.ycombinator.com