Hacker News Reader

Comment by mikl | Hacker News Reader

Shame that Bram is doubling down with vim9script. This will give vimscript a Python 3 moment, splitting an already small community into even smaller pieces.

I wish he’d have embraced Lua like Neovim. It has already been proven to work great (half my plugins are Lua these days, and it performs great), but alas, it was not to be.

View on HN

> This will give vimscript a Python 3 moment

Not really; the Python 3 problems were due to incompatibilities in the APIs (e.g. functions returning str previously now returning bytes) that couldn't be automatically converted, not merely due to "being incompatible".

You can safely mix VimScript and Vim9Script; you can even use both in the same file. It's not a problem. I wish people would stop using "Python 3!" on any incompatible change; the details on what is incompatible really do matter.

> I wish he’d have embraced Lua like Neovim

Vim has supported Lua since 2010, and Lua doesn't exactly have the best story on compatibility by the way.

This is all correct. To quote from the official description of vim9script:

    Vim9 script and legacy Vim script can be mixed.  There is no requirement to
    rewrite old scripts, they keep working as before.  You may want to use a few
    :def functions for code that needs to be fast.

So entirely the opposite of the python3 split.

Since Vim has been Bram’s project for decades, I have some empathy for him to want to continue doing things his way and to not compromise on that. It may have taken Neovim to convince him that certain features are important, but that doesn’t mean he has to like how those are realized in Neovim. Open source is freedom, and I believe it’s okay for him to make use of his freedom to design things in his way, even if the dichotomy with Neovim is not optimal for the community. And maybe it’s not worse than (say) having both GCC and Clang.

I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor.

My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).

> The official neovim repo still has twice as much vimscript code as it has lua code

Much of that is "just" the runtime files (things that define language syntax, etc), which are x-compatible (broadly) between nvim and vim. Seems it would be foolhardy to just re-write all that in lua, "just because".

https://github.com/neovim/neovim/search?l=vim-script&p=1

Last time I touched lua support on neovim it really was not as easy as i hoped as an api. As compared to let’s say eMacs lisp.

I agree that making a new custom scripting language wasn’t the best move, but the release notes deal with backwards compatibility concerns (and calls out Python specifically as a lesson learned).

There is a Lua interface:

https://vimhelp.org/if_lua.txt.html#Lua

Reply on news.ycombinator.com