path: root/2022/captions/emacsconf-2022-async--emacs-was-async-before-async-was-cool--michael-herstine--answers.vtt

WEBVTT

NOTE Introduction

00:00:00.000 --> 00:00:06.999
[Amin]: Okay, so for folks, you can start asking your questions over IRC or the PAD,

00:00:07.000 --> 00:00:10.839
and after a minute or two, we'll also open up this big blue button room

00:00:10.840 --> 00:00:14.799
for those of you who would like to join here to ask these questions directly.

00:00:14.800 --> 00:00:16.199
Michael, take it away.

00:00:16.200 --> 00:00:21.599
[Michael]: Okay, cool. It looks like we've got two questions on the PAD.

NOTE How does this approach compare to using tq.el, Emacs' built-in library for transaction queues?

00:00:21.600 --> 00:00:26.039
The first, how does this approach compare to using TQ.L,

00:00:26.040 --> 00:00:29.279
Emacs's built-in library for transaction queues?

00:00:29.280 --> 00:00:31.759
Yeah, that's actually a great question.

00:00:31.760 --> 00:00:35.159
I should have called out TQ in the talk

00:00:35.160 --> 00:00:40.559
because I actually took a hard look at it in terms of my implementation.

00:00:40.560 --> 00:00:47.159
You could absolutely build this using TQ.L. I chose not to because

00:00:47.160 --> 00:00:51.199
I didn't see any compelling benefits to pay the cost

00:00:51.200 --> 00:00:58.199
of adding another dependency and creating a buffer for each new connection.

00:00:58.200 --> 00:01:04.679
In the actual implementation, input is buffered into a variable connected

00:01:04.680 --> 00:01:10.479
to the connection object and just handled there.

NOTE Have you considered using the aio.el library (written by Chris Wellons) that implements async/await for Emacs lisp using promises?

00:01:10.480 --> 00:01:16.439
Have you considered using the AIO.L library written by Chris Wellens,

00:01:16.440 --> 00:01:22.239
implements async await for Emacs Lisp using promises. Implemented

00:01:22.240 --> 00:01:25.559
using Elisp's record data structure turns the nested callbacks into

00:01:25.560 --> 00:01:30.279
regular-looking Elisp code without introducing new keywords. Cool. No,

00:01:30.280 --> 00:01:34.959
I didn't because I was not aware of the package. But the fact

00:01:34.960 --> 00:01:40.519
that it was written by Chris Wellens alone is enough to get me to take a look.

00:01:40.520 --> 00:01:43.879
So yeah, perhaps that could have been another implementation.

00:01:43.880 --> 00:01:49.159
But I don't know. This kind of code journey finally got me

00:01:49.160 --> 00:02:03.919
to understand Emacs Lisp. I don't regret anything else.

00:02:03.920 --> 00:02:07.119
[Amin]: I think your last sentence was a little cutting off, Michael.

00:02:07.120 --> 00:02:09.199
Maybe you were a little far from the mic.

00:02:09.200 --> 00:02:13.199
But yeah. Okay. All I was going to say is, yeah, I mean,

00:02:13.200 --> 00:02:19.679
leave it to Chris Wellens to solve the problem in all generality.

00:02:19.680 --> 00:02:27.479
All I noted at the end was given that this little project

00:02:27.480 --> 00:02:34.079
is what finally got me to understand Emacs macros or Lisp macros, you know,

00:02:34.080 --> 00:02:42.719
I kind of, I don't regret running down this implementation.

00:02:42.720 --> 00:02:45.439
We've got another question coming in.

NOTE Are you aware that EMMS has an MPD client? There's also mpc.el built into Emacs.

00:02:45.440 --> 00:02:49.399
Am I aware that Ems has an MPD, I absolutely am.

00:02:49.400 --> 00:02:54.399
And there's actually another MPD client for Emacs called MPD-L.

