DAS SURMA: So it's
my turn to tell you about something new
in JavaScript land and the web land, actually. And I have a proposal. JAKE ARCHIBALD: Had we
started, by the way? DAS SURMA: I thought so. JAKE ARCHIBALD: Oh [BLEEP]. Sorry. I didn't realize. I thought you were still
just like, um, might just start soon. DAS SURMA: So. JAKE ARCHIBALD: So. DAS SURMA: We're
trying this once more. Another episode of-- JAKE ARCHIBALD: I
love the sigh there. Like, [SIGH], here we are again. I'm having to talk to Jake. And this time, I have
to present something. Come on. DAS SURMA: Yes. JAKE ARCHIBALD:
Be a bit cheerier. This is YouTube. You know people don't watch
anything for more than-- DAS SURMA: I'm actually really-- JAKE ARCHIBALD: --five
minutes unless you're like, oh my god, this is the
most amazing thing that's ever happened to JavaScript. This is going to be incredible. You know, you're going to
learn so much in this episode. You're going to come away
with your brain to be, like, three times the size it was. It's just-- this is going to
be the best part of your day, if not your whole year. DAS SURMA: Isn't
that how you die, if your brain grows to three
times the original size? I think you die. JAKE ARCHIBALD: I think
the idea is the skull would have to also inflate. DAS SURMA: Oh. So you look like Brain
from "Pinky and the Brain." JAKE ARCHIBALD: Yes. DAS SURMA: Not--
shall we-- now we need to put a
disclaimer on the show. Might make your skull grow if
you watch too much of this. JAKE ARCHIBALD: That's the
new tagline for the show. "HTTP 203--" might
break your skull. DAS SURMA: Great. So I found a new
JavaScript thing that intrigued me
mostly in my role as the maintainer of Commlink-- JAKE ARCHIBALD: Ah. DAS SURMA: --where, you
know, values and workers and main thread pretend
to be in both places, but they're actually not. And then you get into
garbage collection issues because things that
you share will never get garbage collected
because they're being shared. There's been
references being held. And so I have learned more
about this new proposal that is now ship to Chrome
stable, which is weak refs. And I thought, you know what? Let's make a little episode
about all this weak stuff that JavaScript has anyway. JAKE ARCHIBALD: Oh, so we're not
just covering weak references. This is going to be the-- DAS SURMA: Well, we
have a short intro bit about what's been there
so far and why it is the way it is because there are
some weird rough edges. JAKE ARCHIBALD:
Well, stop teasing me and just give me
the information. DAS SURMA: Let's
do it, shall we? OK, so I thought we
start with what actually is a weak reference because
it's been thrown around a lot and just want to
make sure everybody knows what we're talking about. Really what it means is whenever
you have an object and you, quote unquote,
"save" that object in a variable that the
variable is a strong reference to that object. And as long as there's
any variable in your code that has this
object, this object will not get garbage collected
because that will be bad if the stuff you have in
variables suddenly disappeared. Now, a weak reference
is the kind of reference that doesn't prevent
garbage collection. So if there was a way
to have a variable being a weak reference to
an object, if there is no references to an object
or only weak references-- basically no strong
references-- that object is free to get garbage
collected at any point in time, and you might see your
value actually disappear. JAKE ARCHIBALD: OK, so a weak
reference is kind of like-- like, if your weak
reference is actually pointing to the
object, then that's your way of-- you kind
of know, eh, there's probably something else
that's using this right now. DAS SURMA: Maybe. You basically know that it has
not been garbage collected yet. That's pretty much as much
you can deduce from that. And there's already
one little difference that you mentioned there
because just because you give up all strong references
to an object doesn't necessarily
imply that it will be immediately garbage collected. So a weak reference
could theoretically still give you an object even though
there is no strong references to it anymore. And that's a detail
that we're going to get more into
a little bit later because it's an important
distinction to make. JAKE ARCHIBALD: It was-- I heard that. I'm glad you're doing
this talk because I did read the article
on weak references, and I came away still
being quite confused. And it was some
of the uncertainty that I was a bit
like, I don't know, this uncertainty sounds bad. DAS SURMA: So we're going
to have a lot of that because basically, we
have had two weak data types in JavaScript for
actually quite a while. And those are the
WeakMap and the WeakSet. And some might be surprised
that these are fairly old. They were in IE 11. So they've been around
for a long time. JAKE ARCHIBALD: Yes. DAS SURMA: And what these two do
is basically-- in the WeakMap, the key is weak, meaning you
can only get to the value when you have the key. But the key itself is not
prevented from being garbage collected just by the fact that
it's being used in the map. So if you use a dom note
as the key in the WeakMap and don't save this
dom note anywhere else, if it gets garbage collected,
your key and your value can disappear from that map. And that can be
incredibly helpful. I often see
questions on Twitter, sometimes directed
at me, sometimes others, what the use cases
for WeakMap and WeakSet are. And so one of the
prime uses for me is that for the longest
time in JavaScript, expandos, as they're called,
have been fairly common. You just take an object, and
you throw new properties on it. Like, you put just an _mystuff
and put your stuff in there. And you know, that's JavaScript. It works. But one of the downsides is that
it's bad etiquette, basically, to transform objects
that you don't own also because that can
cause the JavaScript runtime to deoptimize
because you're changing the shape, as
it's called, of an object. And so generated binary
code might not work anymore. And they would have
to regenerate it. And so mutating
objects you don't own is often a bad practice. JAKE ARCHIBALD: And there's an
ownership issue here as well, isn't there, because
now, anything else that gets that profile node
can see that internal data. Yeah, because it's
not really private. DAS SURMA: And you can never
be 100% sure that you're not creating a name clash. Maybe in this case, you know,
some library code actually does use _internal. Who knows? And so what you should be doing
instead is create a WeakMap. So in this case, we're getting
something from the dom. And instead of putting something
on the dom node itself, we use the dom node as
a key in our WeakMap and put our extra data into
the value of the weak map. And that means as long
as the dom node exists, the value will
continue to exist. But when the dom node
gets garbage collected, so will the value. And that's really useful. And for a WeakSet, it's
basically for the use case. Whenever you find yourself doing
a WeakMap where you store true in the value, that's
like my prime example. But you just want
to remember, have you visit a certain object? Have you already seen it? Has it already been processed? Those kind of things, that's
where a WeakSet comes in. However, and that
is something that trips some people up or raises
question marks, at least, is that neither of
these are iterable. You cannot iterate over
the keys in the WeakMap. You can't iterate over
the entries in a WeakSet. Weak stuff in general
was never iterable, and that kind of
comes from the fact that one of the fundamental
principles, I think, by the W3C was you should never
expose garbage collection. And the reason for it is
actually from security-- [MUSIC PLAYING] Because exposing
garbage collection is, what I learned when
I researched this, is called a covert
channel because now two pieces of JavaScript
can communicate without ever knowing really
of each other's existence. You can think about
it a little bit that if you bundle two
libraries and you pass, you know, just an object
for one library to another, now the one library
might be able to track when the other library
stops using that. And that could actually--
if those two libraries do it in coordination, you can
communicate a lot through that without ever accessing
each other's data. And I mean, if you
think about cookies, that's how tracking happens. And I think something
like this could be exploited the same way. And so they never wanted to open
this can of worms, basically. However, over time, there were
more and more demands and use cases for actual weak
references and exposing garbage collection. And so over time,
they spend a lot of design work and collaboration
between the engine authors to figure out how
they can make this happen without making
this covert channel an actual problem. And so the weak refs
proposal was born. JAKE ARCHIBALD:
Before we move on to that, like, one of
this model with weak sets and weak references where you
can't iterate on the keys, in some ways, it almost
makes more sense to me because it's that idea of,
like, you can only open the door with a key, right? And if you lose the key, you
can no longer open the door. The equivalence here with
like-- because we don't just have WeakMap and WeakSet. There's also map and
set, which can iterate. And that seems like a kind of
model where I've lost my keys. Uh, I better go and ask
the door for them back. You know? DAS SURMA: Which, fair. JAKE ARCHIBALD: Would be
problematic in general, wouldn't it? DAS SURMA: Yeah, let's not
let real doors be inspired by computer science maps. No, I don't think
that's a good idea. So yeah, so this is where we
now can talk about WeakRef. This is marked as
advanced because it can be fairly hard to reason about. The second garbage
collection is involved, it becomes undeterministic,
unpredictable, and but also because whenever
you use it, think really, really hard if there
isn't a way you can solve the problem
without it because this will be likely to
introduce more bugs than it fixes because it is a fairly
hand wavy spec almost. And we'll talk about
that a bit more. JAKE ARCHIBALD: Well, whether
garbage collection happens isn't specced at all. DAS SURMA: Isn't
spec, and that's one of the underlying problems
for this entire thing. JAKE ARCHIBALD: In fact,
somebody even said to me, like, JavaScript engines are
not required to garbage collect. Like, the spec-- DAS SURMA: We'll get to that. We'll get to that
because that is-- JAKE ARCHIBALD: Oh, OK. DAS SURMA: Basically,
we have weak refs now. And in the end, they do
violate the principle of exposing garbage collection. They do create that
covert channel. But they did spend a lot
of time in the design to make sure that
on the one hand, engines are still
able to optimize and, you know, iterate on
their internal architecture freely without being constrained
by this WeakRef existing and also to limit the bandwidth
of this covert channel to such an extent that the
risks are extremely low to that actually being a real problem. What are these actual problems? Why is this actually
such a, quote unquote, "advanced" topic? Well, the first problem
is that garbage collection is non-obvious or
non-deterministic. For example, if two
values become unreachable at the same time, like, you
give up your strong references at the same time, that does
not mean they will get garbage collected at the same time. Or-- and that is also something
that you might not know. It might look like you
made something unreachable, but it is, in fact, not because
the way that internal data structures work or native
data structures to JavaScript or closures, there might
still be a reference you're just not aware of. And so your reasoning
might just be flawed and really hard to figure
out where it is going wrong. Engines will garbage collect
differently from each other. So something that might
work in one browser or when something gets garbage
collected in one browser, it might not in another. It actually might
get garbage collected in one previous
release of your browser but not in the current one. Or it might get actually garbage
collected in the first run but not in the second run of the
same code on the same website because there's so many factors
that the engine incorporates when to run garbage
collection that it is inherently unpredictable. And this is what I
brought up earlier. Garbage collection and
something being unreachable are inherently separate things. Something being unreachable
is a requirement for it getting
garbage collected, but they basically can be
an arbitrary and infinitely long time in between. Most browsers run
their garbage collector when they feel like the
browser has downtime and only when it's
under memory pressure. So if you're running on
a super beefy machine, garbage collection might
just not happen as a trade off for keeping the page
responsive, snappy, and fast. And so that's just something
to really keep in mind also for the rest of the discussion
that when we talk about garbage collection, we mean the moment
in time when a value is being deleted from memory and the
memory is being freed up, not the point where it's
becoming unreachable for your code. JAKE ARCHIBALD: Yeah,
it's an optimization pass. Like, garbage collection
is optimization. It was weird when I heard
that browsers aren't required to garbage collect or JavaScript
engines aren't required to garbage collect
because it's like, but all the code
everywhere would break if they didn't garbage collect. And it's like, well,
yeah, but never mind. It is something they all do. It's just when they
do it and how they do it is completely unspecified. DAS SURMA: Yeah,
and just to give it a separate point, GC will happen
late or sometimes not at all. That can happen. And actually, there is
a lot of details of this that we'll talk
about a bit later. All right, let's look about
at the actual weak ref API. It is a very, very tiny,
slim API, which is nice. So you create a value. That value has to be an object
because only object gets garbage collected. Things like numbers,
strings, the primitives don't get garbage collected. And you just put
it in a WeakRef. And now you have a
WeakRef to the value. JAKE ARCHIBALD: Wait, no. Wait, wait, wait, wait. I'm confused. No, no, no. No, no, no. OK, strings do get
garbage collected, right? If I create a 100
megabyte string and then lose my
reference to it, it will be garbage collected. I think the difference is that
you can recreate that exact string later whereas you can't-- once you lose
access to an object, you can't recreate that
exact object again. It would be a different
instance of that object. DAS SURMA: I'm not 100% sure on
strings now that you say that. I think strings are special
in that they're not objects and that two strings
you create separately will be considered identical. And I think strings are shared
in like a string pool because of this identity, reference
identity that they have. So I think they will
probably be removed from that pool,
especially large strings. But I think that's not
considered garbage collection. I'm not sure on this one. So we'll probably add something
in the notes of this video. I'm pretty sure you cannot
create a WeakRef to a string. JAKE ARCHIBALD:
Yeah, it's pretty similar to how it can't be the
key to a WeakMap or a WeakSet-- DAS SURMA: Yeah. JAKE ARCHIBALD: --because
you can recreate them again. So the same goes for like
numbers and symbols and, like, null and undefined,
that kind of thing. DAS SURMA: So this
is now a WeakRef. The WeakRef is a weak
reference to the value that I created above. Even if we didn't put the value
in its own variable, which is the strong reference--
like, if we didn't have a single strong
reference, we would be guaranteed that this
value would continue to exist until the next task. So that way, we can
make sure it doesn't get garbage collected immediately. We might have a promise chain. Maybe want to use this value
in the next micro task. That much is guaranteed. And this is not only for
code to work as you expect but also one of these
mitigations for the bandwidth. And that's the
lifetime of the value is elongated so that you
can't communicate as much through garbage collection
just because now it's delayed until the next task. And now we could basically call
.deref on the weak reference to see if the value is still
there at some point later. And then this maybe
value will be undefined if the value had been GCed at
some point between these calls. Or it will be the actual
value if it hasn't. And if we call deref and
get the value, again, that's a new point
in time where we say, OK, now the value
will continue to exist until the next task
at the very least, again, for this
guarantee and to limit the amount of communication
that you can do. JAKE ARCHIBALD: So when you call
deref all right, two questions. Can you call deref
multiple times? DAS SURMA: Yes, as
many times as you like. JAKE ARCHIBALD: And then
the thing you've got is now a strong reference. deref gives you a
strong reference. DAS SURMA: Yes, it gives-- yeah, basically. And so until that
variable ceases to exist. But even then,
the value will not be garbage collected at the
very least until the next task. This is actually one of
the consistency guarantees. So you can have multiple
WeakRefs to the same value, and calling deref on all of
them will always yield the same result. There's no way that
one WeakRef will still have it and the other one won't. Those will always be consistent. So with this, we can
have weak references and hold onto a value
without preventing it from being garbage collected. But actually, sometimes
it's more helpful to have it the other way around where we
get informed when something has been garbage collected
because this way, we don't. We have to check, I guess,
every frame or something. Like, it's really hard. You would have to do
polling, and that's bad. You want to have
the inversion where you get notified when something
gets garbage collected. And that's the other part, the
other half of this proposal. And that is called the
finalization registry. The finalization registry
takes a call back that will be called
whenever a value that you have registered
with the registry gets garbage collected. And you basically register
that value with a held value. And now this is
something that might be confusing to
some people at first because the value that
will be called [INAUDIBLE] not the value that gets
passed into the callback. And that's simply because at
the time the callback is called, the value has already
been garbage collected. Doing it the other way around
where you pass the value in just before it gets
garbage collected could allow you to store
a new strong reference. Then the garbage collector
would have to undo its thing, and it would be way
more complicated. So what you do instead,
you get a separate value that you can pass
in and that can be something for your
internal bookkeeping to know which value
it originally was. Or maybe it's the underlying
resource you want to free up. Whatever. JAKE ARCHIBALD: Can you pass
the same object in twice? No, that's not going to
work because it has to have a strong reference, then. DAS SURMA: Yeah,
so the held value is called held value
because it is strongly held. JAKE ARCHIBALD: Yes. DAS SURMA: I mean, you could
call register sum value sum value. But that would prevent
garbage collection from ever happening
on sum value. JAKE ARCHIBALD: Yes. So this is your
optimization step. So if you've got-- if you've vended an object and
you've got some sort of system where I want to keep
this web socket open while this object
is still being used, this is the pattern
you would use because you get that call
back, and you go, oh, that object's gone now. Now I can do my related
optimizations like, close the web socket. DAS SURMA: Yeah. And this is also important to
note that the callback will be called at the same time the
value gets garbage collected or at some point later in time. And again, this is up for
interpretation by the engine. It can be very, very long
between the actual garbage collection and when this
callback will actually be invoked. JAKE ARCHIBALD: But
what about WeakRef then? Is there guarantees there? Like, could there
be a situation where if I deref a weak
reference, it returns, like, undefined or whatever, but this
callback fires like an hour later or something? DAS SURMA: Yes, I think
that is a possibility. So I think if the
callback has been called, deref will definitely
return undefineds. Deref returning
undefined doesn't require that this callback has
been called because it isn't required to get called at all. And this is what I want to
talk about next because there is no guarantee the
callback will run. And that's why it's so important
that this callback isn't used for critical work. This callback should be used if
a value being garbage collected means you can free up even
more memory internally. It is supposed to allow you to
reduce memory pressure further. It is not supposed to be used
to actually do business logic cleanup work because it
might not ever get called. And so in that case,
you might actually be more wasteful with user
resources than necessary. JAKE ARCHIBALD: Yeah,
you couldn't build, like, an analytics system that tells
you how many objects are around using this because it doesn't
come with those guarantees. DAS SURMA: Yes, so that's
one of the reasons, for example, why this has
been tailored with WebAssembly in mind because WebAssembly
often passes values to JavaScript that represent
something that's actually in WebAssembly memory. And so in that
case, it makes sense because if the
representation in JavaScript gets garbage collected,
meaning the engine thinks it's under
memory pressure, then code can run
to free up even more memory in WebAssembly lands. But if that memory
doesn't get freed, it doesn't inhibit
the functionality of the app or waste
user resources to an unnecessary extent. So as I said, there is no
guarantee that this will run, and there's some-- two things that they
point out makes especially unlikely for them to run. One is if you close the tab
or if you kill the process, there is no need for the
engine or no requirement for the engine to run all the
registered callbacks if you just kill the process. So it shouldn't be used
to do cleanup work when somebody leaves the page. And it's also very unlikely
for these callbacks to run if the registry
itself becomes unreachable by your code. So I guess if the registry gets
garbage collected unreachable, there is no guarantee that
these callbacks will ever be called in the future. Now that we've registered
something to get cleaned up, sometimes we might
discover later on actually, we don't want this callback
handler to run ever and we want to unregister
a certain value. For that to work,
the function register takes a third parameter,
which is the unregisterToken. It's similar to the
held value in that it symbolizes what you need to have
to unregister this one value. In this case, however,
unregisterToken could be the same
thing as sum value because it is not strongly held. But sometimes, it
might be easier for you to use a
different value altogether just for bookkeeping
purposes or keeping it simple or something like that. And then you can just
call it unregister with this unregisterToken, and
that will remove your value from the registry. And now one last method on
the finalization registry, which actually I found really
interesting because it's the first time that I have
seen a normative optional API. That means this API is in
the spec, is specced out, but implementers are not
required to implement it. I think the only other API on
the web that has a similar fate currently are shared
array buffers in that they are specced. They're agreed upon. They're merged and everything. But they're not required
to be implemented to be fully spec complaint. JAKE ARCHIBALD: Is
this the same reason? Is it a security timing thing? DAS SURMA: Yes. I mean, shared array-- you
all know or we have probably heard of the history of
the shared array buffer. That was removed because
of specced out meltdown, and now it's slowly
being incorporated. But they still leave
it up to the engine to decide whether they
want to enable them. If they don't-- basically,
browsers who hadn't shipped any mitigation or founded a
good mitigation shouldn't be considered spec incompliant-- uncompliant? Incompliant? JAKE ARCHIBALD:
Incompliant, I think it is. DAS SURMA: Whatever
it is, don't say that about the
browser that doesn't have shared array buffer because
it's a very tough problem. That's basically the
thinking behind it. And this apparently had a
long discussion behind it, which I'm not going
to try to summarize. But some browsers didn't
want to ship this. Other browsers did
want to ship with it. There was basically
a big contention around should this
ever be-- because it's a synchronous API
that runs callbacks on amount of values that
might have been garbage collected-- oh, sorry. I should explain what
this function does first. So the function is
called clean up sum, and that is basically saying,
hey, if you have a chance, call all the callbacks
for the values that have been garbage collected
if you haven't called the callback on them just yet. So you're kind of opting
like, hey, I would like to process these things now. I'm actually kind
of surprised they made it optional because it
would be just as spec compliant to make it a no-op
because you don't have to run the callbacks. You can say, like, no,
not running anything. JAKE ARCHIBALD: It's just
a little poke, isn't it? It's just like please,
please, please. DAS SURMA: But there were
browser vendors disagreeing on whether this is good for
the main thread or not. And so in the end,
they just made it normative optional
to implement this. And it currently looks
like, at least on the web, we will only be shipping
it in workers, not on the main thread, which I
thought is quite interesting. So you do have to check
whether this method exists before calling it. And this is where optional
chaining comes in super handy. We just do a little question
mark dot parentheses, and then it will be called
only if that function actually exists. JAKE ARCHIBALD: And
that's not the first thing that's happened with
in JavaScript, right? Because we've got-- there's
the atomic stuff, right? There's methods on atomics that
are only in workers as well. DAS SURMA: Yeah. And so, yeah, just
keep in mind you need to check before it's there. And again, this method is just a
request to run these callbacks. There is no requirement
from the browser to actually process,
call any callbacks, or process any values. That's what I mean. Like, this entire
API is very much trying to leave this freedom
for the engine implementers to allow them to implement
better garbage collection algorithms in the future
so that they're not constrained by WeakRefs
and finalization registry. And so it is very-- you need to be very careful
when working with this. One thing I want to close
with-- that with this, you can now actually
build an iterable WeakMap. And interestingly
enough, there's an entire implementation
of this in the explainer. That is, I have a link here--
bit.ly/iterable-weak-map if you want to look at that. I'm not going to go through
it here because of things to track to make sure that
everything is garbage correctly and so on and so forth. But if you're
curious, take a look. The WeakRefs
implementation has shipped in current stable Chrome. I have actually merged
it into Commlink. So if your browser
supports WeakRefs, I will automatically
garbage collect stuff across the
worker boundary now, which I think is kind of cool. So yeah, try it out. Play around with it,
but remain careful too. JAKE ARCHIBALD: Do we
have enough time for you to quickly describe how
you used it in Commlink? DAS SURMA: Commlink,
what it does is you have a value in a worker. And you basically create
a proxy on the main thread saying like, you, proxy. Behave like that
object in the worker. And then under the hood, I
use a message passing protocol to say, this person
wants to access property A. Send me the
value of property A, please. And then this
round trip happens. What I'm doing now is basically
have a simple reference counting algorithm. Whenever a proxy is created,
I increment that counter. And previously, I had an
explicit release function. I still have that, an
explicit release function. Like, I don't need
this proxy anymore. That decreases the counter. And when the counter
reaches zero, that thing can get
garbage collected-- on the worker side, that is. Now you implicitly call that
function when the proxy gets garbage collected. And you can opt in off that. You can opt out of that. JAKE ARCHIBALD: Nice. DAS SURMA: But this--
again, like, this is-- if there is
memory pressure, it might be useful
for the engine that I release unused objects
in the worker side as well. And so I pretty much
just use a WeakRef-- finalization registry,
sorry-- to get a notification this proxy has been released. And then I can decrease the
count on the worker side and just let go of
the message channels once that counter reaches zero. JAKE ARCHIBALD: You should say,
this is super advanced stuff, and anyone watching
this shouldn't be like, oh, my code doesn't
use weak references. I should go and add
them in somehow. Like, don't do that. DAS SURMA: Please don't. JAKE ARCHIBALD: Yeah. DAS SURMA: Don't. Please don't. JAKE ARCHIBALD: But
it is just enabling these couple of
edge cases where you can make extra optimizations. Or like you say,
you can avoid a case where you have to call
an explicit destructor, like, release function
or something like that. DAS SURMA: Yeah. Yeah, for me, obviously
the most exciting part is the WebAssembly
bit where you now get a deeper integration
between the garbage collector and JavaScript and
your memory and WebAssembly. So this is the
first stepping stone towards getting garbage
collected languages to WebAssembly without having to
ship your own garbage collector code in WebAssembly. So that's-- JAKE ARCHIBALD: Got you. DAS SURMA: It's not
the whole story, but it's the first puzzle piece. And so I'm obviously
thinking ahead and quite excited
about the prospect of having managed
languages be smaller and, I guess, better
in WebAssembly. JAKE ARCHIBALD: Cool. Well, we'll link to
the VA article, and-- DAS SURMA: Yes. JAKE ARCHIBALD: --Commlink. Will show where you're
using it in Commlink. DAS SURMA: Why not? JAKE ARCHIBALD: Yeah,
that's good, actually. I do now understand it a lot
better than I did before. DAS SURMA: I'm glad. JAKE ARCHIBALD:
Well done, Surma. DAS SURMA: Well done, me. JAKE ARCHIBALD: It's super
advanced, this stuff. And, like-- DAS SURMA: Yeah. JAKE ARCHIBALD:
--anyone watching this-- and anyone watching this
shouldn't-- oh, Christ. Jesus, I'm out of practice. We should say, though, that
this is super advanced stuff.
