WEBVTT

00:00:00.000 --> 00:00:06.519
Okay, so I'm going to look at some of the questions showing up

00:00:06.520 --> 00:00:08.499
in the etherpad we got here.

NOTE Q: Have you considered using CRDTs to share buffers between threads and merge any concurrent edits automatically?

00:00:08.500 --> 00:00:09.439
It says, have you considered

00:00:09.440 --> 00:00:12.799
using a CRDT to share buffers between threads and merge any

00:00:12.800 --> 00:00:16.039
concurrent edits automatically? So I have looked at that.

00:00:16.040 --> 00:00:20.559
And the problem with CRDTs is that even though they give you a

00:00:20.560 --> 00:00:22.839
mathematically correct answer when you're trying to merge

00:00:22.840 --> 00:00:26.479
two conflicts, it's not always a useful answer. Like, it's

00:00:26.480 --> 00:00:29.199
not coherent. If you have two things trying to edit the same

00:00:29.200 --> 00:00:31.359
thing, there's no good way to resolve that. And so they

00:00:31.360 --> 00:00:33.559
really work well when you have two people working live, both

00:00:33.560 --> 00:00:35.639
editing the same document, because they can fix any

00:00:35.640 --> 00:00:37.199
particular issues like that, like you would with Google

00:00:37.200 --> 00:00:39.919
Docs. But you have different packages that aren't aware of

00:00:39.920 --> 00:00:42.159
each other, and you're going to run into problems. And so

00:00:42.160 --> 00:00:44.999
this is something, if you read from the Xi editor, which was

00:00:45.000 --> 00:00:48.039
one of the first ones to use CRDTs, in the retrospective, he

00:00:48.040 --> 00:00:52.359
talks about how they had this problem, where the CRDTs They

00:00:52.360 --> 00:00:53.999
give you an answer, but it's not always an answer that's

00:00:54.000 --> 00:00:59.079
useful. And so I feel like locks at least are going to make it.

00:00:59.080 --> 00:01:00.439
It's not going to be as efficient if you have a whole bunch of

00:01:00.440 --> 00:01:02.319
packages, but I don't imagine there's going to be a ton of

00:01:02.320 --> 00:01:04.799
those. It can actually, I think it'll be more useful in

00:01:04.800 --> 00:01:05.873
practice.

NOTE Q: Why hosted on GitHub? GitHub is nonfree. Is it possible to report bugs/send patches without using GitHub?

00:01:05.874 --> 00:01:11.239
I host on GitHub because that's what I know.

00:01:11.240 --> 00:01:13.239
If there's a way to host it on somewhere else, I'd be

00:01:13.240 --> 00:01:15.439
interested in doing that. If you're interested in setting

00:01:15.440 --> 00:01:17.799
patches without using GitHub, you could always send an

00:01:17.800 --> 00:01:22.959
email. I'm more than happy to accept email patches.

NOTE Q: Do you think it's possible to achieve 100% compatibility with current Emacs code?

00:01:22.960 --> 00:01:24.959
Do you think it's possible to achieve with the current Emacs

00:01:24.960 --> 00:01:29.719
code? I do. I think, I think you can do that. Um, like I said,

00:01:29.720 --> 00:01:33.279
there's a couple things inside there that are intentional

00:01:33.280 --> 00:01:37.919
breaks with existing Emacs code. And some of those being

00:01:37.920 --> 00:01:43.159
like functions are immutable. As well as having data shared

00:01:43.160 --> 00:01:44.759
switch between different threads, which means there's

00:01:44.760 --> 00:01:46.599
going to be some copying going on. So there's going to be

00:01:46.600 --> 00:01:48.399
subtle things that are going to be different. And we've

00:01:48.400 --> 00:01:50.359
really got to think about those intentionally, but I'm

00:01:50.360 --> 00:01:54.519
really going for bug compatibility with GNU Emacs so that

00:01:54.520 --> 00:01:57.159
you can take an existing Elisp package and just run it and it

00:01:57.160 --> 00:01:59.879
just works, 'cause I think that's one of the big strengths of

