Hacker News Reader

Comment by SPBS | Hacker News Reader

I use nvim in the terminal and gvim/macvim on the desktop. I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins (vimscript plugins are better because they work with both vim and neovim). Switching to init.lua also means losing all compatibility with vim, and I cannot fathom why people would want to do that considering that there is nothing that init.vim cannot already do.

I also don't like how there looks to be an upcoming split in the plugin community when Vimscript 9 releases and the neovim community will ignore it while plugin authors in the vim camp (e.g tpope) may start moving their plugins over to it.

That said, the built-in LSP for nvim is very good thing and I plan to migrate away from the node-dependent coc.nvim once nvim 0.5 releases.

View on HN

> vimscript plugins are better because they work with both vim and neovim

I think you mean "vimscript plugins are better for plugin adoption because they work with both vim and neovim".

From the language-design, performance, documentation, robustness/general codebase quality, and total number of users perspectives, Lua is overwhelmingly better than vimscript.

> I cannot fathom why people would want to do that considering that there is nothing that init.vim cannot already do

Ahh, yes, the Turing-equivalence fallacy: "technology A is theoretically capable of doing everything that B does, therefore they're equivalent". Brainfuck and Python are Turing-equivalent, and yet nobody would seriously argue that they're interchangeable.

Design matters.

Well, yes. Vimscript plugins will see better adoption. Lua matters for compute-heavy plugins.

> Ahh, yes, the Turing-equivalence fallacy: "technology A is theoretically capable of doing everything that B does, therefore they're equivalent".

Language design is not the full picture. init.lua is essentially a thinly-veiled init.vim with lua syntax. You will have to learn init.vim either way. It is extra work to do something in init.lua, and in using it you remove any chances of it ever working with an installation of vim (e.g. vim still has the best GUI options out there).

> From the language-design, performance, documentation, robustness/general codebase quality, and total number of users perspectives, Lua is overwhelmingly better than vimscript.

Even if ahead of Vimscript; from the language-design, performance, documentation and total number of users perspectives Lua sucks very very much.

> I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins (vimscript plugins are better because they work with both vim and neovim)

How many decades do we continue to use, support and maintain a terrible DSL like vimscript? I personally don't want to be using vimscript in 2030.

It's time to move on. Lua is a solid choice

The thing is, Vimscript sucks. Using a more mainstream language would be great for a modern advanced editor.

Vim has a ton of Vimscript plugins but I wonder how long it will take the Neovim community to replicate most of their functionality in Lua. I'd guess that not that long.

I spent 10 hours learning enough vimscript to make a command to check if a line is commented, comment it if not, or uncomment if it is, be able to handle multiple filetype and comment chars, and be able to handle proper indentation and multi-line selection.

I have to imagine it would be simpler in other languages. Vimscript is hard.

Out of curiosity, does your's have any benefits over NERDCommenter?

I'm sure mine's strictly worse. It was written when I was working in an environment where it was easier to spend 10 hours on something than it was to get permission / access to download vim plugins from the internet.

Gov?

government contractor, yeah. It is insane how much effort there is put into getting butts in chairs for the right number of hours and how little effort goes to actually building something useful.

Now that calls for story time.

I’m pretty sure that the primary reason we don’t have more VIM plugins, despite many more emacs users, is vimscript being terrible.

If vim had a more usable scripting language it would have easily surpassed emacs in plugins and more importantly, since plugins would have been more popular, vim would have been developed in a way to make it more extensible and nvim wouldn’t even be needed.

The philosophy of vim is to be able to do a lot without the need for complex plugins, as opposed to emacs' world view. That's why vim script is good only for simple scripting tasks.

I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself. After all, emacs lisp is not the best language in the world and only a small group really knows it beyond the basics.

> emacs lisp is not the best language in the world

Emacs-lisp is a Lisp. It may not be the best of Lisps, but even a bad Lisp can be far more powerful than many other non-lispy languages. To understand what makes Emacs so awesome, one has to understand the philosophy of Lisp. Emacs Lisp is not just a text editor, IDE, email client, project management tool, scientific calculator, etc.

Emacs, first and foremost is a Lisp environment. Definitely not the most ideal, but certainly the best one we have today.

