6 ms·

s/continuation/hard fork/ Neovim is a hard fork, not a continuation. Vim is still being developed by Bram and other contributors, and has a lot of the same fun

s/continuation/hard fork/ Neovim is a hard fork, not a continuation. Vim is still being developed by Bram and other contributors, and has a lot of the same functionality now with different API surfaces. Questionable choices by both development groups (but, IMO, mostly from the initial arrogance of the neovim developers) are increasing the gap to the point where, in a couple of years, I do not expect there to be meaningful compatibility between them. A lot of people don’t like Vimscript, but I personally find the Lua integrations which neovim has to be harder to use because the language isn’t built around the editor, it requires bridging, and there’s a definite impedance mismatch involved. For me, without an equivalent of `gvim`/`MacVim`, neovim is a non-starter. The OS-level integration is important, and none of the various neovim GUIs that exist are nearly as good as the original `gvim` for X or Windows or MacVim for macOS.

israrkhan 4y ago
I find lots of arguments about who was actually more arrogant. But lets look at it from objective perspective. Looking at neovim[1] vs vim[2] contribution Bram is top contributor for vim. 16,211 commit right now. Second top most contributor has 194 commits only. Neovim top contributor has 2285 commits, followed by 21,66 commits for second. It looks to me that neovim is more open to community contribution. Then look at commit graph over period of time. It looks like Neovim is more actively developed. There development activity level around vim also increased in 2016. Perhaps that was the time when bram realized that he need to do more with vim, to compete with neovim. I myself was a longtime vim user, who switched to neovim 2 years ago, and am happy with it. [1] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors [2] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors
kurtreed 4y ago
What did you find arrogant about the neovim developers?
- halostatue 4y ago
  Pretty much everything, including the ongoing lie that Neovim is a "continuation" of Vim. I replied in a different comment (https://news.ycombinator.com/item?id=33922783 https://news.ycombinator.com/item?id=33922783) about the async patches, which is where the whole things started. Because the patches weren’t accepted as is, they hard forked. That requires an incredible amount of arrogance. Neovim is not better than Vim. It is (increasingly) different. They have made different choices, some of which are interesting, some of which are baffling, and most of which are just different, although I consider the removal of GUI support to be about as arrogant as the gemini protocol stuff. There is a pernicious strain of software developer that thinks that they know better on everything and that GUIs are bad. I felt that way in 1992 or so, despite having been exposed in 1990 to X, because it was easy to pick on Windows 3.1 and (then) Mac users. I got over it because there are things which are better, easier, and faster with GUIs than without. Not everything needs a GUI, but if you want people to use your software, leaving it in the terminal is unlikely to be a long-term success strategy.
  - soperj 4y ago
    > Because the patches weren’t accepted as is, they hard forked. They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?
    - halostatue 4y ago
      You’re right. They weren’t going to be accepted, because they didn’t work the way that Bram thought they should and the people who pushed them would not change them to fit Bram’s goals. As package maintainer myself, if I get a PR/patchset the implements something in a way with which I disagree, I will not accept the changes. If I don’t care enough about the changes, then I probably won’t implement them either. Or I might do so later when I have time. On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.
- Beltalowda 4y ago
  Things have calmed down a bit now, but there were quite a lot of harsh words coming from some Neovim developers aimed at Vim and Bram personally which really turned me off; things like "lazy" and such. You can disagree on a technical level without being an asshole about it.
shmerl 4y ago
I'm glad for neovim addressing issues that vim ignored for years. The fact that vim picked some of those features is competitive pressure.
sodapopcan 4y ago
Hard agree on lua v. viml. Viml really isn't that bad. I'm certainly not claiming it doesn't have its warts and shouldn't keep improving, but it's a DSL for a text editor... And as you point out, you still need to know a bunch of viml that you have to wrap in Lua calls. At the same time, I haven't actually given vim scripting in Lua a fair shot, so I'd be happy if anyone could shed some light on why they might think it's better.
wirrbel 4y ago
> but, IMO, mostly from the initial arrogance of the neovim developers Vim really was in a sad state prior to the fork which turned out to be a wake up call to Bram it seems.

israrkhan 4y ago

I find lots of arguments about who was actually more arrogant. But lets look at it from objective perspective. Looking at neovim[1] vs vim[2] contribution Bram is top contributor for vim. 16,211 commit right now. Second top most contributor has 194 commits only. Neovim top contributor has 2285 commits, followed by 21,66 commits for second. It looks to me that neovim is more open to community contribution. Then look at commit graph over period of time. It looks like Neovim is more actively developed. There development activity level around vim also increased in 2016. Perhaps that was the time when bram realized that he need to do more with vim, to compete with neovim. I myself was a longtime vim user, who switched to neovim 2 years ago, and am happy with it. [1] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors [2] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors

kurtreed 4y ago

What did you find arrogant about the neovim developers?

halostatue 4y ago
Pretty much everything, including the ongoing lie that Neovim is a "continuation" of Vim. I replied in a different comment (https://news.ycombinator.com/item?id=33922783 https://news.ycombinator.com/item?id=33922783) about the async patches, which is where the whole things started. Because the patches weren’t accepted as is, they hard forked. That requires an incredible amount of arrogance. Neovim is not better than Vim. It is (increasingly) different. They have made different choices, some of which are interesting, some of which are baffling, and most of which are just different, although I consider the removal of GUI support to be about as arrogant as the gemini protocol stuff. There is a pernicious strain of software developer that thinks that they know better on everything and that GUIs are bad. I felt that way in 1992 or so, despite having been exposed in 1990 to X, because it was easy to pick on Windows 3.1 and (then) Mac users. I got over it because there are things which are better, easier, and faster with GUIs than without. Not everything needs a GUI, but if you want people to use your software, leaving it in the terminal is unlikely to be a long-term success strategy.
- soperj 4y ago
  > Because the patches weren’t accepted as is, they hard forked. They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?
  - halostatue 4y ago
    You’re right. They weren’t going to be accepted, because they didn’t work the way that Bram thought they should and the people who pushed them would not change them to fit Bram’s goals. As package maintainer myself, if I get a PR/patchset the implements something in a way with which I disagree, I will not accept the changes. If I don’t care enough about the changes, then I probably won’t implement them either. Or I might do so later when I have time. On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.
Beltalowda 4y ago
Things have calmed down a bit now, but there were quite a lot of harsh words coming from some Neovim developers aimed at Vim and Bram personally which really turned me off; things like "lazy" and such. You can disagree on a technical level without being an asshole about it.

shmerl 4y ago

I'm glad for neovim addressing issues that vim ignored for years. The fact that vim picked some of those features is competitive pressure.

sodapopcan 4y ago

Hard agree on lua v. viml. Viml really isn't that bad. I'm certainly not claiming it doesn't have its warts and shouldn't keep improving, but it's a DSL for a text editor... And as you point out, you still need to know a bunch of viml that you have to wrap in Lua calls. At the same time, I haven't actually given vim scripting in Lua a fair shot, so I'd be happy if anyone could shed some light on why they might think it's better.

wirrbel 4y ago

> but, IMO, mostly from the initial arrogance of the neovim developers Vim really was in a sad state prior to the fork which turned out to be a wake up call to Bram it seems.