00:01:59.880 --> 00:02:03.399
the Emacs ecosystem is the millions of lines of Elisp that

00:02:03.400 --> 00:02:07.479
people have written.

00:02:07.480 --> 00:02:11.912
Um, So I'm not, okay...

NOTE Q: so you're re-implementing elisp in rust? have you considered using a more modern lisp, such as scheme? [11:03]

00:02:11.913 --> 00:02:14.279
So since you're re-implementing Elisp and

00:02:14.280 --> 00:02:17.039
Rust, have you considered using more modern Lisp such as

00:02:17.040 --> 00:02:20.919
Scheme? So I'm not re-implementing Elisp and Rust. I'm

00:02:20.920 --> 00:02:25.439
re-implementing the C in Rust. In fact, I would like to make

00:02:25.440 --> 00:02:30.479
more of the core that's written in C in Elisp instead of C or

00:02:30.480 --> 00:02:33.839
Rust, because then it's actually introspectible. There's

00:02:33.840 --> 00:02:38.719
a talk by Tom Tromney that he gave a while ago about Emacs

00:02:38.720 --> 00:02:42.239
should be Emacs Lisp. I kind of like that philosophy,

00:02:42.240 --> 00:02:44.799
that as much of it as should be Elisp as possible, and we

00:02:44.800 --> 00:02:48.079
should only have C or Rust or some systems level language for

00:02:48.080 --> 00:02:52.319
really low-level stuff. Using a more modern LISP such as

00:02:52.320 --> 00:02:54.839
Scheme. I know there's, I mean, there's two talks, I think,

00:02:54.840 --> 00:02:58.239
in this conference about using Scheme inside Emacs. And I

00:02:58.240 --> 00:03:00.719
looked at this at one point about what if you wrote it inside

00:03:00.720 --> 00:03:03.919
Common LISP, because that's also has some really low level

00:03:03.920 --> 00:03:05.879
details. And then you could go from Elisp down to Common

00:03:05.880 --> 00:03:09.199
Lisp. But the problem is, is under the hood, you still need a

00:03:09.200 --> 00:03:12.559
systems language. You can't, you still need either C or Rust

00:03:12.560 --> 00:03:15.639
or something underneath the Common Lisp to implement the

00:03:15.640 --> 00:03:17.799
primitives. And so it's not going to give you just two

00:03:17.800 --> 00:03:19.719
languages, you know, you'll have three. You'll have the

00:03:19.720 --> 00:03:24.919
elisp, common lisp, and C under the hood. And so in this case

00:03:24.920 --> 00:03:29.559
we just have the two. We have the Elisp and the rest.

00:03:29.560 --> 00:03:42.999
All right that's all the questions I see there. Let

00:03:43.000 --> 00:03:54.079
me go look at... Okay,

00:03:54.080 --> 00:04:01.399
so I see into the chat.

NOTE Q: Do you have specific features from the Rust compiler that are missing (or are nightly-only) that you would take advantage of?

00:04:01.400 --> 00:04:03.839
Does it features from the Rust compiler that are missing

00:04:03.840 --> 00:04:06.239
that way you would take advantage of? Oh, that is a great

00:04:06.240 --> 00:04:10.679
question. Um, there's a handful of them. Uh, I should've

00:04:10.680 --> 00:04:13.599
written down a list of these. One of them is Polonius, which

00:04:13.600 --> 00:04:17.959
is the new borrow checker because we're trying to be used

00:04:17.960 --> 00:04:21.759
lifetime to track our objects. We often run into situations

00:04:21.760 --> 00:04:24.239
where we've kind of got a hack around things because the

00:04:24.240 --> 00:04:26.199
limitations with the borrow checker. And so I have a whole

00:04:26.200 --> 00:04:29.559
bunch of like notes inside there about where. A better

00:04:29.560 --> 00:04:34.959
Polonius would help inside there and help ease some of the

00:04:34.960 --> 00:04:40.599
issues. Another thing is enum variances types, because

00:04:40.600 --> 00:04:42.999
right now we have an object which is defined as a big enum that

00:04:43.000 --> 00:04:46.079
had all the possible objects, but if we want to have a subset

