Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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/


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




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

Search: