Hello guys! Please don’t feel confronted with this question, it’s just a suggestion (and question)!
Currently, the neovim source code includes a lot of C code and I think that we all know that C has its dangerousness like double-free issues, indexing atfer an array and so on but it has the great performance of course! So I’m wondering if it would be worth to start including some rust code since rust is memory-safe and has more features to work with like traits and structs (with actual methods).
I’m not really familiar with the source code of neovim yet, I’ve just just read some lines from the runtime.c. Am I wrong with this suggestion? Would you agree to include rust code into neovim? I’m aware of that this means that we’d need some developer who need to do that but ignore this fact now.
I’d suggest “no”. Don’t get me wrong, I really like rust and use it for my stuff, but it’s just not appropriate here.
The nice safety properties of rust come in to play when you can encapsulate your unsafe parts. If you “just” introduce some rust in a C codebase like neovim, that won’t be the case. Even if you start rewriting more and more parts, it won’t be the case for quite some time. Moreover, much of (neo)vim is written in a way that’s directly not possible in safe rust (e.g. multiple mutable aliasing), so you’re not looking at a translation, but rather a rewrite of a lot of modules, while keeping the exposed APIs the same, which probably also are not compatible with safe rust. (Neo)vim is a huge codebase with lots of implicit and global state, which you will also have to get rid of to stay in safe rust. Which warrants even more redesign and rewrite… So to reap the benefits here, you’re looking at an almost full rewrite.
All the while people still want to work on the codebase, add new stuff and change things around. That’s going to be a lot of friction.
So, I don’t think this is feasible in any practical sense. That leaves “How about not rewriting any C in rust, but rather write some new code in rust?” as a possibility. While that’s a nice thought (rust is very nice to write in anyways), introducing a new language into such a codebase is quite a bit of work, introducing more maintenance trouble and CI woes. I don’t think it’s worth it.
If you want to work on neovim but feel uncomfortable in C (I can definitely relate), there’s quite a bit that can be done in lua
Hm… yes I understand what you mean here. Man… I wish we could include rust into neovim! That would be so awesome in my opinion!
Well, sadly I don’t really like lua as well because I’m missing the type-force in lua. You can’t even optionally add types to your variables which makes it very uncomfortable to me to write large code bases in lua, since you can’t be really sure, that the variable is definetely gonna be a table or an integer…
Hm… yes I understand what you mean here. Man… I wish we could include rust into neovim! That would be so awesome in my opinion!
Unfortunately, “so awesome!” is not really a compelling technical argument. This just will not happen, for all the reasons KillTheMule explained.
Well, sadly I don’t really like lua as well because I’m missing the type-force in lua. You can’t even optionally add types to your variables which makes it very uncomfortable to me to write large code bases in lua, since you can’t be really sure, that the variable is definetely gonna be a table or an integer…
Do you mean “would a PR rewriting the Lua code shipped with Neovim in Teal be accepted?” Likely not, as this would add a(nother) nontrivial dependency to our already complicated build system.