00:04:46.080 --> 00:04:47.479
of those objects or just pass in one of those objects, we've

00:04:47.480 --> 00:04:50.079
got to define a new struct. And so we have a whole bunch of

00:04:50.080 --> 00:04:52.839
boilerplate code to define that all out. And if we had

00:04:52.840 --> 00:04:56.719
variances types, that would make the code a lot easier.

00:04:56.720 --> 00:05:00.079
Another one is the allocator API. Right now we're kind of

00:05:00.080 --> 00:05:02.479
working around it, but ultimately we're going to need our

00:05:02.480 --> 00:05:07.719
own allocator. And the allocator API is still nightly only.

00:05:07.720 --> 00:05:10.919
So there's a couple more. I'll look at that more, but that's a

00:05:10.920 --> 00:05:24.279
great question.

00:05:24.280 --> 00:05:26.879
Let's see.

NOTE Q: Can remacs be reused?

00:05:26.880 --> 00:05:30.799
Okay. I see a question you might not have noticed just asking

00:05:30.800 --> 00:05:37.159
about reuse of Remacs. Oh, yes, so I have reused some of Remacs

00:05:37.160 --> 00:05:40.159
code, and some taken, like I mentioned, taken some of their

00:05:40.160 --> 00:05:45.319
ideas, but ultimately we're using a different model

00:05:45.320 --> 00:05:49.439
because under the hood in Remacs, everything is just defined

00:05:49.440 --> 00:05:53.799
as an opaque external type that's defined inside Emacs and

00:05:53.800 --> 00:05:56.159
so it just pulls those in interacts with those and passes

00:05:56.160 --> 00:05:58.879
them back into C. We're trying to see what we can do if we

00:05:58.880 --> 00:06:02.279
say okay we're not going to take the same... So they're bound to

00:06:02.280 --> 00:06:06.839
the implementation details of Emacs, and we don't want to do

00:06:06.840 --> 00:06:09.559
that. We've re-implemented all the core types

00:06:09.560 --> 00:06:12.559
ourselves. So that means that we can't just take the

00:06:12.560 --> 00:06:16.559
Remacs code one for one and use it in our project, but we can

00:06:16.560 --> 00:06:18.799
take a lot of their ideas. I've spent some time reading

00:06:18.800 --> 00:06:20.439
through their documentation, different things about how

00:06:20.440 --> 00:06:23.856
they approached strings and GC

00:06:23.857 --> 00:06:24.759
and different stuff like that.

00:06:24.760 --> 00:07:23.599
Looks like all the questions.

NOTE Q: What are you thoughts on the GUI layer. Any plans on how to reimplement it?

00:07:23.600 --> 00:07:26.199
Okay, so another question. What are your thoughts on the GUI

00:07:26.200 --> 00:07:30.959
layer? Any plans on how to reimplement it? This is something

00:07:30.960 --> 00:07:34.079
I've thought a lot about, but I still don't have a solid plan

00:07:34.080 --> 00:07:37.253
for. I'm not really a GUI person. I mostly work with

00:07:37.254 --> 00:07:42.719
low-level. And so my two thoughts is you can go the GTK route.

00:07:42.720 --> 00:07:45.519
There's Rust bindings for that. That's well understood.

00:07:45.520 --> 00:07:48.319
It's got a good support. But there's also some interesting

00:07:48.320 --> 00:07:53.919
projects to try and do GUI in Rust, native Rust, and have it

00:07:53.920 --> 00:07:57.399
use Rust idioms and stuff like that. And so those are things

00:07:57.400 --> 00:08:01.439
like Druid and there's eGUI and a bunch of those that are that

00:08:01.440 --> 00:08:05.359
way. And I've never used one of them, but I'd be interested to

00:08:05.360 --> 00:08:08.879
try that out first and see how well does this work and how well

00:08:08.880 --> 00:08:21.239
supported is this doing a Rust-first GUI.

NOTE Q: If money could fix the problem, how much would it cost to ship this with feature parity before 2026?

00:08:21.240 --> 00:08:23.639
If money could fix the problem, how much would it cost to ship