00:02:54.400 --> 00:03:05.399
Yes, yes there is. So again, I probably should have talked about this in before,

00:03:05.400 --> 00:03:10.759
but I was pressed for time. I was not looking, yeah,

00:03:10.760 --> 00:03:16.239
I was not looking for a full-fledged MPD client. Sometimes MPD-L

00:03:16.240 --> 00:03:22.839
and MPC.L can give you a full UX within Emacs

00:03:22.840 --> 00:03:27.599
and I would absolutely recommend them if that's what you're looking for.

00:03:27.600 --> 00:03:36.039
I wanted to just add a few tweaks to my workflow.

00:03:36.040 --> 00:03:41.039
Now increase the volume while coding, put the track name and the mode line,

00:03:41.040 --> 00:03:46.159
things like that. So I felt like those were a little heavyweight.

00:03:46.160 --> 00:03:53.439
In fact, I ended up corresponding with the author of MPD-L.

00:03:53.440 --> 00:04:00.679
And kind of the analogy I came up with was if, you know, MPD-L is to MPD

00:04:00.680 --> 00:04:03.959
as good news is to email, I wanted to build mail utils.

00:04:03.960 --> 00:04:07.039
I just wanted a couple of very tight little utilities

00:04:07.040 --> 00:04:12.879
that would get me what I wanted. But yeah, actually

00:04:12.880 --> 00:04:15.559
that's also a great callout. Perhaps I should have included references

00:04:15.560 --> 00:04:39.719
to those clients. One thing I will mention is

00:04:39.720 --> 00:04:42.559
I think we've got plenty of time for questions.

00:04:42.560 --> 00:04:47.879
Maybe close to 25 minutes or half an hour, which is very interesting.

00:04:47.880 --> 00:04:51.679
I think in many cases it's been more than the actual length of the talks.

00:04:51.680 --> 00:04:57.039
And I think that's a side effect of sort of, I guess, going with two tracks,

00:04:57.040 --> 00:05:01.879
which is nicer. There's much more breathing room between the talks this year.

00:05:01.880 --> 00:05:05.759
So if there are questions, as long as there are questions coming in,

00:05:05.760 --> 00:05:09.759
or if you do also want to present anything extended, you know,

00:05:09.760 --> 00:05:11.999
more than what you covered in your talk, you're also welcome to do that

00:05:12.000 --> 00:05:14.439
and, like, stay here. So.

00:05:14.440 --> 00:05:20.359
Okay. Cool. Now I'm happy to hang out. This is an interesting question.

NOTE Have you seen the Lonesome Pine Specials?

00:05:20.360 --> 00:05:22.839
Have I seen the Lonesome Pine specials?

00:05:22.840 --> 00:05:28.079
During the talk he saw my music library and figured I'd be interested.

00:05:28.080 --> 00:05:32.279
I have not. But oh, interesting. Bella Fleck. Cool.

00:05:32.280 --> 00:06:10.359
I will be checking out Lonesome Pine, thank you.

00:06:10.360 --> 00:07:27.159
Oh, that's an awesome, awesome tip. Cool.

00:07:27.400 --> 00:07:29.999
That's probably going to be it for the questions.

00:07:30.000 --> 00:07:33.999
Do we just, do we hang out for the balance of the time?

00:07:34.000 --> 00:07:37.679
Yeah, sure. I think there's actually one new question on the pad

00:07:37.680 --> 00:07:40.999
and I might have one to ask as well, but yeah, otherwise we can.

00:07:41.000 --> 00:07:44.399
Oh, apologies. Yeah, I needed to scroll down.

NOTE Would using dynamic/special vars add anything interesting / easier to async elisp in your opinion?

00:07:44.400 --> 00:07:49.679
Would using dynamic special VARs add anything interesting,

00:07:49.680 --> 00:07:55.239
easier to async with? I'm not sure what you mean by

