Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim 9.0

vim.org

Post reply on HN
Print view View original

261–270 of 272 posts

Re: Vim 9.0

#261

Post by fatbird »

cardanome wrote: post #226
fatbird wrote: post #76

Earlier quoted context omitted.

async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in. Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute,…

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 innovatio…

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.

Re: Vim 9.0

#262

Post by masukomi »

slgeorge wrote: post #203
kzrdude wrote: post #85

Earlier quoted context omitted.

We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.

That's pithy but a characterisation that misses many important aspects. Bram's been developing Vim for 30 years [0]. Just think about that for a second. An open source project that's been running for longer than the age of probably 50% of the readership on hackers news. It's ways of working and values have been developed over a long period of time. Vim favours being available on multiple platforms, alignment with Uni…

vim's support for legacy platforms is... IMNSHO extreme to the point of self-harm.

many of the systems it supports haven't received updates in decades and have essentially no users. The old versions work just fine on them, and require no changes because those systems aren't changing. There's no reason why _new_ versions of vim have to be held back by the need to work on ancient platforms.

Re: Vim 9.0

#263

Post by layer8 »

bongobingo1 wrote: post #135
layer8 wrote: post #96

Earlier quoted context omitted.

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…

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

Re: Vim 9.0

#264

Post by jonathf »

capableweb wrote: post #20

As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're…

That's not necessarily true.

Core maintainer of the Neovim Tjdevries is working on a compatibility layer that would allow vim9 to not only run in Neovim, but likely faster.

Source: https://github.com/tjdevries/vim9jit

Re: Vim 9.0

#265

Post by mempko »

TotempaaltJ wrote: post #187
mempko wrote: post #109

Earlier quoted context omitted.

Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.

As above[0], these are different people than the author's of neovim [0] https://news.ycombinator.com/item?id=31942444

Weird, so people who give justification for neovim and use that thread are wrong. Thanks.

Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?

Re: Vim 9.0

#266

Post by 59nadir »

californical wrote: post #173
layer8 wrote: post #89

Earlier quoted context omitted.

…by the Stackoverflow crowd.

Yeah I feel like this definitely skews the results. I’m experienced enough to nearly never use StackOverflow, and also experienced enough to want to use something robust and readily available (try to find a system that doesn’t have vim), so I stick with vim and am _incredibly_ happy with it. Add in that StackOverflow is mostly a tool used by more junior web developers, and I think you’ll see that other demographics (…

The participants of the StackOverflow survey are likely not people who end up on StackOverflow randomly when looking for answers, but are more likely to be people who answer questions or are pulled in from other communities that link to the survey in progress (language subreddits, etc.). The actual programming community skews way more towards learners than an SO survey shows.

You can see here that there are more people with 5+ years experience than less:

https://survey.stackoverflow.co/2022/#section-experience-yea...

For what it's worth I prefer NeoVim and I've programmed since 2001, I don't think experience or anything has much to do with this preference.

I also think that anyone who doesn't Google stuff (and let's be honest, you'll probably end up on a Stack Exchange sub-domain when you do) for their hobby or professional programming is likely very stagnant and probably way worse and less experienced than they ought to be, since they're probably just doing the same old stuff all the time.

P.S. It's trivial to find default installations that don't have Vim, I don't get how anyone who's installed desktop or server distros at this point can not remember being surprised about the absence of Vim and having to install either it or NeoVim. I remember it being almost a regular occurrence when setting up machines.

Re: Vim 9.0

#267

Post by kingofpandora »

imran0 wrote: post #86
deadbunny wrote: post #69

Earlier quoted context omitted.

And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.

Well, Bram is the author of the parent project, he doesn't have any obligation to make it compatible with the derivative.

Of course, there was no obligation.

But he went about it in a way that certainly looked petty.

Re: Vim 9.0

#268

Post by usrbinbash »

yrro wrote: post #259
usrbinbash wrote: post #255

Earlier quoted context omitted.

And a Perl API :-)

Indeed, and Ruby, and who knows what else... surprised nodejs hasn't been shoved in as well. :) To be honest I don't know how Brad keeps up with it all. And even has enough left over to add a new bespoke scripting language with Vim 9...

> and who knows what else

Okay, I did a quick grep through the documentation of my distros current vim installation and came up with support for Lua, MzScheme, Perl, Python, Ruby and tcl.

So yeah, there are lots of interfaces to chose from.

Re: Vim 9.0

#269

Post by besnn00 »

justaj wrote: post #220
capableweb wrote: post #20

As Vim9 comes alive, and Neovim community focuses on Lua plugins instead, it seems this release is finally the update that will put a hard branch on the two communities. Up until now, most plugins (except Lua-only ones of course) have worked in both editors, but it doesn't seem like Vim9 will be supported in Neovim, so I guess what people go with now, will decide what you might stick with in the future (unless you're…

I don't understand. Can't NeoVim simply add the Vim9 interpreter and be a drop-in replacement for users that are migrating from Vim (9.0) this way?

That would potentially make NeoVim slower, because you could have plugins that use Lua, plugins that use VimL and others that use Vim9. That means 3 runtimes which can contribute to latency.

Re: Vim 9.0

#270

Post by cardanome »

fatbird wrote: post #261
cardanome wrote: post #226

Earlier quoted context omitted.

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 innovatio…

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…

> 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.

Post reply on HN