00:08:23.640 --> 00:08:28.399
this with feature parity before 2026? Ooh, in a year. Uh,

00:08:28.400 --> 00:08:32.079
that's a good question. Even if we had the money, it would

00:08:32.080 --> 00:08:36.639
take more than just me, even if I was working on it full time.

00:08:36.640 --> 00:08:40.630
Um, I don't know. That's a good question.

00:08:40.631 --> 00:08:41.769
I would think it would take a team

00:08:41.770 --> 00:08:45.239
of at least a handful of people to get this

00:08:45.240 --> 00:08:48.559
shipping within one year. Because there's still a lot of

00:08:48.560 --> 00:08:50.759
work to do. And even once you have everything implemented,

00:08:50.760 --> 00:08:55.119
there's a lot of bug finding and smoothing it out so that it

00:08:55.120 --> 00:08:57.519
runs as well as Emacs, which has been, you know, battle

00:08:57.520 --> 00:08:58.359
tested for a long time.

00:08:58.360 --> 00:09:06.599
Um, okay, so this might be a good moment for me to break in and

00:09:06.600 --> 00:09:09.039
just say that we've got about 10 minutes left before we

00:09:09.040 --> 00:09:12.519
resume new talks on on both tracks. Of course, we're happy to

00:09:12.520 --> 00:09:18.119
keep this. This chat open and keep the recording going here,

00:09:18.120 --> 00:09:21.599
which will share after the conference as long as as long as

00:09:21.600 --> 00:09:28.349
there's discussion here. Thank you.

NOTE GObject implementation

00:09:28.350 --> 00:09:29.119
GTK project has

00:09:29.120 --> 00:09:31.079
automatic binding with a framework called GObject

00:09:31.080 --> 00:09:33.599
introspection, which is what I'm using for gypsum project.

00:09:33.600 --> 00:09:35.959
Probably Rust has a G object implementation, which you can

00:09:35.960 --> 00:09:39.119
use. Yeah, I know it has some GTK bindings. Um, I'm not sure if

00:09:39.120 --> 00:09:41.954
it's specifically GObject, but that's a good path

00:09:41.955 --> 00:09:44.335
because I feel like the problem

00:09:44.336 --> 00:09:46.759
with the Rust GUIs is that they're all

00:09:46.760 --> 00:09:50.359
very new. And so, you know, everything works in a demo, but

00:09:50.360 --> 00:09:52.319
you need something that can work across all different

00:09:52.320 --> 00:09:54.319
devices and all different platforms and have really good

00:09:54.320 --> 00:09:56.599
support and good accessibility and stuff like that.

NOTE Q: elisp is implemented in c, so if you're not implementing elisp in rust, are you using/keeping the c implementation of elisp?

00:09:56.600 --> 00:10:03.399
All right, Elisp is implemented in C. So if you're not

00:10:03.400 --> 00:10:07.359
implementing Elisp in Rust, we're keeping the C

00:10:07.360 --> 00:10:13.639
implementation of Elisp. So let me see if I can do a better job

00:10:13.640 --> 00:10:18.439
of explaining this. So inside Emacs, you have about a

00:10:18.440 --> 00:10:21.519
million lines of Elisp. And underneath that, you have the C,

00:10:21.520 --> 00:10:24.079
which is the primitives everything's implemented yet. And

00:10:24.080 --> 00:10:27.079
so we're keeping all of the Elisp, and we're just taking that

00:10:27.080 --> 00:10:30.559
C layer and replacing it with Rust. And so when you call a

00:10:30.560 --> 00:10:33.079
built-in function, it's calling into a Rust function

00:10:33.080 --> 00:10:40.079
instead of a C function under the hood. So all the Elisp stays

00:10:40.080 --> 00:10:42.679
Elisp, but the C becomes Rust.

NOTE Clarifying rewriting Elisp in Rust

00:10:42.680 --> 00:10:54.599
So looking at the IRC chat, it feels to me like maybe there's a

00:10:54.600 --> 00:10:59.159
little bit of confusion around what do we mean when we say

00:10:59.160 --> 00:11:04.839
rewriting Elisp in Rust, right? I think there are some