00:07:55.240 --> 00:08:48.159
dynamic or special variables. Can you say a little more?

00:08:48.160 --> 00:08:54.999
Okay, fair enough. I mean, certainly in the examples that I included,

00:08:55.000 --> 00:09:21.919
we could use variables at a larger scope. Yeah, yeah.

00:09:21.920 --> 00:09:31.199
Interesting. Good question. I would have to think on that one.

00:09:31.200 --> 00:09:39.479
To be honest, I went hard down the lexical binding path a few years ago

00:09:39.480 --> 00:09:43.959
when it was introduced to ELISP, precisely because I found dynamic binding

00:09:43.960 --> 00:09:49.239
so much more difficult to reason about. Possibly.

00:09:49.240 --> 00:10:10.119
[Amin]: So I guess one question I might have,

00:10:10.120 --> 00:10:13.479
prefixing it with the fact that I wasn't able to fully follow your talk

00:10:13.480 --> 00:10:16.559
because I've been basically behind the scenes.

NOTE How does your project compare to some of the other MPD clients?

00:10:16.560 --> 00:10:22.079
But how would you say that your project compares to some of the other,

00:10:22.080 --> 00:10:23.879
I guess, MPD clients?

00:10:23.880 --> 00:10:29.359
[Michael]: Yeah, like a couple of years ago, I used to use ncmpcpp myself,

00:10:29.360 --> 00:10:33.159
and also I tried a bunch of different ones.

00:10:33.160 --> 00:10:35.679
I never quite got into using emms as one.

00:10:35.680 --> 00:10:39.359
[Amin]: I noticed that you mentioned that, for example, for some of the other ones,

00:10:39.360 --> 00:10:43.079
maybe like npc.l, yours may be much more lightweight.

00:10:43.080 --> 00:10:47.279
But yeah, I was wondering how you would compare them.

00:10:47.280 --> 00:10:55.639
[Michael]: Yeah, yeah. So those are what I would call full-fledged applications.

00:10:55.640 --> 00:11:00.759
You're familiar with ncmpcpp. You could swap that out as your daily driver

00:11:00.760 --> 00:11:06.039
for any of those. They show you the playlist. They let you browse.

00:11:06.040 --> 00:11:15.079
They let you set up saved playlists, et cetera, et cetera, et cetera.

00:11:15.080 --> 00:11:19.479
And this does none of that. This is basically a building block.

00:11:19.480 --> 00:11:23.599
These are building blocks for building up Emacs commands.

00:11:23.600 --> 00:11:31.879
So for instance, I actually have a little minor mode that holds the key cord.

00:11:31.880 --> 00:11:36.079
You can adjust the volume. You can skip to the next track.

00:11:36.080 --> 00:11:44.439
You can do a few things like that. But that's it.

00:11:44.440 --> 00:11:48.839
More of a tool kit than an application, I guess, is the way I would put it.

00:11:48.840 --> 00:11:55.039
[Amin]: Right, right. Makes a lot of sense.

NOTE Can you share the code to the macro that creates the callback tree?

00:11:55.040 --> 00:12:05.599
Awesome. Another question. Can I share the code to the macro?

00:12:05.600 --> 00:12:15.599
Help a bit for folks.

00:12:15.640 --> 00:12:22.519
And it's on OPA. Let me share a link here. Or

00:12:22.520 --> 00:12:26.879
I guess maybe GitHub would be the better UX. I can do that right now.

00:12:26.880 --> 00:12:27.599
Let's see here.

00:12:27.600 --> 00:12:32.559
I'll put it in the pad.

00:12:32.560 --> 00:12:34.199
Don't judge me. It's my first list macro.

00:12:34.240 --> 00:12:44.639
OK. So I can do that. I can do that. I can do that. I can do that.

00:12:44.640 --> 00:13:11.279
I can do that. I can do that. I can do that. I can do that.

00:13:11.280 --> 00:13:22.559
[Amin]: I think we got all the questions. I think this is an interesting sort of,

