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

This is a reasonable question on the discussion of vimscript. Does it make sense to have tool-specific languages like this anymore?

I don't love lua, but moving to a "standard" scripting language has a lot of value.

And neovim proves that lua is viable, so...




Let's be realistic: If people were really concerned with some issues with Vim9Script, they could address them in nearly infinite ways. Yet they choose neovim, again, and as some standard of truth or excellence (where else is neovim a standard of excellence for anything?).

Every Vim discussion has neovim people finding ways to attack Vim. The signal is always negative which makes the signal meaningless - the source is just tuned to transmit negative.

It's a major reason I don't consider neovim. Who wants to be involved in that community, defined it seems by hating someone else's hard work - which they are giving to the public for free - and being parasites on the other's reputation. Just do your own thing, in your own way, and do something wonderful - don't worry about criticizing others. Ugh.


I have to say that I love vim, and super respect Bram and all the other contributors for everything that they have done for vim.

There just happens to be some technical choices in vim that I don't agree with / don't find appealing, where neovim happens to have made an alternate technical choice that I do agree with / find appealing. vim9script is one of them, which is highly relevant to the submission. I apologize if I came across as hating someone else's hard work.

My point isn't about being concerned about a specific issue with vim9script per say, it's vim9script itself. If Bram and a bunch of core vim devs were spending time on their _extremely_ valuable time on anything, the last thing I'd want it to be would be a vimscript offspring. That is just my opinion, and that is truly the extent of my opinion. Again, I apologize to Bram and the core devs if that came across as anything else.

I have used vim for more than 10 years now (neovim for just 2 of those years), and I expect to be using vim / neovim for the rest of my life. And having written some useful but niche plugins for vim, I felt like expressing my opinion here about the direction of vim / vimscript / vim9script wasn't unreasonable.


The only person I'm seeing here as a reactionary is you.

I love vim. I'm using neovim a fair bit now, too. How wonderful is it to be spoiled for choice?

I think it's great we have two vibrant lines of *vim development and the opportunity to learn the best lessons from each. Here, I think it's a bit of a bummer: neovim has proven lua to be pretty decent (as much as I dislike lua itself) and this would have been a decent place for vim itself to consider following.

As a result, we're going to have a plugins/scripts ecosystem that's more fragmented than it needs to be. Meh.


I haven't seen what you're saying. I've seen people addressing specific problems, and suggesting specific solutions, and I really don't understand why neovim isn't a reasonable suggestion. Maybe you can point out some of these unreasonably negative comments for me.

Neovim is literally people doing their own thing in their own way and succeeding. I don't understand your concerns or why you don't consider a solution to this problem to be viable just because it acknowledges the problem as a problem. Sounds a bit kafkaesque to me, to refuse to consider a solution because even bringing up the problem is considered too negative. How should neovim have done it? Do you think they should simply not have bothered?


I‘m neither pro nor against VIM or NeoVIM, but your comment is imo completely negative and not helpful at all.

I for one are glad for NeoVIM improving upon VIM and pointing out some weaknesses.

Since NeoVIM was released, Bram has been improving VIM much faster than before and even added features like async I/O support, that he previously rejected.


When did he reject? To my knowledge, he didn’t reject anything.




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

Search: