3 ms·
Python is and has been a go to language for writing vim plugins. We've seen its limitations in the vim community. The same is true for Javascript and Typescript
by bern4444 4y ago
Python is and has been a go to language for writing vim plugins. We've seen its limitations in the vim community. The same is true for Javascript and Typescript (which I personally love).
NeoVim picked Lua and every Lua based plugin I've seen has been extremely impressive in its speed.
I don't love Lua - I don't know it so well and find it a little difficult to read and write - but I can't argue with the results. Python is not the right decision nor is JS.
Only other language I could see is rust given its speed, safety, and interoperability with C but Rust also has a lot of ceremony which is great but not as conducive to the plugin author community (a lot of additional overhead).
- bogwog 4y ago> Python is and has been a go to language for writing vim plugins. We've seen its limitations in the vim community. The same is true for Javascript and Typescript (which I personally love). Can you link to any example plugins that are written in either python or js/ts and are considered slow? I'm not doubting you, I'm just not a big vim user, so I'm not familiar with many plugins. > NeoVim picked Lua and every Lua based plugin I've seen has been extremely impressive in its speed. I'm sure you're impressed by the perceived speed, but I don't believe you have any real (i.e. data-backed) basis for comparison there. If you do, I'd love to see it. But to counter your anecdotal evidence with another, Sublime Text only supports Python for its plugin system, and the performance of every plugin I have ever used has been extremely fast. Besides network stuff, I've never even noticed plugin operations, since they all seem to finish instantly.
- bern4444 4y agoI believe you complete me was a python plugin. CoC for vim is a LSP client written in typescript which was slow to startup and felt a lot slower than neovim’s native LSP
- bogwog 4y agoSlow startups are potentially a language issue (which can be mitigated/eliminated in various ways, especially for a text editor), but I hope you realize that comparing the performance of two completely different implementations doesn't say anything about the language choice. If the neovim native LSP were a direct translation of the typescript implementation, then that would be useful to compare. However, I doubt that's what happened here since doing that would be a waste of effort. If anything, it's more likely neovim's LSP was designed with knowledge of some of CoC's performance issues in mind (since it pre-dates it). As for youcompleteme, I don't have too much experience with it. I used it years ago and don't remember any performance problems, although that's anecdotal. Regardless, a completion plugin like that typically relies on a cache built from e.g. clang's compilation database feature, meaning that (after the cache is built) the plugin just needs to access that data structure in response to queries. The design of the cache and implementation of the interface between the client and the server are what will likely determine the bottlenecks, not the raw ops/sec of the Python interpreter.