00:13:22.560 --> 00:13:26.399
I guess, topic or thing that's come up today. I think multiple times,

00:13:26.400 --> 00:13:30.919
there was also partly mentioned in RMS's talk as part of the Q&A

00:13:30.920 --> 00:13:33.679
where he was sort of complaining a little bit or saying that

00:13:33.680 --> 00:13:36.839
how he would like to see some of org's features, I guess,

00:13:36.840 --> 00:13:39.799
be decoupled from org or org syntax

00:13:39.800 --> 00:13:42.439
and just be made available either as libraries

00:13:42.440 --> 00:13:45.199
or maybe as smaller minor modes that one could use then

00:13:45.200 --> 00:13:49.279
throughout anywhere else in Emacs. And I think I do agree,

00:13:49.280 --> 00:13:53.559
and especially now in the context of MPD and using it via Emacs,

00:13:53.560 --> 00:13:57.639
I think it's very important to also have libraries or toolkits,

00:13:57.640 --> 00:14:02.519
as you mentioned, to be able to build upon them however you wish. So kudos.

00:14:02.520 --> 00:14:05.439
Thanks so much for working on this. It's very kind of you.

00:14:05.440 --> 00:14:09.359
[Michael]: Yeah, I mean, there was a much remarked upon,

00:14:09.360 --> 00:14:14.679
perhaps even controversial talk at last year's EmacsConf by Carl Voigt,

00:14:14.680 --> 00:14:20.879
if memory serves, proposing that the org mode markup language be sort of

00:14:20.880 --> 00:14:27.279
hoisted out and given a specification, he wanted to call it org down.

00:14:27.280 --> 00:14:30.599
And I think some people, for reasons unclear to me,

00:14:30.600 --> 00:14:32.039
were highly resistant to this.

00:14:32.040 --> 00:14:42.879
But yeah, yeah, mm-hmm, yeah, interesting.

NOTE There's another package (chuntaro?) in addition to wellon's aio that also implements a coroutine trampoline on the emacs event loop. any thoughts on the async/await paradigm generally red/blue functions, etc?

00:14:42.880 --> 00:14:46.959
There's another package, Taro, perhaps,

00:14:46.960 --> 00:14:55.999
pronouncing that phonetically, in addition to Welland's AIO

00:14:56.000 --> 00:15:01.759
that also implements a coroutine trampoline on the Emacs event loop.

00:15:01.760 --> 00:15:03.439
Interesting.

NOTE Any thoughts on the async await paradigm generally, red-blue functions, etc.?

00:15:03.440 --> 00:15:07.759
Any thoughts on the async await paradigm generally, red-blue functions,

00:15:07.760 --> 00:15:10.879
et cetera? Oh, wow.

00:15:10.880 --> 00:15:18.799
What color are my functions could be the topic of another talk in and of itself.

00:15:18.800 --> 00:15:24.239
Yeah, that's sort of the problem with async, isn't it? It's like a virus

00:15:24.240 --> 00:15:26.399
that infects your code base once you start.

00:15:26.400 --> 00:15:31.959
And having spent a fair amount of time in the past year or two

00:15:31.960 --> 00:15:36.959
writing async rust, I guess I've kind of made my peace with it.

00:15:36.960 --> 00:15:39.639
I was highly resistant to it at first.

00:15:39.640 --> 00:15:46.919
But who is that venture capitalist that diagrammed

00:15:46.920 --> 00:15:50.079
the uptake of new technology? And at first,

00:15:50.080 --> 00:15:53.919
you sort of saw this exponential curve of enthusiasm,

00:15:53.920 --> 00:15:57.079
then a peak, and you called it the valley of despair,

00:15:57.080 --> 00:16:00.439
and then sort of a plateau of acceptance.

00:16:00.440 --> 00:16:05.519
I kind of feel like asynchronous programming is kind of the hot new topic,

