Hacker News new | past | comments | ask | show | jobs | submit login

I'm curious how many users are now using vim versus neovim.

I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.




I stuck with Vim for a long time. I had friends that made the jump and honestly, around version 0.4.3, it still didn't seem to offer anything I cared about. So I stuck with my decade old .vimrc. I had started to get into CoC stuff, and NeoVim was just starting to release their native LSP integration. On a whim, I decided to give it a shot. I ended up sticking with it. Now there'd have to be a heck of a good reason for me to go back. I never enjoyed VimL. Any of the personal plugins I've written, I've had to struggle through writing. While Lua isn't the most amazing language either, I do like it far more. I feel like NeoVim's ecosystem is pushing the boundaries far more than Vim but, isn't that kinda what Vim wanted? They want to remain the conservative slow-moving text-editor. There's nothing wrong with that at all!


Neovim occasionally has really basic functionality regressions compared to vim: I switched back to preferring vim after realizing that neovim silently deletes all ACLs on a file (https://github.com/neovim/neovim/issues/1200).

However, I use Emacs and VS Code for more involved editing, and mostly use vim as a light remote editor via SSH, so my priorities may be very different.


Debian popcon can be interesting:

- https://qa.debian.org/popcon.php?package=vim

- https://qa.debian.org/popcon.php?package=neovim

- https://qa.debian.org/popcon.php?package=nano

(nano for the control group)

So lots of neovim growth, but still small in absolute numbers. Then again, vim-tiny is installed by default. Normal vim is a better indicator. And it won't grow as much, because Debian's userbase grows slowly.

Personally I'm happy with the default Vim config (I'll enable features if I need them, such as line numbers) and prefer the minimalism.

I tried neovim but there were more bells and whistles by default, and I didn't want to waste time configuring (and I work on a bunch of machines when wearing my sysadnin hat). For plugins, I only use a debugger.


For those who don't want to parse the Debian popcon graphs :

    94000 installs for vim
     4000 installs for neovim
Exact values are 94171=81618+5727+6826 for vim + vim-gtk3 + vim-nox, and 3980 for neovim. I ignored vim-tiny, which is installed by default.


I switched to NeoVim and then back to Vim a few years ago. I ran into some bug that prevented my setup from working correctly that forced me back. Vim has been working fine for me and I haven’t found the motivation or a reason to try and switch again.


It was only in the last year or so that neovim really hit its stride. Features like treesitter provide the basis for some really interesting functionally.


I use vim for a living. I need it to work. Always. Neovim in my experience hasn't been as stable, not by a longshot. Neovim adds things I don't care about (lua, lsp, treesitter) while taking away things that are essential to me (gvim, rock solid stability).

I see the neovim community holding up lua as a holy grail, rewriting entire vimrc configs just for the sake of it (even though a vimscript vimrc is much easier to read than a lua one) and rewriting rock solid existing vim plugins in lua, resulting often in a less stable and less feature complete plugin. But hey, it's now written in lua so it MUST be better!


This comment thread on the previous conversation has a lot of good replies:

https://news.ycombinator.com/item?id=31908731

A few highlights:

* "If it ain't broke, don't fix it"

* People don't like Lua (or just simply prefer VimScript)

* Divergence over time means that they are not still compatible.


> * People don't like Lua (or just simply prefer VimScript)

Lua is not my favourite language, but I'd sure take it over vimscript.


> People don't like Lua (or just simply prefer VimScript)

:shock:


I prefer VimScript over Lua. VimScript is really not that bad of a language and I think its deficiencies have been greatly exaggerated, and Vim9Script fixed most of the oddities that were in there (e.g. '1' == 1 and such, JS/PHP-style).