00:11:04.840 --> 00:11:07.399
people that are like, A, we're reinventing ELISP, and

00:11:07.400 --> 00:11:09.679
there's other people that are like, no, we're trying to be

00:11:09.680 --> 00:11:12.879
byte-for-byte compatible with Rust.

00:11:12.880 --> 00:11:17.500
So some people are questioning your no answer on that.

00:11:17.501 --> 00:11:20.000
Aren't you really, maybe, is what I'm reading in there.

00:11:20.001 --> 00:11:21.769
Do you want to respond to that?

00:11:21.770 --> 00:11:26.119
Yeah, I'm trying to think about how I can make this

00:11:26.120 --> 00:11:29.559
clearer. So the Elisp stays Elisp. We're not changing the

00:11:29.560 --> 00:11:33.239
Elisp at all, or at least very minimally. We want to be able to

00:11:33.240 --> 00:11:36.519
take, like I said, bug compatible. So whatever works inside

00:11:36.520 --> 00:11:39.999
existing Emacs, you can take all the Lisp and you can run it in

00:11:40.000 --> 00:11:43.599
Rune and it works the same. So the Elisp stays the same. It's

00:11:43.600 --> 00:11:47.119
just the under the hood core that is getting replaced. And

00:11:47.120 --> 00:11:49.199
this in turn adds some new features such as

00:11:49.200 --> 00:11:52.799
multi-threading. So it's not exactly compatible, but

00:11:52.800 --> 00:11:55.559
you should be able to use your existing code and the Elisp will

00:11:55.560 --> 00:12:00.639
stay Elisp. So the idea is that anything that I've written as

00:12:00.640 --> 00:12:04.559
an Emacs user, my config, my custom packages, whatever it

00:12:04.560 --> 00:12:08.999
may be, that's all going to be valid code. If you take, you

00:12:09.000 --> 00:12:13.163
know, the Elisp implementation as being the C code

00:12:13.164 --> 00:12:15.745
and the parts of Elisp written in Elisp

00:12:15.746 --> 00:12:18.448
that represent opportunity space

00:12:18.449 --> 00:12:20.799
thinking about Rust as an implementation language...

00:12:20.800 --> 00:12:24.479
Okay fine. You know, you can make a semantic argument, okay

00:12:24.480 --> 00:12:25.995
we're re-implementing, we're creating

00:12:25.996 --> 00:12:29.018
an alternate implementation of Elisp

00:12:29.019 --> 00:12:31.639
but what Elisp is isn't the problem

00:12:31.640 --> 00:12:35.039
space here. That's a fixed, a given, if you will.

00:12:35.040 --> 00:12:36.065
Is that all right?

00:12:36.066 --> 00:12:39.199
That's a good way of saying it. Okay. Yeah, what you

00:12:39.200 --> 00:12:42.559
said makes sense. I was kind of responding to some comments,

00:12:42.560 --> 00:12:44.959
like I'm not sure it connected for everybody. Makes a lot of

00:12:44.960 --> 00:12:47.399
sense. Yeah, I wasn't sure how much I needed to expand on that

00:12:47.400 --> 00:12:51.119
and explain that, but I appreciate you jumping in.

00:12:51.120 --> 00:12:57.907
Um, okay. So if I were just going to, but...

NOTE Q: Will your Rust implementation also be able to run Emacs bytecode? Or are you implementing it at the Lisp level?

00:12:57.908 --> 00:13:02.239
Will your Rust implementation also be able to run Emacs bytecode or the

00:13:02.240 --> 00:13:04.359
implemented at the Lisp level? So I already have a bytecode

00:13:04.360 --> 00:13:06.759
interpreter inside there that runs the existing Elisp

00:13:06.760 --> 00:13:09.519
bytecode. And so that was one of the first things I did was

00:13:09.520 --> 00:13:11.679
bootstrap the interpreter and then bootstrap the bytecode

00:13:11.680 --> 00:13:14.999
engine. And so we compile, we use the... because the bytecode

00:13:15.000 --> 00:13:19.079
compiler is written in Emacs Lisp. So you bootstrap that