00:16:05.520 --> 00:16:12.239
and everybody's diving in, including in scenarios

00:16:12.240 --> 00:16:14.639
where I'm not sure I see the benefit

00:16:14.640 --> 00:16:16.919
to the additional complexity to your program.

00:16:16.920 --> 00:16:23.719
So I did it here because, as I tried to demonstrate,

00:16:23.720 --> 00:16:28.319
response latency back to the MPD server

00:16:28.320 --> 00:16:34.639
can reach into the realm of human perception, depending on the query.

00:16:34.640 --> 00:16:37.519
And my use case was, I'm in a buffer coding.

00:16:37.520 --> 00:16:42.279
I just want to quick adjust the volume, and I didn't want any pauses.

00:16:42.280 --> 00:16:48.279
But in a lot of other scenarios, I just don't see the benefit to.

00:16:48.280 --> 00:16:55.959
So yeah, I mean, that's my two cents.

00:16:55.960 --> 00:17:07.759
Yeah, I think there's a lot of care to be taken, well,

00:17:07.760 --> 00:17:12.599
I guess in both in advance consideration, but also while implementation,

00:17:12.600 --> 00:17:15.839
if one is going to add asynchronicity to an existing code base

00:17:15.840 --> 00:17:20.719
and making sure to cover essentially as many as existing workflows

00:17:20.720 --> 00:17:23.239
and code paths as possible.

00:17:23.240 --> 00:17:27.879
Yeah, exactly, exactly.

00:17:27.880 --> 00:17:31.799
You know, I've certainly gotten myself into trouble writing asynchronous code

00:17:31.800 --> 00:17:36.039
and locked up the async runtime, and it's like, well, you know,

00:17:36.040 --> 00:17:39.759
is the benefit worth it? I mean, look, if you're building a socket server

00:17:39.760 --> 00:17:51.399
of some sort, like a web service, microservice type of thing, all

00:17:51.400 --> 00:17:54.999
of the famous 10k connection problem from the last decade,

00:17:55.000 --> 00:18:01.319
if you're writing a command line tool, you know, Klee,

00:18:01.320 --> 00:19:17.759
I'm not sure why you need to spin up anything to run time for that. Yeah,

00:19:17.760 --> 00:19:44.399
I mean, I'm not sure why you need to spin up anything to run time for that.

00:19:44.400 --> 00:20:10.399
Yeah. Yeah. Yeah. Yeah, I mean, I'm not sure why you need

00:20:10.400 --> 00:20:14.239
to spin up anything to run time for that. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

00:20:14.240 --> 00:20:18.399
Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

00:20:18.400 --> 00:20:20.919
We'll definitely be checking. It's. So, Centauro appears to be the author.

00:20:20.920 --> 00:20:24.999
The package name is called Emacs Promise. Interesting. Okay,

00:20:25.000 --> 00:20:29.039
I see you reacting, I just wanted to check out if my mic is working.

00:20:29.040 --> 00:20:30.999
The talk, thank you for your interesting talk.

00:20:31.000 --> 00:20:33.599
That's a yak. I already shaved myself

00:20:33.600 --> 00:20:36.639
how to do async programming in Emacs.

00:20:36.640 --> 00:20:39.679
I found about the TQQ and I improved on it, too,

00:20:39.680 --> 00:20:42.919
and then I was thinking, okay, async programming.

00:20:42.920 --> 00:20:49.079
It wasn't how to do macros, but it was my whole into, yes,

00:20:49.080 --> 00:20:51.679
how to do async programming without callback hell.

00:20:51.680 --> 00:20:54.719
And as you said in your title, you did async before it was cool,

00:20:54.720 --> 00:20:58.679
because you often hear the opinion that Emacs doesn't do multithreading,

00:20:58.680 --> 00:21:02.639
it's just single threaded and therefore old and useless.