> I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself

I believe, Emacs held the crown of "the most malleable" tool for over forty years, specifically because it builds on top of Lisp.

Number of plugins is not an indicator. They also have to "play nicely" with each other. I just checked - I pull over four hundred Emacs packages in my config, including built-ins and dependency libs. I just cannot imagine any other IDE or text editor with 400 plugins installed. That's just not possible.

Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs. It is the other way around: it was Emacs that created Emacs lisp. Initially, emacs was created on top of TECO, arguably the worst, most difficult programmable editor ever created. TECO language was so bad that they decided to switch. But emacs, the editor, was successful even running on top of a terrible language that nobody liked at the time.

> Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs

Early Emacs and the modern GNU/Emacs I think, are two distinct worlds.

I believe Lisp has shaped Emacs into its modern form. I just can't imagine the possibility of building something like Org-mode, with the same level of extensibility and flexibility in any other language that is not a Lisp.

I bet if you ask any serious Emacsen - authors and maintainers of Magit, CIDER, or any other serious Emacs package if they could replicate their work, for example, in Python. I have no doubts, they'd definitely say: "that's nearly impossible"

Funny, because Magit has been ported to Vim, I use it daily.

Magit is not just a user interface. It's also a number of emacs-lisp packages useful on their own. It's Transient that's gaining popularity for building modal key UIs in Emacs. It's Forge that paved the road for nice packages like github.com/anticomputer/gh-notify. It is Org-mode integration and many other things. What you're using is a ported subset of them.

So much better, because what I want is to interact with git, not to manage a hodge podge of libraries.

There are always multiple paths to get something done. Some people prefer automation. Having "a bucket of bolts and nuts" makes it possible to hack your way around things.

Some people like Ferrari. For some - the utilitarian value of it, is minimal. They'd rather have "a bucket of bolts and nuts" instead. They can't go camping in a Ferrari. They can't take their bullmastiff to a vet in it. They can't help a friend to move furniture.

Emacs is that - it's not akin to a shiny, expensive but not very useful car. It's like a transformer - you can build a pickup truck, a camper, an ambulance, or a race car.

But some people like Ferrari. And that's totally fine.

I think you are correct. I think this is why certain Vim "demigods" have arisen (aka tpope). Only a few take the time to learn VimScript. In my humble opinion, when I took the time to try and learn it a while back, I ascertained that it was not worth my time.

Having never written a line of Lua in my life, on the other hand, I was able to pick it up in exponentially less time than the small bit of VimScript that I "know". Lua is not a fantastic language, but it is infinitely better than VimScript.

There is a point when it doesn't make any difference if the language sucks or not. What matters is if it is capable. You can say the same about most successful languages: C sucks, shell script sucks, eLisp sucks, LaTeX sucks, but they're all there and will continue to be because they have been capable of support the communities for which they were designed.

Now, you can freely dream about the perfect extension language for UNIX, or vi, or TeX, or emacs, but it won't make any difference because nobody will move from something that works to an unproven extension language just because some people (usually the minority) feel that it is a more comfortable language for them.

> Now, you can freely dream about the perfect extension language for UNIX, or vi, or TeX, or emacs, but it won't make any difference because nobody will move from something that works to an unproven extension language just because some people (usually the minority) feel that it is a more comfortable language for them.

Lua ia an extremely powerful and popular extension language. It probably has at least 10x the users that Vimscript has.

And people willingly choose Lua. Barely anyone chooses Vimscript, they're generally forced to use it.

If anything, Vimscript is the <<unproven>> extension language. It's in Vim because Bram made it the Vim language, but it was never voted on or designed. Vimscript will most likely die with Vim, because I'm quite convinced that outside of trolling attempts, no one will adopt it for another app ;-)

> Vimscript will most likely die with Vim

Which is just fine! Vimscript was created to create simple vim scripts, not to build full programs.

And if you need to do more than Vimscript can do, Vim already provides this: it has native bindings to Lua, among other languages. If Lua was such in demand to write vim scripts, at this point it should have taken over VimScript as the main extension language, but it hasn't, and I guess that unless something huge happens in the community, it won't.

