Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me.
Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?
There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.
Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim.
This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
> You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch.
This seems more like an inexperienced developer getting frustrated with the process. I absolutely would expect that new contributors will have to go through multiple revisions before they can get anything merged.
When I started working as a junior dev my first merge request had more comments from seniors requesting changes than lines of code. It can be absolutely brutal but that something everyone needs to go through.
If he had tried for years he might have had a point but just because it took months does not mean Bram was not interested in the patch at all. Otherwise he wouldn't have suggested any fixes.
Considering what Thiago accomplished by forking Neovim, you can’t describe him as an inexperienced developer. By all accounts the cleanup alone was was a huge and very successful effort—-from 300k LOC to 170,000, huge jump in test covereage, modern build chain and code checking with Coverity. He didn’t do it alone, but he led the effort and managed it incredibly well.
Seriously, you don’t have to love Neovim, but credit where it’s due.
Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way?
There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.