Lua, on the other hand, won't give me an error if I mistype a variable name, and the ecosystem doesn't really have good static analysis tools to catch these kind of silly errors. There's some other things I don't like either, like how "arrays" are really just hashmaps, as well as some other things. The whole versioning story wrt. compatibility is also annoying (it's basically a Python 2/3 story with every single Lua version).

It's not Lua is horrible, but the fawning over it from some Neovim people is something I always found curious, like it's a fantastic brilliant language. Meh, I found it quite average overall, at best. And if I look at some Lua vimrcs or plugins then it's all a lot more verbose and awkward than VimScript.

Not that VimScript is perfect by any means, but overall I find it's quite a decent DSL for an editor.


Fair, though neovim uses LuaJIT which is maintaining Lua 5.1 compatibility indefinitely; with their own set of extensions[1].

Through the use of metatables you can improve the undeclared global situation[2], through I admit it's kludgy.

We use luacheck for static analysis, but I'll admit it's far from perfect. The language doesn't lend itself well to static analysis.

I think what lua mostly has is a really good embedding story. It's a tiny C library with broad compatibility and a permissive license; and with LuaJIT it's also very fast (though less portable). This means it's used everywhere and a lot of people are at least passingly familiar with it. Vimscript on the other hand is fairly alien.

[1] https://luajit.org/extensions.html

[2] https://github.com/CorsixTH/CorsixTH/blob/master/CorsixTH/Lu...


I feel the same way. Legacy vimscript certainly had some warts but vim9script has been much nicer IME than lua. Elsewhere I've likened vim9script to typescript 1.0. It has just enough types to be useful but not enough to let you go down a rabbit hole. That's sort of the sweet spot when scripting another application.


> Lua, on the other hand, won't give me an error if I mistype a variable name,

Lua has pretty good lsp server and it gives me good warnings and completions.


I prefer vimscript when scripting vim.


> People don't like Lua

Who doesn't like Lua? That is right up there next to disliking kittens and puppies...


Arrays start at 1?


Just like in math, and Lua doesn't do manual memory management so aligning stuff with memory addresses is not needed.

They're both valid options and it's just about preference.


> Just like in math

I might be wrong, but I think math favors different starting indices based on the subject matter. I've seen Analysis textbooks favor 0 as the starting index. I don't think there's a clear argument for cultural transference from math.

I'm opposed to starting index from 1 because I think departure from very mainstream programming tradition should have a strong reason beyond preference, even if the de facto tradition appears equally capricious.


There are good reasons for zero-based indexing outside of pointer arithmetics: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/E...


It's a well-known argument. It's also widely recognized as highly subjective, starting with the notion that upper bound must be exclusive.


Indexing starts at 1 in math mostly because in history, people were afraid of 0, and it's hard to change conventions.


Debatable. It makes sense to say "the first element", regardless of mathematical connotations. We've had this kind of expression in almost every language across the world long before we invented multiplication.

Saying the "the zeroth element" is just... weird and slightly nonsensical.


Yes, because language developed at a time where people didn't know about zero.


Zero still would most likely wooldn't make sense. Zero is nothing, it can't be anything. Even ordinally.

1 is something and it fits very well for the first position... outside of programming :-)


In 1-based indexing, the index of an item is the number of items you've already seen, including the one you're looking at.

In 0-based indexing, the index of an item is the number of items you've already seen, excluding the one you're looking at.


I agree that is very weird at first. But after building a toy project including about 5,000 lines of Lua, I can say I got used to it fairly quickly. Most of the time, I was accessing arrays via iterators anyway, so I had to deal with indices very rarely.

Aesthetically, it is repulsive, but when actually writing code in Lua, it was not much of a problem. I felt much stronger about "do"/"then" and "end" versus curly braces for delimiting blocks.


Array index starts at 1

~= instead of !=

# instead of len()

Default declaration to global

-- for comments

Dereferencing something that doesn't exist returns nil


Debian switched back from Neovim to Vim as the default “vim” in Buster(?), so I switched back along with it.


Do you have any details on that? I tried looking at default packages and containers for each version but those are probably too slimmed down. I assume you mean installed by default when you pick a "desktop install".

Really surprised to see /Debian/ of all things pick Neovim, especially years ago when it was even newer, as a default over Vim and would love to see the discussion around it. It would have been ~v0.2 for Stretch and ~0.3 for Buster, and only a year old during Jesse.


It turns out I mixed this up with Mutt vs. NeoMutt, so please disregard.


I've tried Neovim a few times but kept getting discouraged by things like pane navigation being different and the replacement for netrw seemingly not being able to be configured to have similar keybindings. Last time it was something to do with :term or :vertterm.


I switched over to neovim a few years ago and haven't looked back. The embedded language server is awesome.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: