Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There’s no future to Vim without Bram. A merge of the two fork’s isn’t what Bram has wanted, but it’s the best way to keep Vim alive


No future for Vim without Bram? People said the same thing about Apple when Steve Jobs passed away. Turns out, as long as you have loyal users and competent people working, things can keep on chugging right along.

It seems a bit ridiculous to dismiss reunification when you don't even know what kind of compromises might be made to make it happen.


I would not be so prompt to compare the situation with Apple and Jobs. Apple is a company that provides something no one else does while also holding a lock on its users. You can't go and install iOS apps on android.

On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim. I would not be very optimistic for the future of vim considering that nobody uses vim9script and that alone is quite the massive baggage to maintain, an entirely separate, new programming language? one that is used by.. no one? 99% of extension developers either use the old vimscript or lua, and neovim's lua base has significantly grown to the point where we can imagine a future that has no vimscript.

Where will they find people willing to continue working on vim's code base when it has this kind of really big, really useless baggage? and if they were to cut it out of the code base, would it still be vim? I respect Bram for his contribution to open source, and vim is one of my favorite, most used software, but his decisions in the past few years have been extremely poor and were not friendly toward the possibility of vim being community maintained.


> On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim.

They are quite different at this point and personally I prefer vim over neovim. I've never gotten NeoVim to work satisfactorily. I've had issues with the async setup where the backend and frontend start having issues with each other or lag. So on. Personally I find vim to be a lot simpler to work with and MacVim in particular to just be a perfect GUI for me.

Of course YMMV. The point being is that there are a many of us that prefer normal Vim over the NeoVim work. That's okay. Its also okay that others prefer NeoVim over Vim. There is nothing wrong with that. What there is something wrong with is the way that many NeoVim people are reacting to this.


You've hit the nail on the head for me. From my point of view, vim is simpler than neovim. I value that and wouldn't like to see neovim subsume it (although I'm sure people are happy with neovim for very good reasons)


Where will they find people willing to continue working on vim's code base

the same place where neovim found its developers. if one group of people can organize themselves to maintain and develop their version of vim. so can another. i don't know how many contributors vim has, but i am sure they can figure out how to move forward. finding new leadership can be difficult when there is no clear candidate, but if the contributors had not wanted to work on vim they would not have been there in the first place.


>i don't know how many contributors vim has, but i am sure they can figure out how to move forward.

Bram, for 98% of the commits/lines, plus some statistical noise.


i didn't realize that. given this and what others say about how bram treated contributions, i'd think it's best to put the original vim into maintenance mode and keep it as the version that bram intended. there is no need for another group of developers to emerge if it wasn't already there when they most likely would just end up repeating what neovim already did, since none of them would be a replacement to do things the "bram" way, especially considering that bram apparently was reimplementing many neovim features anyways.

it feels to me that not changing vim would be what bram would have wanted. any new developments may as well happen in neovim.

of course anyone who disagrees or doesn't like where neovim is heading may fork vim and make their own version of it.


>No future for Vim without Bram? People said the same thing about Apple when Steve Jobs passed away.

Well, they were making a wrong prediction, but also a totally unrelated to the Vim/Bram situation comparison, then.

This is not the case of a huge multinational company with tens of thousands of employees, hundreds of billions in cash, hundreds of millions of users, a strong product lineup, and a strong C-level team, who has been preparing for 2 years for its CEO eventual demise, complete with another person taking his CEO role way before that happened.

As Apple was at the time of Job's passing.

This is a FOSS software project, strongly associated and mostly solely written almost predominantly by a single person [1], with another fork that has a vibrant community and more modern features.

So, to keep the relevant parts of a comparison, this is an multi-person entity fully prepared for the demise of its leader, with people ready to take over, and stocked to the brims with the essential fuel to continue it's operation (cash), vs an entity that was essentially an one-man-show, with no preparations for the next day, and with a quite popular alternative ready to take over.

[1] Bram has 16,515 commits, the next biggest contributor has 68 times less commits. Or, 1/50th lines added. And it goes downhill from there, with the rest of the contributors added together being 1/50th Bram's contribution as well.


Time will tell, but I think vim is likely to fade away with slow development pace. People are all sentimental right now, but we'll see how many of them will remain in a couple of years still committing to vim daily.

Looking at the commit history, vim was largely a one-man show, I'm a bit skeptical about that changing basically overnight.


The commit history does not accurately reflect the contributions to the code-base. As I understand it, contributors would write and provide patches to Bram who would then commit the changes to the code-base.


Why would anyone amend the author in an open source project?


From what I can tell the reason is that that’s the way it was always done. As I understand it, back in the days before there were distributed version control systems, Bram was the only one who could commit to the code-base so he would credit the actual author of a submitted patch in the commit message. He continued this practice after the Vim project moved to Mercurial (and Git).

Related discussion: https://github.com/vim/vim/issues/1554


On reflection, it might have been clearer to have started my comment with:

“Taken at face value by most modern users of Git, the commit history does not accurately reflect the contributions to the code-base”.


Ah, thanks


I wouldn't be so dismissive.

Vim is a marquee project, tons of hackers will want to contribute because it's cool or because they want to have that name on their CV.


> tons of hackers will want to contribute because it's cool

It's one thing to contribute a couple of PRs/patches, a very different thing to spend a large part of your free time on the project for years (which is what Bram did to make vim what it is).

These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it.


> These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it.

Those same contributors that remained on vim instead of neovim didn't put much effort into vim9 ecosystem either. I can't imagine them being willing to maintain all of vim's baggage when literally nobody writes vim9script. Classic vimmers tend to stick to the old vimscript.

As you said, contributing a few patches to classic vim is one thing, but becoming an actual maintainer of the behemoth that comes with a ton of useless baggage is a whole another thing. Maintaining a programming language no one uses.. sisyphus would be proud.


Pretty much this. I'd like to take a crack at updating that vim.org page away from PHP5/MySQL.


None of that is even remotely true.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: