Hacker News Reader

Comment by funklute | Hacker News Reader

> IMO, any application for editing/powerusers with a plugin system should be using Python exclusively.

While I agree that python is often a good (or even the best) choice, I think the neovim team made a solid argument for lua (easier than C, faster than python).

Would you have chosen python for neovim, and if so, how would you have avoided excessive startup times? (keeping in mind that a terminal-based editor gets started many times throughout the day, as opposed to a GUI editor which you might only start once at the beginning of the day)

EDIT: btw, I wholeheartedly agree about the plugin system. Even with neovim, it's pretty confusing that many plugins are now available in original vimscript versions, or new lua versions. I tend to go with the lua versions, simply because I don't want the mental overhead of understanding two different plugin languages, in cases where I decide to fork and alter the plugin code.

View on HN

I actually have a mild distaste for Lua after spending about a month and a half using LiteXL (https://lite-xl.com/), which is an editor written entirely in Lua. The thing is a spaghetti mess, with a lot of plugins relying in internal implementation details of core features, and some of them even making changes to the core and other plugins. (but to be fair, that's mostly an issue with the design of LiteXL and not Lua)

The thing I don't like about Lua is that it doesn't really offer much. It's a programming language with practically zero features. Projects end up doing things, like inventing their own class system just to do OOP, and that becomes a problem for interop between projects. Performance is good, but there are other options with good performance. Although I will admit that coroutines are a killer feature of Lua that I wish more languages had.

For the use-case of neovim, idk. I stopped using vim as a main editor many years ago, but I do know what you mean about the concern with startup times. However, I don't think anyone can say Python's startup times are too slow without actual data to back that up. On my machine (with Python 3.10), a simple hello world runs instantly. I'm too lazy to do a proper measurement, but it's nowhere near what I would consider slow.

And idk what neovims plugin ecosystem looks like, but if Python's startup times were a real issue, I don't think I would mind having a persistent daemon to reduce the problem, especially if it means better plugins.

> And idk what neovims plugin ecosystem looks like, but if Python's startup times were a real issue, I don't think I would mind having a persistent daemon to reduce the problem, especially if it means better plugins.

That's a very good point!

> The thing I don't like about Lua is that it doesn't really offer much. It's a programming language with practically zero features. Projects end up doing things, like inventing their own class system just to do OOP, and that becomes a problem for interop between projects.

I personally see Lua's minimalism as one of its strengths and one of the reasons it's great for plugin systems. OOP is doable if you need it, but really unnecessary anyway.

> how would you have avoided excessive startup times?

I don't think it's a problem? kitty terminal is programmed half in Python and is fast.

Python has a huge standard library full of useful general-purpose stuff. The motto "Batteries Included" might sound a bit boring at this point, but it's as true as ever.

I wasn't disputing that though. However, because of the batteries included, it has significantly more overhead than lua.

I don't think the breadth of the standard library necessarily affects startup time. You only pay the cost for a module when someone imports it, surely.

Yes, true - I didn't word that very well. I believe lua is faster than python mostly due to the simplicity of the language implementation itself, but as another comment pointed out, it might not actually be that big a difference (and I don't have any hard numbers at hand).

Reply on news.ycombinator.com