[[!meta title="An Experimental Emacs Core in Rust"]] [[!meta copyright="Copyright © 2024 Troy Hinckley"]] [[!inline pages="internal(2024/info/rust-nav)" raw="yes"]] # An Experimental Emacs Core in Rust Troy Hinckley - , [[!inline pages="internal(2024/info/rust-before)" raw="yes"]] An overview and discussion and early prototype of a new Emacs core written in Rust. The talk covers some of the interesting design choices in the GNU Emacs C core, as well as some of the trade-offs made in the Rust core.  - What is the Emacs core? - How has the core evolved? - Design trade-offs - multi-threading - Precise GC - Being bug compatible with GNU Emacs - Comparison About the speaker: Hardware Engineer with interest in low-level programming and the hardware-software boundary. # Discussion ## Questions and answers - Q: Have you considered using CRDTs to share buffers between threads and merge any concurrent edits automatically? - A: While mathematically correct, CRDT does not always produce a useful answer. With different packages, this will the issue: not a useful result. [https://www.moment.dev/blog/lies-i-was-told-pt-1](https://www.moment.dev/blog/lies-i-was-told-pt-1) - This question answer about CRDT's is by itself showing a lot of problem awareness - Q: Why hosted on GitHub? GitHub is nonfree. Is it possible to report bugs/send patches without using GitHub? - A: Email patches are possible. Github is what the speaker knows. - Q: Do you think it's possible to achieve 100% compatibility with current emacs code?  - A: Most should be compatible (since elisp package is the biggest emacs strength) but there might be differences on purpose. - Q: troyhinckley: so you're re-implementing elisp in rust?  have you considered using a more modern lisp, such as scheme? \[11:03\] - A: No actually. Only trying to reimplementing the C part of emacs, replacing it by rust. There are two other talks in the conference to use something else (guile and scheme). - Q:can remacs be reused? - A: Some of the code and some of the ideas (documentation, ideas and approach to problems) were taken. But different model: in remacs everything is an external type. Here, instead trying, to use the builtin type reimplementating the objects instead. - Q: hello, great talk, fascinating topic! I am a contributor of the compiler team of the Rust prog. language (though I don't delve in the code myself). Do you have specific features from the Rust compiler that are missing (or are nightly-only) that you would take advantage of?  10:05:38  - A: Polonius: the new borrow checker. Would solve lifetime-tracking issues. A better tracking mechanism would be better. - A: Enum with variant types to avoid boilerplate [https://github.com/rust-lang/lang-team/issues/122](https://github.com/rust-lang/lang-team/issues/122) - A: Allocator API could be better (still nightly-only) - A: thanks! Dont forget to fill out the survey :) [https://blog.rust-lang.org/2024/12/05/annual-survey-2024-launch.html](https://blog.rust-lang.org/2024/12/05/annual-survey-2024-launch.html) - Q: What are you thoughts on the GUI layer. Any plans on how to reimplement it? - A: Either GTK+ or direct GUI in Rust, but no concrete plan so far. - Q: (not a question) Re. the GUI layer, the Gtk project has automated bindings with a framework called "GObject Introspection," which is what I am using for my "Gypsum" project. Probably Rust has a GObject Implementation which you could use. - A: Problem with Rust GUIs very new and mostly demo without accessibility and test in all environements. - Q: If money could fix the problem, how much would it cost to ship this with feature parity before 2026? - A: Probably needs a couple people and more than one year of work. Lots of testing required to fix all bugs. - Q: troyhinckley: elisp is implemented in c, so if you're not implementing elisp in rust, are you using/keeping the c implementation of elisp? - A: Idea of the project is to keep the Elisp layer and changing the C layer underneath that is currently called, replacing it by rust. Elisp does not change. Plan is to be even be bug compatible to emacs: Elisp should be perfectly compatible with both C and rust. Elisp is fixed in this approach. - Q: sorry if you already discussed this, but will your Rust implementation also be able to run Emacs bytecode? Or are you implementing it at the Lisp level? - A: Bytecode interpreter already exists (actually bytecode compiler and interpreter was bootstrapped first as it is implemented in Elisp). - A: the bytecode is missing some OP-code that have not been encountered so far. - Q: Cool, so will you also provide bytecode JIT compilation via "libgcc" the way Emacs currently does? - A: Eventually maybe, but a proper JIT would be better as it includes type information to better optimize the code. -  Q: Is it possible to bootstrap without the interprerter? - A: having only bytecode does not work, as some part are expected to be interpreted with macros containing functions that are not yet defined. You really need an interpreter for the lazy macro expansion. - Q: How would you do the native module system?  What would be different?  Sounded like part of an anwer about Rust Emacs modules got cut off. - A: There is an FFI, so it should be possible to have the same thing. Could possibley implement FFI in elisp. - Q:  That was me who was discussing with you about bootstrapping Scheme! (Not Guile, R7RS Scheme) Yes, it would be a whole other thing than what you have done so far. But it would be cool, because then you would be able to run the "Gypsum" editor on top of your Emacs engine. - A: I still think that would be really cool to get working! we will have to collaborate on that more. - Q: elisp is implemented in c, so if you're not implementing elisp in rust, are you using/keeping the c implementation of elisp? - IRC: of course they are implementing elisp in rust (?), what else could they mean? - I think they misunderstood your question - (not yet answered)? ## Notes - Getting good vibes from this Rust work - (you can do the offscreen-cursor thing in current emacs with enough effort. see scroll-in-place.el.) - Oooooh flow images.  My last expectation was Rust making Dslide image animations slick - troyhinckley: Very cool talk!  - I recommend [https://codeberg.org/](https://codeberg.org/) (as a freedom-respecting github replacement) - one big problem with using gtk \-- there is a \*two-decade-old\* unfixed bug in gtk where it keeps permanent references to the x server etc (IIRC, its wayland support has similar problems). this means a gtk emacs \--daemon crashes if you connect to an x server and then close the x server down. this is\.... unfortunate - I had not thought about the fact that we could just mutate functions on the fly just like data. Neat! - really good talk! - Getting good vibes from this Rust work - I'm spending half this talk going OOH and wishing we had this in current emacs - Very cool talk! - So looking forward to a faster multi-threaded Emacs :D - Well, it does sound like we need some scale to turn this from a multi-year idea to a next-year idea - ruby shows one advantage here -- they're reimplementing bits of the ruby C core in ruby, and *speeding it up* because their new jitter then sees the insides of it and can optimize the hell out of it. ruby is, of course, famously slow... but not as slow as elisp :) - one wonders if emacs could benefit similarly... - one big problem with using gtk -- there is a *two-decade-old* unfixed bug in gtk where it keeps permanent references to the x server etc (IIRC, its wayland support has similar problems). this means a gtk emacs --daemon crashes if you connect to an x server and then close the x server down. this is.... unfortunate - yeah "of course" all new emacs efforts should be able to run elisp code; but it would be awesome if new lispy code could be written in scheme [[!inline pages="internal(2024/info/rust-after)" raw="yes"]] [[!inline pages="internal(2024/info/rust-nav)" raw="yes"]]