00:21:02.640 --> 00:21:06.319
Not like that, maybe.

NOTE Do you think it's a viable future for Emacs to get out of callback hell?

00:21:06.320 --> 00:21:10.599
The solution you found, do you think it's a viable future

00:21:10.600 --> 00:21:13.399
for Emacs to get out of callback hell?

00:21:13.400 --> 00:21:22.279
I think so, but I would certainly, in the pad,

00:21:22.280 --> 00:21:25.119
somebody pointed out that Christopher Wellens

00:21:25.120 --> 00:21:28.959
came up with a general purpose async await library

00:21:28.960 --> 00:21:32.839
that I will definitely be taking a look at,

00:21:32.840 --> 00:21:36.359
because I think he used the phrase yak shaving

00:21:36.360 --> 00:21:38.839
and that's absolutely what I was doing here.

00:21:38.840 --> 00:21:45.559
So this solution is purpose-built to my little personal problem.

00:21:45.560 --> 00:21:53.999
It sounds like Wellens may have solved the problem in greater generality.

00:21:54.000 --> 00:21:56.439
But yeah, absolutely. I mean, periodically

00:21:56.440 --> 00:22:00.999
in the Emacs IRC channel or an Emacs devil, somebody will say, oh my God,

00:22:01.000 --> 00:22:07.639
I can't believe Emacs is single threaded, this is hopeless, and yeah, I think

00:22:07.640 --> 00:22:10.159
that here's another use case for asynchronous problem.

00:22:10.160 --> 00:22:22.319
It's interesting that you mentioned like the AIO from Christopher Wellens,

00:22:22.320 --> 00:22:24.159
because I had a look at it too.

00:22:24.160 --> 00:22:28.919
And if I remember correctly, he uses Emacs generators.

00:22:28.920 --> 00:22:37.799
I'm not really sure, I'm not sure anymore if that's the case. But yeah,

00:22:37.800 --> 00:22:48.199
that's another cool macro use to get out of callback Emacs generators.

00:22:48.200 --> 00:22:55.399
Did you see it already? I'm looking at it right now for the first time,

00:22:55.400 --> 00:23:02.279
oh gosh, look at this. And if you want, I can spare you a lot of time,

00:23:02.280 --> 00:23:07.439
because if you go down this road and you get the same direction as me,

00:23:07.440 --> 00:23:10.599
you'll find out like, okay, that's a cool solution.

00:23:10.600 --> 00:23:13.519
You already mentioned Go, the solution Go uses

00:23:13.520 --> 00:23:15.799
with the coroutines or green threads

00:23:15.800 --> 00:23:22.359
or whatever you name it. And I think, in my opinion, the best solution

00:23:22.360 --> 00:23:28.159
or the neatest solution of this problem in this plant or in general is Futures,

00:23:28.160 --> 00:23:33.319
no, not Futures, wrong name, host called, no, I just forgot.

00:23:33.320 --> 00:23:41.839
It's a guy's scheme, and it's from Andy Wingo. And he does it with fibers,

00:23:41.840 --> 00:23:49.439
not Futures, fibers, this is a really good solution for the problem of how

00:23:49.440 --> 00:23:55.119
to do async, how to do multi-color functions

00:23:55.120 --> 00:23:57.719
and say they have all functions the same name.

00:23:57.720 --> 00:24:05.599
And it's fundamentally based on concurrent ML, and yeah, fibers on top, this

00:24:05.600 --> 00:24:09.079
is cool. I would like to see this in the mix. Interesting.

00:24:09.080 --> 00:24:13.559
So I found this talk, Channels, Concurrency, and Cores,

00:24:13.560 --> 00:24:16.679
a New Concurrent ML Implementation.

00:24:16.680 --> 00:24:18.439
This one, yes.

00:24:18.440 --> 00:24:34.719
Okay, I will be taking a look at this, thank you.

00:24:34.720 --> 00:24:35.759
You're welcome.