00:13:19.080 --> 00:13:22.919
and it gives you the Emacs bytecode. I have a bytecode

00:13:22.920 --> 00:13:26.039
engine that runs the bytecode. So that's already done. And

00:13:26.040 --> 00:13:28.239
you can potentially, on top of that, do something like the

00:13:28.240 --> 00:13:31.999
data compilation or a JIT. But we have both an

00:13:32.000 --> 00:13:47.019
interpreter and a bytecode compiler.

00:13:47.020 --> 00:13:50.799
And I'll just break in one more time to say with about five

00:13:50.800 --> 00:13:56.319
minutes left in our live time with this Q&A session, which

00:13:56.320 --> 00:13:58.439
we're happy to keep going as long as there are questions.

00:13:58.440 --> 00:14:03.959
Coming up in five minutes, we'll have a talk on color on the

00:14:03.960 --> 00:14:09.639
gen track. And then right here, we'll have the p-search

00:14:09.640 --> 00:14:09.959
talk.

00:14:09.960 --> 00:14:20.099
Thank you.

NOTE Q: Is it possible to bootstrap with just the bytecode interpreter?

00:14:20.100 --> 00:14:22.559
Is it possible to bootstrap with just the bytecode

00:14:22.560 --> 00:14:25.759
interpreter? So I'll have to put in a link to one of my blog

00:14:25.760 --> 00:14:28.519
posts. So that was my original idea was to say, I don't want to

00:14:28.520 --> 00:14:31.559
have an interpreter, a bytecode interpreter and a native

00:14:31.560 --> 00:14:33.180
compiler. I want to just have just one.

00:14:33.181 --> 00:14:36.741
So I'm only going to have the bytecode.

00:14:36.742 --> 00:14:37.708
And so that's what I did initially.

00:14:37.709 --> 00:14:42.079
The problem with that is, is that a bunch of the early bootstrap

00:14:42.080 --> 00:14:45.117
Emacs code is written with the assumption

00:14:45.118 --> 00:14:47.278
that it's going to be interpreted.

00:14:47.279 --> 00:14:49.019
This is especially true with macros,

00:14:49.020 --> 00:14:50.821
where you'll have a function defined,

00:14:50.822 --> 00:14:52.642
you'll evaluate part of the function.

00:14:52.643 --> 00:14:55.599
The other half of the function has macros in it

00:14:55.600 --> 00:14:59.719
that are not defined yet, but it doesn't matter because they

00:14:59.720 --> 00:15:02.399
don't get used. But with the bytecode interpreter, it

00:15:02.400 --> 00:15:04.639
expands all macros when it gets the function definition.

00:15:04.640 --> 00:15:08.799
And so those weren't macros when the function was expanded,

00:15:08.800 --> 00:15:12.359
and therefore they got instantiated as functions, but

00:15:12.360 --> 00:15:15.759
they're not functions, they're macros. And so I initially

00:15:15.760 --> 00:15:18.999
spent a bunch of time trying to work around this, trying to

00:15:19.000 --> 00:15:21.599
move code around, work stuff around, refactor the code to

00:15:21.600 --> 00:15:24.759
try and get it to work with only bytecode interpreter. And

00:15:24.760 --> 00:15:27.039
eventually I just gave up. I said, you know what, I'm just

00:15:27.040 --> 00:15:30.039
going to write an actual interpreter to handle this because

00:15:30.040 --> 00:15:33.799
trying to handle all these lazy macros is too much work. And

00:15:33.800 --> 00:15:35.759
everything in the bootstrap is built with the assumption

00:15:35.760 --> 00:15:37.799
that you have lazy macro expansion.

00:15:37.800 --> 00:15:45.159
I'm guessing the Emacs bytecode interpreter isn't

00:15:45.160 --> 00:15:45.959
complete.

00:15:45.960 --> 00:15:52.279
So it's mostly complete. There's a handful of opcodes that

00:15:52.280 --> 00:15:55.239
aren't implemented that are pretty easy to add that I

00:15:55.240 --> 00:15:57.879
haven't run into. And there's some of them that are