> The thing is, Vimscript sucks. Using a more mainstream language would be great for a modern advanced editor.

Lua sucks, too, and it's hardly mainstream.

As someone who maintains a vimscript plugin... HAHAHAHAHAHAHA

There's API differences between vim8 and neovim that make it a pain to do certain tasks on both (UI manipulation or anything with asynchronous work). Supporting both in the same plugin is annoying. The split is already there and it's only going to get worse, so might as well go with a language that doesn't suck to write. I think upstream vim is the one needing to catch up. Vimscript sucks to write and maintain.

> I also don't like how there looks to be an upcoming split in the plugin community when Vimscript 9 releases and the neovim community will ignore it while plugin authors in the vim camp (e.g tpope) may start moving their plugins over to it.

Honestly Vimscript 9 always felt like a serious case of "not invented here". Bram could have easily chosen one of many existing languages, but instead decided to take Vimscript and make it even more bizarre (this was even more so the case at first as IIRC block delimiters for example were really odd).

Setting that aside, you could also argue that people moving their Vimscript plugins over to Vimscript 9 is a problem on their end because it makes the plugins incompatible with NeoVim. In other words, the argument is basically silly.

Vimscript is terrible though. I switched from Emacs to Vim (and later, neovim) last year and the shock of going from elisp to vimscript was intense.

I even contributed some small patches to a couple of vim plugins which meant writing and debugging vimscript, I hated every second of it.

I'm not a huge fan of Lua either mind you, but I'll take it any day of the week over vimscript.

I've always wanted to write Vim plugins, and as soon as 0.5 hits stable, I'm looking forward to trying! I won't touch VimScript with a 10-foot pole, and I write code for a living. It's not worth my time, and it does not commute to other things that I'd rather be spending my time coding.

But you can use Python to write Vim and NeoVim plugins already. It's arguably an even better language than Lua.

This is demonstrably and unequivocally untrue. Lua is designed to be fast, lightweight, and easy to use as an embedded scripting language. Python is a general-purpose kitchen sink language. Python is 10x bigger, and 10x slower than Lua. It is bad fit for an embedded language.

I don't have experience with Vimscript, but I know both Lua and Python. It seems that the biggest benefit is gained by stepping up from Vimscript to any of those two. Switching to the other would only have diminishing returns, if at all.

Apart from that, Lua was explicitly designed to be embedded. Python is designed as a scripting language that can bind to C code, and embedding seems to be an afterthought.

> I'm not a huge fan of Lua either mind you

If you liked emacs-lisp, perhaps you should try Fennel. It's a tiny Lisp that compiles to Lua with zero overhead.

It's pretty dope.

Oh, that sounds interesting, thanks for the tip!

How many people realistically are willing to write vimscript plugins, vs how many people realistically are willing to write Lua? I know personally, after wresting with vimscript for a couple of days I'd never touch it again, but Lua is nice.

New vimscript plugins are created constantly. So that isn't a good argument metric.

In a vacuum where there was no need for legacy vim support (lets say vim integrated lua), I can't imagine anyone but a small minority preferring vimscript over lua. My argument isn't that nobody programs vimscript, it's that hardly anyone does it by choice.

Personally I found the quirks of vimscript interesting when I wrote my first and only plugin: https://github.com/nburns/vim-auto-light-dark

somehow being part of the ~50 year lineage of vi editors and scripting was fun to think about

> I don't like how the nvim community seems to be throwing themselves wholeheartedly into lua and lua-only plugins

The transition to lua can't come soon enough, imho. The biggest downside to vim is vimscript. Lua is a delightful little language and the sooner it replaces vimscript the better.

There is no other credible alternative to betting on lua.

vim script is too limited and there are no other options, really.

Python plugins are a hassle.

Replacing init.vim with init.lua is, imo, a mistake. Lua is not a config language. I'd sooner use bash. Once you start writing functions tho lua feels more sane.

I recommend checking out gui frontends for nvim on desktop. I've been using neovide[1] for a while now and it's decent. I also found out that you can use nvim as a backend with the vscode-vim plugin which will load your nvim config and scripts.

[1] https://github.com/Kethku/neovide

Reply on news.ycombinator.com