1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
[[!meta title="An Experimental Emacs Core in Rust"]]
[[!meta copyright="Copyright © 2024 Troy Hinckley"]]
[[!inline pages="internal(2024/info/rust-nav)" raw="yes"]]
<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->
# An Experimental Emacs Core in Rust
Troy Hinckley - <https://coredumped.dev>, <mailto:troy@troyhinckley.com>
[[!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. <https://github.com/CeleritasCelery/rune>
- 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
- YouTube comment: Really interesting approach. I like the humility in the beginning, the likes of "this is to try new approaches".
[[!inline pages="internal(2024/info/rust-after)" raw="yes"]]
[[!inline pages="internal(2024/info/rust-nav)" raw="yes"]]
|
