No, rewriting all of that Lisp code would be impossible. It's also unnecessary. The primary advantage of Rust is safety; the compiler ensures that either your code follows the rules or that it doesn't compile at all. The Lisp code, on the other hand, already has that safety. No manipulation of conses or vectors or other lisp data structures will ever result in a buffer overflow, or a null-pointer dereference, or in doubly-freed memory, or any of a hundred other of C's pitfalls. On top of that, Lisp is extremely fast to write, test, and debug.
But of course, that safety only exists to the extent that the Lisp interpreter/compiler is bug-free. The C side of Emacs's code base is alternatively great and terrible, depending on how you look at it. On the one hand, 30 years of continuous development has resulted in code that works really well. On the other hand, it is very hard to extend this code to support new features (good multi-threading support has been in the works for ages, moving to lexical scoping and away from dynamic scoping has taken years, etc). This is because it's difficult to maintain quality and compatibility while also navigating such an old project.
Once enough of this old C code is rewritten in Rust, it'll be possible to leverage the memory safety features (and the type system) of Rust to innovate much more quickly. Not as quickly as you can innovate on code that's written in Lisp, but much more quickly than you can innovate on the C code.
Besides, the number of libraries that a program uses is only a detriment if it means that the developers have to spend more time installing and maintaining those libraries. Cargo makes this comparatively painless.
>> No, rewriting all of that Lisp code would be impossible.
I thought the lisp was written in C and so moving it to Rust would be useful. Perhaps it's written in itself. If that's the case then my bad. I did not mean rewrite the list parts in rust.
I am unclear about what you mean by this? The lisp in emacs is elisp ([0] emacs lisp). More generally, Lisp is the name given to a class of languages including Guile, Racket, Scheme, Common Lisp that generally feature homomorphism, functional style and parentheses to enable the homomorphism.
The LISP interpreter is written in C. I was trying to suggest that it may be useful to rewrite that in Rust. That is a necessary step in getting rid of the C dependencies for emacs.
But of course, that safety only exists to the extent that the Lisp interpreter/compiler is bug-free. The C side of Emacs's code base is alternatively great and terrible, depending on how you look at it. On the one hand, 30 years of continuous development has resulted in code that works really well. On the other hand, it is very hard to extend this code to support new features (good multi-threading support has been in the works for ages, moving to lexical scoping and away from dynamic scoping has taken years, etc). This is because it's difficult to maintain quality and compatibility while also navigating such an old project.
Once enough of this old C code is rewritten in Rust, it'll be possible to leverage the memory safety features (and the type system) of Rust to innovate much more quickly. Not as quickly as you can innovate on code that's written in Lisp, but much more quickly than you can innovate on the C code.
Besides, the number of libraries that a program uses is only a detriment if it means that the developers have to spend more time installing and maintaining those libraries. Cargo makes this comparatively painless.