00:24:35.760 --> 00:24:39.319
Maybe to expand on this, if you don't mind. Please.

NOTE Generators

00:24:39.320 --> 00:24:44.919
The idea behind it is like Chris Wellon uses generators,

00:24:44.920 --> 00:24:47.399
generators like in Python generators,

00:24:47.400 --> 00:24:49.599
like you have some function, and it can yield,

00:24:49.600 --> 00:24:54.279
and you can start it again at this point, and so on and so on.

00:24:54.280 --> 00:25:00.559
It's an Emacs, and it's a hack. It uses a macro for the code processing,

00:25:00.560 --> 00:25:02.879
and then it's bits of callbacks, more or less.

00:25:02.880 --> 00:25:07.759
And it's a solution for like how do I specify callbacks

00:25:07.760 --> 00:25:15.039
without writing actually callbacks with writing synchronous looking one color.

00:25:15.040 --> 00:25:20.759
And the general solution, and that's the reason Andy Wingo can do it in Guile,

00:25:20.760 --> 00:25:27.519
for them is the limited continuations. You have a delimited continuation,

00:25:27.520 --> 00:25:30.639
that means you have a point in your program where you can yield,

00:25:30.640 --> 00:25:35.639
and it yields until a prompt, like it yields a part of your code.

00:25:35.640 --> 00:25:38.839
What that means is your code can stop

00:25:38.840 --> 00:25:43.239
and pass the rest of the computation to something else,

00:25:43.240 --> 00:25:46.319
and this something else can invoke the computation.

00:25:46.320 --> 00:25:48.079
That means you can have a scheduler.

00:25:48.080 --> 00:25:56.839
And How do you arrange for your continuation to be restarted or all can again?

00:25:56.840 --> 00:26:04.119
Good question. That's exactly the thing the Fibers does, like the scheduler.

00:26:04.120 --> 00:26:08.559
You could put it like an Apollo interface, even in Linux,

00:26:08.560 --> 00:26:14.239
which Apollo network connection or a file creation, something like that,

00:26:14.240 --> 00:26:15.079
or a socket.

00:26:15.080 --> 00:26:17.119
Interesting.

00:26:17.120 --> 00:26:21.799
This sounds not dissimilar from what I understand goes coroutines to be.

00:26:21.800 --> 00:26:25.319
This is coroutines, more or less.

00:26:25.320 --> 00:26:26.079
Right.

00:26:26.080 --> 00:26:31.839
These are the things you can do when you have

00:26:31.840 --> 00:26:34.799
like Andy Wingo can do it in Guile

00:26:34.800 --> 00:26:36.919
because he's got his fingers into the interpreter.

00:26:36.920 --> 00:26:43.119
Yes, he does. He sort of got inside knowledge.

00:26:43.120 --> 00:26:49.639
I don't know.

00:26:49.640 --> 00:26:51.919
Yeah, I think so, too.

00:26:51.920 --> 00:26:53.919
He implemented the delimited continuations,

00:26:53.920 --> 00:26:59.759
but yes, it was maybe my point I wanted to make.

00:26:59.760 --> 00:27:01.359
Like there's a neat solution.

00:27:01.360 --> 00:27:04.719
Sometimes you need these delimited continuations

00:27:04.720 --> 00:27:12.279
and function-wise you need like some kind of callback.

00:27:12.280 --> 00:27:16.999
Actually, you always need some kind of callback. You just hide it, well,

00:27:17.000 --> 00:27:20.439
and you call the delimited continuation.

00:27:20.440 --> 00:27:20.639
Right.

00:27:20.640 --> 00:27:25.919
I mean, if you've ever tried to do asynchronous programming,

00:27:25.920 --> 00:27:33.679
say, in C using EpoL, sort of wind up structuring your entire program

00:27:33.680 --> 00:27:40.759
around this event loop and kind of you sort of have this state