00:15:57.880 --> 00:16:00.119
deprecated that aren't implemented, but it's essentially

00:16:00.120 --> 00:16:00.479
complete.

00:16:00.480 --> 00:16:11.999
We also provide a bytecode JIT compilation via libgcc the

00:16:12.000 --> 00:16:17.344
way Emacs currently does it. Eventually I would like to...

00:16:17.345 --> 00:16:22.919
I'm more inclined to have a proper runtime JIT than an

00:16:22.920 --> 00:16:27.399
ahead-of-time compiler like libgcc, like the current

00:16:27.400 --> 00:16:29.919
Emacs native compilation, because it allows you to take

00:16:29.920 --> 00:16:34.559
type information and actually apply that to the code, which

00:16:34.560 --> 00:17:03.959
can let you do more aggressive optimizations to it.

NOTE What would it take to bootstrap Guile in Rune?

00:17:03.960 --> 00:17:06.319
He said, we may either get a new Emacs with an ancient C core

00:17:06.320 --> 00:17:09.039
with a modern Lisp, or an Emacs with modern core, but stuck

00:17:09.040 --> 00:17:11.879
with ancient Elisp. So there was another project I was

00:17:11.880 --> 00:17:16.639
talking to, one of the Guile implementations, about how we

00:17:16.640 --> 00:17:19.119
could potentially, he was like, what would it take to

00:17:19.120 --> 00:17:24.479
bootstrap Guile in Rune, where you have both, you could have

00:17:24.480 --> 00:17:27.399
Elisp and Guile running inside this project. And so we've

00:17:27.400 --> 00:17:28.999
started that discussion, which I think would be, which

00:17:29.000 --> 00:17:33.999
would be interesting. But it's tricky too, because

00:17:34.000 --> 00:17:36.199
fundamentally Elisp and Guile are two different

00:17:36.200 --> 00:17:38.119
languages. They have different semantics. They have

00:17:38.120 --> 00:17:39.879
different ways of handling things. You've really got to

00:17:39.880 --> 00:17:42.479
consider both of those when you're trying to make them work

00:17:42.480 --> 00:17:42.799
together.

00:17:42.800 --> 00:17:57.319
How would you do the native module system? What would be

00:17:57.320 --> 00:17:59.799
different? We can do the same thing. We have an FFI. So I

00:17:59.800 --> 00:18:03.839
haven't looked into it a ton, but I feel like it could be

00:18:03.840 --> 00:18:06.359
similar. And I'm actually interested, there's a couple

00:18:06.360 --> 00:18:12.759
projects on GitHub right now to have an FFI written in Elisp.

00:18:12.760 --> 00:18:17.239
So you don't even need to create a separate C or Rust module,

00:18:17.240 --> 00:18:21.679
because you can actually write native modules in Rust or C.

00:18:21.680 --> 00:18:25.559
And so you can just have direct bindings to a C FFI written in

00:18:25.560 --> 00:18:27.799
Elisp. You don't need any C code inside there. And I think

00:18:27.800 --> 00:18:33.699
that would be an interesting approach to look at as well.

00:18:33.700 --> 00:18:35.839
Oh, Ramin. Yeah, that's right. We were talking about that,

00:18:35.840 --> 00:18:41.539
about bootstrapping Scheme.

00:18:41.540 --> 00:18:45.519
And at this point, we have broken away from, uh, from this

00:18:45.520 --> 00:18:47.399
talk, but we're continuing to record and this will all be

00:18:47.400 --> 00:18:50.439
published. I'd say, go ahead and keep going as long as you'd

00:18:50.440 --> 00:18:54.959
like in here. And, um, thanks once again for the awesome

00:18:54.960 --> 00:18:58.639
discussion. Thank you so much. So I'll just pay attention to

00:18:58.640 --> 00:19:02.919
the ether pad and the chat and see.

00:19:02.920 --> 00:19:05.919
That sounds good. I'll keep an eye on IRC. And if there are

00:19:05.920 --> 00:19:08.559
more questions here, I'll bounce people toward the ether

00:19:08.560 --> 00:19:12.760
pad or this, uh, chat room. All right, thank you.