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