3 ms·

I see a lot of hate on Lua here. Anecdotal but I never wrote any plugins in vimscript. Since moving to Lua a week ago i’ve already written one, and will continu

I see a lot of hate on Lua here. Anecdotal but I never wrote any plugins in vimscript. Since moving to Lua a week ago i’ve already written one, and will continue to where I find a use case. Vimscript sucks, using Lua will make it easier for people to contribute I think.

tjdevries 5y ago
That's great to hear :) As you write more plugins, make sure to submit ideas to Neovim core about how to make Lua even easier and/or more integrated!
isatty 5y ago
People generally dislike change. I don’t think it’s about _lua_, anything new would receive the same treatment.
hajile 5y ago
I agree that vim script needs replacement, but I don't know that Lua was the correct answer. It's not a super-popular language and makes some things harder than necessary. Base 1 arrays means you are almost certain to bake in bugs accidentally. Meta tables are even worse though. They result in many subtly different object systems. Maybe that's not as bad in a unified project, but it's the path to a fractured ecosystem. The builtin string library is very barebones which isn't a great place to be in a text editor. Finally, the "regex" match function is hyper limited. I'd argue that either Python or JavaScript would be better.
- jmiskovic 5y ago
  1-based indexing is boring subject, you just get used to it like you did with 0-based indexing. FORTRAN and Matlab also use it and Julia apparently supports both. The OOP through meta tables is bit more interesting discussion. Meta tables also enable other dispatching mechanisms, if you want to get fancy. In my case I find it makes me reach for OOP less often, which in turn reduces code complexity. I agree that it's frustrating when different libs are each using own OOP implementation. It doesn't matter too much because all those implementations are light and don't pollute the code base. Fractured ecosystem is both good and bad thing. The string handling is kind of a pain point, especially if you are spoiled by Python. I have no idea how Neovim + Lua handle Unicode text? Python is huge & complex language, as well as 10x slower than Lua. JS has more rough edges due to historical baggage, also a fast VM would be much much harder to integrate than Lua. I'd say they would both be worse choices for maintainability and Neovim usability.
  - hajile 5y ago
    1-based indexing matters if you only code Lua occasionally (as you say, you get used to it when coding it all the time). JS has better string builtins than Python IMO. QuickJS is made for embedding and has similar performance to Lua (slightly slower). I don't think you'd want to embed a large VM like v8 anyway. https://sabotage-linux.neocities.org/blog/9/ https://sabotage-linux.neocities.org/blog/9/
    - jmiskovic 5y ago
      I didn't know about QuickJS, last time I checked Duktape was most suitable for these cases. I see QuickJS was made by Fabrice Bellard himself. While linked benchmark is impressive for QuickJS, in case of Neovim they chose to embed LuaJIT which is ~10x faster than "official" PUC Lua. I see your point though, QuickJS would still be a good choice. JS and Lua are not that different once you set aside syntax differences. http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html

tjdevries 5y ago

That's great to hear :) As you write more plugins, make sure to submit ideas to Neovim core about how to make Lua even easier and/or more integrated!

isatty 5y ago

People generally dislike change. I don’t think it’s about _lua_, anything new would receive the same treatment.

hajile 5y ago

I agree that vim script needs replacement, but I don't know that Lua was the correct answer. It's not a super-popular language and makes some things harder than necessary. Base 1 arrays means you are almost certain to bake in bugs accidentally. Meta tables are even worse though. They result in many subtly different object systems. Maybe that's not as bad in a unified project, but it's the path to a fractured ecosystem. The builtin string library is very barebones which isn't a great place to be in a text editor. Finally, the "regex" match function is hyper limited. I'd argue that either Python or JavaScript would be better.

jmiskovic 5y ago
1-based indexing is boring subject, you just get used to it like you did with 0-based indexing. FORTRAN and Matlab also use it and Julia apparently supports both. The OOP through meta tables is bit more interesting discussion. Meta tables also enable other dispatching mechanisms, if you want to get fancy. In my case I find it makes me reach for OOP less often, which in turn reduces code complexity. I agree that it's frustrating when different libs are each using own OOP implementation. It doesn't matter too much because all those implementations are light and don't pollute the code base. Fractured ecosystem is both good and bad thing. The string handling is kind of a pain point, especially if you are spoiled by Python. I have no idea how Neovim + Lua handle Unicode text? Python is huge & complex language, as well as 10x slower than Lua. JS has more rough edges due to historical baggage, also a fast VM would be much much harder to integrate than Lua. I'd say they would both be worse choices for maintainability and Neovim usability.
- hajile 5y ago
  1-based indexing matters if you only code Lua occasionally (as you say, you get used to it when coding it all the time). JS has better string builtins than Python IMO. QuickJS is made for embedding and has similar performance to Lua (slightly slower). I don't think you'd want to embed a large VM like v8 anyway. https://sabotage-linux.neocities.org/blog/9/ https://sabotage-linux.neocities.org/blog/9/
  - jmiskovic 5y ago
    I didn't know about QuickJS, last time I checked Duktape was most suitable for these cases. I see QuickJS was made by Fabrice Bellard himself. While linked benchmark is impressive for QuickJS, in case of Neovim they chose to embed LuaJIT which is ~10x faster than "official" PUC Lua. I see your point though, QuickJS would still be a good choice. JS and Lua are not that different once you set aside syntax differences. http://luajit.org/performance_x86.html http://luajit.org/performance_x86.html