GitHub - CeleritasCelery/rune: Rust VM for Emacs

I became interested in implementing programming languages a few years ago and discovered [Crafting Interpreters](https://craftinginterpreters.com/) by Bob Nystrom. At the time, I had experience with Rust and decided to use it to follow the book. Albeit, being a noob, I managed to implement a fully functional bytecode interpreter that supported every feature of the Lox language as described. However, my implementation suffered memory leaks due to reference counting. Back then, I didn't fully grasp Rust to design and implement a proper garbage collector (GC)! Now that I have more confidence in the language, I decided to revisit the project and improve its memory management scheme.

This Org-mode file was used for an org-present presentation at EmacsConf 2025 – Juicemacs. This blog post is adapted from that presentation, with added transcript and explanations for a bunch of things I didn't dig into during the presentation. For EmacsConf 2025 Project: https://github.com/gudzpoz/Juicemacs Contact: See the navigation bar (or join the Zulip chat)

A while ago while working on Rust-based Emacs, I was loading a new elisp file and hit a stack overflow. Digging deeper I found the issue in trying to print a cyclic list (where the tail of the list points back to previous element). I knew this was a possibility, and that at some point I would have to handle cycles. So I quickly implemented a version of Floyd’s cycle detection algorithm (visualized here).

In my last post I introduced an Emacs Lisp VM I was writing in Rust. My stated goal at the time was to complete a garbage collector. I think Rust has some really interesting properties that will make building garbage collectors easier and safer. Many of the techniques used in my GC are not original and have been developed by other Rustaceans in previous projects. Updated: 2022-09-06 Why use garbage collection?

Updated: 2023-01-06 About a year ago I was bitten by the PL bug. It started with reading Crafting Interpreters and discovering the wonders hidden under the hood of a compiler. I am also been a big fan of Emacs, and this started to get me interested in how its interpreter works. At the same time, I was reading the Rust book and trying to understand the concepts there. This all came to a head, and I decided to write an Emacs Lisp interpreter called rune in Rust.

There have been quite a few attempts to re-implement (part of) Emacs' functionalities in languages other than C, like JEmacs, remacs, and lem. And we are seeing new efforts in EmacsConf 2024: rune 1, schemacs 2, and the revived Guilemacs 3. (Strictly speaking, Guilemacs is more a fork than a total rewrite, but anyway.) However, a complete rewrite of (GNU) Emacs 4 has always seemed like an insurmountable task, not just because writing editors is hard. This article aims to look into some of these difficulties and the Emacs designs (that of course have been exposed in some Emacs Lisp API) that lead to them.