00:27:40.760 --> 00:27:45.039
that you move through as various things get signaled,

00:27:45.040 --> 00:27:49.159
whether data shows up on a file descriptor or a timer goes off, whatever.

00:27:49.160 --> 00:27:52.159
And it's kind of mind-bending.

00:27:52.160 --> 00:27:53.559
It's definitely, you know,

00:27:53.560 --> 00:27:57.639
humans seem to be most comfortable writing imperatively.

00:27:57.640 --> 00:28:04.159
And so whether it's Ruster or Golang or JavaScript, it all seems to be like,

00:28:04.160 --> 00:28:07.119
how can we wrap that state machine more ergonomically?

00:28:07.120 --> 00:28:12.999
Yes, exactly. How much more time do we have for Q&A?

00:28:13.000 --> 00:28:31.119
I think we have about seven and a half, eight more minutes.

00:28:31.120 --> 00:28:37.439
Yeah. We don't have to use all of it if there are no questions,

00:28:37.440 --> 00:28:39.439
but you're also welcome to hang out if you want.

00:28:39.440 --> 00:28:41.519
I'm happy to wait.

00:28:41.520 --> 00:28:42.839
Cool.

00:28:42.840 --> 00:28:52.519
And also, if there are no questions, I mean,

00:28:52.520 --> 00:28:55.119
one thing we could maybe do is to, if you

00:28:55.120 --> 00:28:58.079
like to maybe give a quick demo, like walk through some of the parts of,

00:28:58.080 --> 00:29:00.999
you know, your package, your code that could also work whichever,

00:29:01.000 --> 00:29:02.239
whatever you're more comfortable with.

00:29:02.240 --> 00:29:07.879
Honestly, I wasn't prepared for a live demo, so.

00:29:07.880 --> 00:29:12.839
Oh, yeah, sure. No worries. Sorry. Don't mean to put you on the spot.

00:29:12.840 --> 00:29:15.439
I'm going to steer clear of that.

00:29:15.440 --> 00:29:16.999
That's fair enough.

00:29:17.000 --> 00:29:17.599
Thank you.

00:29:17.600 --> 00:29:25.199
Okay.  you

00:29:25.200 --> 00:29:25.239


00:29:25.240 --> 00:31:11.719
questions maybe we can wrap it up sounds good

00:31:11.720 --> 00:31:20.999
I actually think I need to check in for my next talk soon

00:31:21.000 --> 00:31:26.519
oh yeah sure all right any last question before we wrap up folks

00:31:26.520 --> 00:32:05.959
all right I think in that case we can go ahead and wrap up

00:32:05.960 --> 00:32:07.919
thanks so much Michael for the great talk

00:32:07.920 --> 00:32:10.359
I very much look forward to checking out your work

00:32:10.360 --> 00:32:11.999
and yeah seeing what what could be done with it

00:32:12.000 --> 00:32:14.719
and using it as a building block and toolkit all right well

00:32:14.720 --> 00:32:17.079
thank you so much

00:32:17.080 --> 00:32:20.079
I feel like I learned as much through the Q&A

00:32:20.080 --> 00:32:22.239
as other people probably did from the talk

00:32:22.240 --> 00:32:22.519
wonderful

00:32:22.520 --> 00:32:24.279
yeah it's great it's a great way to get to know each other

00:32:24.280 --> 00:32:24.839
and get to know each other

00:32:24.840 --> 00:32:25.759
wonderful yeah it's great

00:32:25.760 --> 00:32:29.999
and yeah we were very lucky to be able to do these sort of live Q&A's

00:32:30.000 --> 00:32:33.359
and awesome speakers like yourself just being able to join in

00:32:33.360 --> 00:32:35.439
and yeah just teach and learn

00:32:35.440 --> 00:32:37.999
all right see you in a bit

00:32:38.000 --> 00:32:47.040
awesome yep see you in a little bit bye