May 31, 2025 • 46 mins
Web browsers and web sites have been around for quite a while. Javascript has been the language driving those pages but there's a way to write in a lower-level language and speed up the slow parts without losing cross-platform compatibility. That way is called Web Assembly (WASM). In this episode Jim explains exactly what that is, and Wolf asks questions.
Show notes:
Take-aways from the episode:
- If you have a compute intensive part of your web application, it may make sense to implement that bit of code in a compiled language like C, C++ or Rust and then compile them to WASM so they can be executed in the browser.
- Security and Portability. WASM code is secure as it utilizes the browsers' sandbox and portable as all browsers are supporting the W3C Standard WASM.
- You are almost certainly using WASM based applications. It's in use in Google Maps & Docs, Netflix, Spotify, Amazon and many more.
Links:
- https://emscripten.org/index.html
- https://emscripten.org/docs/getting_started/Tutorial.html - Nice tutorial
- https://github.com/WebAssembly/wabt - Web Assembly Binary Toolkit
- https://collabnix.com/top-20-companies-that-uses-wasm/ - Companies using WASM
- https://developer.mozilla.org/en-US/docs/WebAssembly/Reference - WASM Instruction set
- https://developer.fermyon.com/wasm-languages/webassembly-language-support - Languages supported
- https://github.com/snaplet/postgres-wasm - Postgres implemented in WASM
Hosts:
Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm
Follow us on Mastodon: @RuntimeArguments@hachyderm.io
If you have feedback for us, please send it to feedback@RuntimeArguments.fm
Theme music:
Dawn by nuer self, from the album Digital Sky
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Wolf (00:03):
Welcome back to another episode of Runtime Arguments
with Jim and Wolf.
Uh we've both been curioussoftware engineers for quite a
while, and each episode we tryto learn something new or report
on things we've built or doneand share it.
Um topics we've covered so farhave mostly been questions that
(00:24):
came up in our conversationsover lunch, and usually tack or
tack adjacent.
We're just starting out in thispodcast world, uh, and we
appreciate you listening andhelping us get better.
Um I'm Wolf, and my friend andpartner in this show is Jim
McQuillen.
(00:44):
How are you doing, Jim?
SPEAKER_01 (00:47):
Oh, Wolf, I'm doing great, and I'm really excited
about this episode we've got foryou today.
Wolf (00:54):
Um we have gotten uh more feedback, which we love and
value.
Uh we want to get this wholething right uh and we want to
get better.
Feedback drives those things.
If you have feedback, you canreach us on Mastodon uh
runtimearguments at hackyderm.ioor by email feedback at
(01:17):
runtimearguments.fm.
Those will both be in the shownotes.
Um two pieces of feedback toshare with you from previous
episodes.
Let's start with thoughts on uhJim's cloud transition.
Jim.
SPEAKER_01 (01:33):
On our May 3rd episode, we talked about my
adventure moving from the datacenter to the cloud.
My old friend John uh uh he sentme some feedback saying that
that's a really good case studyfor uh highlighting just how
little resources you need.
Um it turns out uh most peoplethink they want the most
(01:56):
powerful server they can get,but you really don't need that.
Uh and as I showed in thatepisode, I'm using a very small
uh server with very low RAM torun lots of Docker containers,
and it's performing really quitewell.
Wolf (02:10):
Um we also got a little bit of feedback um in person uh
on our pass keys episode.
Our good friend Ron pointed outthat um he's been he's been
using a password manager, uh, inparticular one password, but
right now for every passwordmanager that we looked at, there
(02:33):
is no import or export of passkeys.
Um that is a thing they areworking on.
It doesn't look like it's vendorlock-in.
It looks like um the passkeypeople are trying to uh f come
up with a uh standard for howthat's going to happen.
(02:57):
Um there was one other thing Iwanted to mention, not on pass
keys, but on crypto, uh, andthat is um our very paranoid
friend, and and I'm paranoidtoo, so I respect this.
Our very paranoid friend Ron uhtook my uh thoughts that you
don't want to have a walletmanaged by a broker with a ton
(03:20):
of crypto in it, and he said,Well, what about where you have
two wallets, one you manageyourself, and that's where you
really keep all your money, andone that you keep on the
brokerage so that you can doexchanges and you just move the
money just in time.
So that was another thing thatwas pointed out.
Um that's our feedback.
SPEAKER_01 (03:43):
Yeah, that that that idea of two accounts, that's I
mean, that's how a lot of peopledo it with a normal bank, moving
money uh between accounts sothat if somebody hacks into your
your uh uh your checkingaccount, they can't take all
your money.
Yeah.
They only can take what what youput there.
Wolf (04:03):
Uh doesn't work that way for me because my checking
account doesn't have very muchmoney.
Um so let's actually get intothis episode.
I'm gonna hand it over to Jim.
He did all the research thistime.
Uh Jim, start us up.
SPEAKER_01 (04:20):
Yeah, I think today's episode is gonna be a
little bit different, maybe moreconversational, because uh uh
this is just something that Iresearched and I I talked a lot
with Wolf about.
Uh so we're just gonna sort oflay out what we learned.
Um years and years ago, I playedwith assembly language.
I I uh I did some x86.
(04:41):
Uh if you remember back in thedays of MS DOS, I I was writing
um um TSRs, the Terminate andStay Residence programs that
you'd run in a in a DOSenvironment that would run kind
of in the background, althoughDOS was not a uh multi
multi-threaded uh environment.
Um but I'd write uh littleservice interrupts that would
(05:02):
run when an interrupt happens,like a clock tick or a keyboard
or something, it would fire offthis little bit of assembly
code.
Um I also did some uh 6502 and6510 assembly.
Uh you know, of course, I Istarted like a lot of people
with uh a Commodore VIC-20 andthen moved up to a Commodore 64,
and those are the processes,processors that those computers
(05:26):
used.
And I played a lot with uhwriting assembly language code
on those.
Sort of cut my teeth on that.
And then as I moved into theprofessional world, I did some
assembly language on a TMS 9900chip, and that was the text
instruments, that's what theyput in their business systems.
I think they also put them intheir their little uh home
microcomputers too.
(05:47):
But I I uh I was writing COBOLcode back then, and we need to
we needed to run some thingsfaster.
Like COBOL didn't have a sortverb just for sorting arrays, so
I wrote something in assemblylanguage to sort an array.
Um and we would call that fromCOBOL, we would call out to the
assembly language routine, andit was much, much faster than
(06:08):
trying to do trying to implementit just in COBOL, or or the
COBOL way was to write it out toa file and then sort that file,
which was kind of silly.
Anyway, I I I do have someassembly language uh experience,
and Wolf, I think you said youyou dabbled in assembly language
as well.
Wolf (06:24):
I have um I've written assembly language for the 68,000
um for the x86, of course.
Um uh I'm trying to rememberwhat else.
I keep meaning oh, the PowerPC.
I wrote wrote code for that.
Uh I keep meaning to write stuffum that runs on an ARM chip.
(06:48):
I'm particularly interested inthe the M chips from Apple.
That would be interesting to me,and I just never seem to get
around to it.
SPEAKER_01 (06:56):
Cool.
Well, the reason why I'm talkingabout assembly language is uh at
one of our one of our lunchesseveral weeks ago, I I had seen
an article that somebody hadimplemented Postgres in
WebAssembly.
And I what is that?
I I'd heard of WASM, I've heardof WebAssembly, but I wow,
(07:18):
somebody's doing Postgres inthat?
That's that's pretty neat.
Uh so I thought that might be aninteresting thing to dive into
and learn about.
And WebAssembly, um, or or it'spronounced WASM, W-A-S-M.
It's it's kind of likeJavaScript, yet not at all like
(07:38):
JavaScript.
Uh, it runs in the browser, uh,although it can run server-side
in like node if you want it.
Um, but it's uh it's it's uhit's very much assembly language
like.
It's got an instruction set.
Uh, you know, when you writeassembly language, you write it
for a particular CPU, usually.
(07:58):
Uh you might write assemblylanguage for an x86 or uh or a
6502.
Well, you can write assemblylanguage for WASM and uh WASM.
Um it there's an instructionset.
Uh it's uh there's a stack-baseduh virtual machine that runs and
interprets that uh assemblylanguage code.
Wolf (08:20):
Wait, wait, can I ask you a question?
Yeah, yeah, yeah, yeah.
Um so I I know some of thethings you were doing to
research this, and I have someknowledge of WASM, uh, but
suddenly it occurs to me, do youactually can a person actually
(08:40):
write WASM?
Can you sit down in your editorand type the instructions in and
have it run?
SPEAKER_01 (08:46):
Yes, absolutely.
There are uh tools to to let youdo that.
So for you to type it and andassemble it into a binary file
that's that's uh consumable bythe browser.
So yeah, you certainly can.
It wasn't it wasn't written tobe human writable and human
readable, although you can writeit.
(09:08):
It's really meant to betranslated from another
language, like C or C ⁇ .
Wolf (09:13):
I feel like um this is a lot in this is a lot like
Postscript.
SPEAKER_01 (09:21):
Yeah, kind of.
Postscript is uh is astack-based language.
Uh I I I've written a fairamount of PostScript in my time,
and it's uh it's not exactlyhuman, it's not exactly intended
for a human to to write or read,but it's sort do certainly
doable.
(09:41):
So yeah.
Um the the the benefit of usingWebAssembly though is it
executes much faster.
Uh it's at near native speeds inthe browser, faster than than
JavaScript, certainly.
Um it's uh it's an attempt to uhto to for you to write code that
(10:05):
needs to perform well in thebrowser, uh where you might not
be happy with uh the performanceof JavaScript.
Um so in my in my digging intothis, I I looked at all kinds of
things.
And and uh first off, uh wheredid it come from?
Um it was written by uhinitially created by uh the
(10:26):
World Wide Web Consortium, uhW3C.
It was a successor to somethingcalled ASM.js, which was like a
subset of JavaScript, uhintended to be fast, um, but it
wasn't a standard.
Uh so Wasm was was kind of uhcreated as a standard way to
(10:47):
write fast code for a browser.
Uh it's first uh the the firstpublic announcement was in June
of 2015.
So we're at like, I mean, nextmonth we're gonna be at uh at 10
years.
Um actually when this when thisepisode comes out, it'll be 10
years since uh WASM was was uhinitially announced.
(11:10):
Um the first viable product, theminimum viable product, uh what
came out in 2017.
Uh and at that time in Septemberof 2017, it came out on Safari,
that was Safari 11 uh for Applepeople, and November 2017, all
major browsers uh supported it.
Um so it's you know it's it'sbeen out there for real use uh
(11:34):
for eight years now.
Um the the people in charge, W3Cis still in charge of it, but
also uh Mozilla, Microsoft,Google, and Apple are all
working uh on this, uh helpingdevelop it, uh, help helping to
keep it going.
So it's got a lot of supportfrom from the big players.
It's it's an important piece oftechnology, I think.
(11:55):
Um that that that these bigcompanies are are behind.
So I think that's good.
Wolf (12:01):
Um why exactly I'm trying to figure out what the place of
Wasm is in in the world.
I mean, people are usually usingtheir browser, that's sort of
the center of user interactionwith stuff that exists today,
uh, or else they're on theirphone and they're using an app
(12:23):
that does the exact same thing.
But my question is um what doesWASM do uh in this world?
Where does it fit?
Where does it come from?
Um tell me more about theperformance.
Why is it better?
Uh does it follow the same rulesas JavaScript?
(12:44):
Um fill me in.
SPEAKER_01 (12:46):
Well, it's uh uh yeah, the the I think the
primary goal is it's faster,faster than JavaScript.
Uh I I think that gap might beshrinking a little bit as
JavaScript uh is is continuallyuh uh getting better with their
just-in-time compilers and andstuff.
But wasm is still quite a bitfaster than JavaScript.
(13:10):
Uh it follows all the samerules.
It runs in a sandboxedenvironment within the browser,
so it doesn't by default haveaccess to any local resources.
You can't you can't uh uh send aWASM program to somebody's
browser that has that couldaccess their hard drive uh or
anything else in their computerunless that person gives it
(13:31):
explicit permission to do that.
Wolf (13:34):
Um let me ask you, uh I I just absolutely don't know the
answer to this.
Um does WASM see the same thingsthat JavaScript can see?
Does it have an interface to theDOM?
Can it can it m do things toyour web page?
SPEAKER_01 (13:54):
Uh WASM doesn't have direct uh access to the DOM.
It goes through JavaScript toget that.
There's a real nice interfacebetween WASM and JavaScript.
Uh WASM can call JavaScriptroutines and JavaScript can call
Wasm.
So it's a it's a nice back andforth thing.
Uh so getting to the DOM, um yougo through the the JavaScript
(14:17):
layer to do it.
Uh I I don't think that's wherethe performance uh benefit
happens.
Uh I think the the performanceis more on just the raw uh uh
processing of data.
Um you know maybe you've got umsome uh encryption uh uh
(14:38):
routines you want to run.
Maybe you want to encrypt data.
Uh uh you could write that codein in C, compile it onto Wasm,
and then run that in thebrowser.
Um I think that would run muchfaster than a JavaScript
implementation of that codewould.
Uh yeah.
When it comes to accessing theDOM, yeah, you'd go through
JavaScript to do that.
Wolf (15:00):
It sounds like um since WASM and JavaScript can talk to
each other, um, they must, Iknow there's sandboxes involved.
It must be that the the WASM inquestion and the JavaScript in
question, they they must betogether in the same sandbox.
Uh is that right?
SPEAKER_01 (15:21):
I I believe they are.
I think when you when you fireup a web page that that includes
Wasm, I think it it naturally uhincludes JavaScript as well.
And I think it's the JavaScriptthat invokes the Wasm routines.
So I think they're both runningin the same uh security context,
uh the same sandbox at thatpoint.
(15:41):
That's how you you can play backand forth.
Wolf (15:44):
So I know that there's not predefined hunks of WASM um that
come from the browser itself.
Um I I I know they come down uhalong with the web page and the
JavaScript for that that page.
They're another resource thatthe client is reaching out for.
(16:07):
Um is that some kind of file?
Like a like there's.js files.
What does a how where does WASMcome from on the server?
SPEAKER_01 (16:18):
Well, it it it's served up by the server with uh
with a uh a mime type, I thinkof application slash wasm.
Like normally you would youwould have uh um what do you
have application slashJavaScript?
Uh what is the mime type forJavaScript or or uh or text
slash JavaScript?
Um just like you'd have textslash HTML.
(16:40):
Um wasm comes the same way as aas a stream of data.
It is a binary stream.
It's it's it's uh I don't knowif it's compressed, but it's
certainly compiled down thebinary.
Um when you're developing, itincludes all kinds of uh uh
simple tables and and map sourcemaps and stuff.
(17:01):
So it's it can be fairly large.
But so it has source maps.
Wolf (17:06):
Source maps means that you can use a debugger.
SPEAKER_01 (17:10):
Yes, yes.
In fact, uh both Chrome andFirefox, uh the debuggers in
those browsers uh can debug Wasmcode.
And what I saw, I I didn't lookinto the Firefox debugger, but
the the Chrome debugger, you candebug at the original source
code level.
So if you wrote your program inC, compiled it to WASM, included
(17:32):
the source maps, which I thinkthey're there by default, uh,
unless you strip them, uh whenthat code gets down to the
browser, you can be debuggingyour JavaScript code, and then
when you call into a a WASMfunction, you can be looking at
it uh at the C code, and thenthere's a mode where you can
(17:52):
actually drop down to theindividual uh assembly
instructions, the WASM assembly.
Uh, you can debug at all thoselevels in the Chrome uh
debugger, and I think you can dothat uh as well in the Firefox
debugger.
Wolf (18:07):
I love the JavaScript debuggers in both of those.
Um yeah, yeah, they're bothfantastic.
I I bet the WASM debugger isjust as good, I'm hoping.
But you said compiled from Cdown to WASM.
So that makes me want to ask ifyou can compile C down to WASM,
(18:31):
what else?
SPEAKER_01 (18:33):
Well, the the the big players are the C, C, and
Rust.
Uh they're the those three arevery, very well supported.
Uh and there's a lot of code outthere that has been compiled
down to Wasm.
But there's a lot of otherlanguages uh as well.
Um C sharp is is fairly wellsupported.
Swift, you can write Swift code.
(18:53):
If you're an Apple developer,you can write Swift code,
compile that to Wasm.
Go uh is very well supported.
Uh uh Google is is doing a lotof Go stuff, and uh they can
compile that down to Wasm.
And there's many, many morelanguages.
Uh there's there's some supportfor for uh uh Python and uh you
(19:17):
can compile JavaScript down toWasm.
Uh some of the languages arevery well supported, some of
them a little less wellsupported.
Uh those are ongoing projects uhwith an aim to make it better.
Uh I'm including a link to apage that shows the various uh
languages and the things thatthey support.
(19:37):
Uh that link will be in the shownotes.
Um this podcast.
Wolf (19:43):
In my day job, uh I write a lot of Python.
I happen to really enjoy writingPython.
Um and uh I participate in thecommunity and I see people
talking, and one of the thingsthey say is, oh yeah, you You
can download uh you can compileCPython, the Python interpreter,
(20:07):
you can compile that down toWASM, send it down the pipe to
the client, and then you canwrite Python programs that run
in your browser.
Um that's interesting to me.
These things seem huge.
Like how much how much data isgoing down the pipe?
(20:28):
How big is a Hunk of WASM?
And why wouldn't uh I mean Iguess this is political, but um
it seems like there's a coupleof things that would be awesome
if they were already in WASM andalready in the client and didn't
need to come down the pipe.
(20:49):
Um I think earlier we weretalking about SQ Lite.
Um that seems like a great thingto have locally that uh that
your JavaScript andor WASM codecan access.
Uh so how big are these things?
How do they get down?
Where do they live?
How come the browsers won'tinclude some?
SPEAKER_01 (21:11):
Well, there's a lot of questions there.
Uh why don't the browsersinclude them?
Uh you open up that door, youknow, it's a Pandora's box.
You you open up that door, andpretty soon the people are going
to expect the browser to includeeverything.
I I think there's a case to bemade that let's keep the
browsers small uh and anddownload the pieces you need
(21:31):
when you need them.
Um you know, if you compile asmall uh hello world uh uh
program in C, it's it's a coupleof K, you know, a couple
thousand bytes, I think, by thetime you you compile it and link
it and convert it into WASM andall that stuff and set it down.
So that's just a few K.
That's not a big deal.
(21:52):
But uh you know, you can get upinto many, many megabytes uh
worth of payload.
The Wasm code comes down just asthough it were uh another
JavaScript module.
It's it's just uh it's a binarystream that the that the server
sends.
You know, the browser requestsit, the server sends it and it
loads it into memory and andstarts executing the code.
(22:15):
Um I I I you know some of thesebig things.
Uh you know, SQL Lite, I thinkis not that big.
Uh there is a what looks like afully supported SQL Lite
implementation on the SQLite.orgwebsite.
Um the original article that Iread was about running Postgres
(22:36):
as a WASM module.
That's probably much larger.
Postgres is a is a is a muchlarger project project.
I I don't know in terms ofmegabytes or even gigabytes how
big that would be.
Um I but I was uh it wouldn't beit It wouldn't surprise me if if
uh the some of these things aretens of megabytes in size.
Wolf (23:00):
I um I as a Python user uh a thing I sometimes do is use
Jupyter notebooks or JupyterLab, whatever.
Um and that's when you use thatalmost always you're separately
running a server.
Um it might be on the machineyou're on or it might be uh
(23:21):
across the internet somewhere,but you connect to it and it
does the real work.
A thing that people have beentalking about um is called
Jupyter Lite, and JupyterLite isa hunk of WASM that you download
to your machine and suddenly inthe client, in your browser,
(23:43):
with no connection other thanwhere you got the WASM from, you
are running a Jupyter Notebook.
Um and I looked it up.
Uh JupyterLite is about eightmegabytes.
Um and Jupyter uses Python, sothat must include a Python
(24:03):
interpreter, I would think.
I don't know that for sure.
Um what do you think?
Is eight megabytes big?
Is that a little tell me more.
SPEAKER_01 (24:13):
To me, eight eight megabytes is not that big.
I I you know I I write a lot ofJavaScript, and I try to keep my
JavaScript down um into thehundreds of K size, uh certainly
less than than half a megabyte.
Um but I don't think it'sunusual for uh for somebody to
download eight megabytes of ofWasm.
(24:35):
And I think it's you know, in inin today's uh uh broadband, uh I
don't think it's that big a dealto pull down something of that
size.
Wolf (24:44):
It's kind of breaking my heart to hear you say that.
Yeah.
Because I want things to besmall and fast.
But uh it is.
SPEAKER_01 (24:53):
Yeah.
Well, you know, uh that initialdownload will uh uh uh if it
improves the performance whileyou use the app, if it's
something you're gonna download,use real quick, and throw away,
eight megabytes is huge.
But if it's a if it's a largeapp um that that's gonna be long
running, um it's not that big adeal.
Wolf (25:15):
That's sort of a thing they say about uh various
different uh algorithms incomputer science.
Usually it's got a big O andsome some kind of expression,
but almost always it starts withcapital C plus that thing.
There's always some kind ofconstant setup time.
(25:38):
And often in the complicatedthings, C is big.
Um so I'm just sort of relatingit to a thing I'm more familiar
with, but it sounds like withWASM, C is big.
So you want to make sure you'reonly using it to solve problems
that are big.
SPEAKER_01 (25:57):
Well, sure, but there are there are plenty of
small things you might want todo.
Let's say you want to you wantto encrypt things in in your
browser.
You might have uh some text orsomething that you want to
encrypt before you send it.
Uh you could write thatencryption code in in C, compile
it into WASM, and and that couldbe potentially pretty small.
(26:20):
You know, if that was 40 or 50k,that's not a big deal.
Uh it can do really big thingsvery quickly in a small
footprint.
So I like what you're saying.
Wolf (26:32):
I do have one off-topic point about what you're saying,
which is um this is a goodexample, but in your example,
you have ordinary programmerswriting their own encryption.
Um totally off-topic.
I think that's a bad idea.
SPEAKER_01 (26:53):
Sure, but you could take a standard implementation
of uh uh some encryption.
Maybe you're calling uh anencryption library, um, and you
can compile and link that andsend it in uh convert it into
Wasm and send it to the browser.
You didn't have to write thatencryption code.
That encryption code might havebeen written by somebody else,
might be a library.
Wolf (27:13):
That sounds much better to me.
Thank you.
SPEAKER_01 (27:16):
Yeah, yeah.
You get the idea.
The code doesn't have to be bigto do important things.
Uh and and if it's if it'scompute intensive, I think WASM
makes a a a great uh case forfor itself by doing that.
Um there are an awful lot ofpeople using WASM.
It really surprised me when Istarted looking into it.
(27:37):
I thought it was a a veryobscure thing that maybe a
research kind of a thing, but itturns out uh Google's using it
in maps, uh in translate, inGoogle Docs.
Those are all used in Wasm.
Microsoft's using it in VisualCode.
Uh I think VS Code that runs inum Electron, is that right?
Wolf (27:58):
That is right.
SPEAKER_01 (27:59):
And and that's a that's kind of a browser type
thing.
Uh that's using Wasm.
Um I I won't say the entire theentirety of uh VS Code is
written in Wasm, but there arepieces of it that are written in
WASM.
I think that's pretty neat.
Um Visa is using it, uh thecredit card people, uh to make
(28:20):
more secure and reliable paymentprocessing systems.
Uh Tesla is using it uh in someof the safety critical code for
for controlling things likebrakes and steering.
I'm not sure I'm crazy aboutthat, but I'm I'm not wanting a
Tesla.
Wolf (28:36):
Thanks.
SPEAKER_01 (28:36):
No, no, no.
Um uh a lot of players.
Spotify is using it, Amazon isusing it, uh, Netflix is using
it in their in their webinterface.
Uh if you're a gamer and you'rerunning some of these games that
are that come across the web, uhUnity and Roblox are uh those
game engines are using Wasm.
(28:58):
Pinterest is using it.
Um it amazes me the the thepeople that are that are doing
this.
Uh so it's out there.
And it's and it's been out therefor for years.
I I think it's pretty neat.
Um uh there's a lot of tools.
When I when I started into this,it's like, how do I you know how
do I how do I write my helloworld program um and and run it?
(29:22):
Uh well it turns out there's athere's a project called M
Scriptin.
It's E M-S-C-R-I-P-T-E-N.
Uh and there's a link to it inthe show notes.
Um and it's uh it's the thecompiler, the the tool that you
use to take your C program oryour Rust program and convert it
into uh WASM.
(29:43):
Um it it works with uh Clang andLLVM.
And if you think about it, it'sreally kind of like a kind of
like a uh it wasm is justanother instruction set.
So if your language if yourcompiler can compile down to
down to um x86 or down to ARM,uh well inscript and allows it
(30:07):
to compile down to Wasm.
Uh so if you think about that,it just think about WASM as
though it's another CPU.
Wolf (30:14):
I'm not a hundred percent sure um how this arrangement
works.
Like, I can't imagine that theseWASM guys have written a Rust
compiler.
It's got to be your Rustcompiler that you already have.
Where does NScripton fit intothat?
SPEAKER_01 (30:33):
I think it's it's just the part that spits out the
the the uh uh machine dependentpart.
The uh the the CPU instructions,I think, come out of an M
script, and I think I I haven'tactually done the Rust part of
it.
I'm not a Rust developer uh likeyou are uh you are working to
(30:53):
be.
Uh I've only done the the C uhstuff, and somewhere in that
toolchain uh it it parses your Ccode and turns it into WASM
code.
Uh I think there's severallayers of of that happening.
Wolf (31:11):
I see.
Um I know in C you might beusing Clang and LLVM and
whatever.
Those allow you to stick inbackends to generate the right
thing.
Um that makes sense to me.
Uh I don't know enough aboutRust to know if it does the same
(31:31):
thing.
SPEAKER_01 (31:32):
Well, Rust is available for a lot of different
CPUs, so I think I think thatmechanism exists.
Um it would make sense that itdoes.
Uh anyway, I know for sure youcan compile Rust into Wasm.
Uh and there's tools to do that.
Um I uh when I when I looked atthe uh uh EMCC is the name of
(31:55):
the command you use within the Mscript and project.
Uh EMCC has a ton of options.
Just there's there's got to be200 options you can specify.
Uh different uh mallocks thatyou want to use, different
memory models, different allkinds of stuff.
Um and what I stumbled uponthough was uh WASM by default is
(32:18):
32-bit.
Uh you know, you think about uhlanguages these days and CPUs
these days, 64-bit has kind ofbecome the norm.
But by default, WASM compilesdown to 32-bit, which means the
memory pointers are 32-bit, theintegers are 32-bit.
Um, but there is a simple optionto run WASM 64 uh to generate
(32:39):
64-bit code.
Um it would make sense to methat that it would be faster,
although bigger, right?
Yeah, you your integers aretwice as long, your pointers are
twice as long.
Um so it could be that that32-bit is just fine for most
everything.
Um but the choice is there.
(33:01):
You you can do that.
Um there's another really neattoolkit.
Um uh it's pronounced Wabbit,it's W-A-B-T.
It's the WebAssembly BinaryToolkit.
That gives you a whole bunch oftools.
For instance, when I compile myhello world program uh written
in C down to WASM, it produces abinary uh.wasm file.
(33:27):
I can use uh Webit to convertthat binary file into a text
file.
Basically it converts uh WASMformat to WAT format, that's
WebAssembly Text format.
And then I can read the assemblycode.
And it's a lot like uh theassembly languages that I've
(33:51):
used in the past.
Um uh you can look at it and andplay with it.
And you can also write this isthe tool you would use if you
want to write WebAssembly byhand and then uh convert it to
uh a.wasm file.
You would use the Webit toolkit.
Wolf (34:08):
Now I have another question.
Um I'm as I said before,paranoid.
And uh a thing about havingsoftware that runs on the client
and works together with theserver is that attackers can be
running the client and they can,for instance, in the case of
(34:30):
JavaScript, um, they can see theJavaScript right there.
It's one of the things theydownloaded.
They m they can tell what itdoes, they can modify it to make
it do new things.
Um and so a lot of things thathappen, uh if they need to be uh
not influenced by the clienthave to happen on the server to
(34:54):
make sure attackers don't getany uh input in that way.
Um is WASM since it seems easyto take Wasm and disassemble it,
is it subject to the sameattacks?
SPEAKER_01 (35:11):
Well, it it it probably is, although you would
have to get that WASM code outof the web page and into a file.
And I think if you just do uhyou know your browser has a show
source mode, uh you wouldn't seeit.
I think you would actually haveto fetch that WASM code from the
server.
I I imagine you could do itusing curl or or um wget or
(35:35):
something to to get your handson that code.
Um but then you would have to ifyou wanted to do something
malicious with it, you wouldhave to modify that code and
then figure out a way to getthat code back into the browser
to execute something.
So it's it's uh I'm gonna saythere probably is a way to do
that, but it's a much higherbarrier uh than you know just
(36:00):
opening up a debugger andlooking at the JavaScript code
and manipulating it.
It it's it's quite a bit morework than that.
It wouldn't surprise me if it'simpossible to do what you're
thinking.
Wolf (36:10):
I think.
SPEAKER_01 (36:12):
But yeah, I think I think WASM is gonna turn out to
be much more secure in thatregard.
Um I I don't know if they'redoing code signing.
I would hope that there's aprovision for you to do code
signing uh of of your WASMmodules.
That'd be interesting to lookat.
Uh I'm not sure if that's there.
(36:33):
But um the the what when Iinstalled like in script m m
script, and it's kind of hard tosay.
Uh when I install that, it uhit's just a download from from
the web.
Uh the Wabbit uh WebAssemblyBinary Toolkit.
Um you can that's a Git project,a GitHub project, you can you
(36:56):
can fetch it that way.
Uh it had a few dependencies, soI just ended up uh installing it
using Homebrew.
Uh I'm on a Mac.
So I just used Homebrew toinstall it.
Uh and that was really simple.
And immediately I was able tostart disassembling Wasm code
and and looking at it.
So that was that was prettyneat.
Um I keep talking about the theone of the real benefits of Wasm
(37:21):
is that it performs better thanJavaScript.
So I did a few simplebenchmarks.
I I'm not a benchmarking guy,but I uh I took a program that
uh that that our friend Dave uhwell I I don't want to say that
he created the program, heactually used uh I think ChatGPT
to to create this program.
He's uh he's a sudoku player,and he over the years has
(37:45):
written several Sudoku solvers,and he asked ChatGPT to write
him a Sudoku solver uh in C.
And it's uh it's a real simpleprogram, it just uses the
recursive algorithm to to bruteforce solve a Sudoku puzzle.
Um so I played with that alittle bit.
(38:07):
Uh I ran the C program, uh the Cversion of it, compiled it and
ran C, and I put a loop in thereto run a million iterations of
this one puzzle.
And in C, a million iterationson a M1 Mac uh took 139 seconds.
(38:27):
I thought that's pretty fast foryou to run a million anything.
Uh 139 seconds.
Um I wrote almost line for linethe same implementation in
JavaScript, because they're thethose languages are similar
enough uh syntax-wise.
I I I rewrote it in JavaScript,and that took 619 seconds on the
(38:48):
same machine.
So 139 seconds at the commandline, 619 seconds in JavaScript
in the browser.
Um when I take that C programand I compile it using Wasm down
to uh a dot Wasm file and I runthat in the browser, um it was
quite a bit faster, andcertainly not as fast as the C
(39:11):
version, uh, but way faster thanthe JavaScript version.
Uh I tried several differentbrowsers.
Um to my surprise, Safari wasthe fastest browser.
It ran a million iterations in158 seconds.
So that's uh that's four timesfaster than the JavaScript
(39:32):
version.
Um slightly slower than the theC.
Yeah uh C was 139 seconds,Safari was 158 seconds, Chrome
was 181 seconds, uh and again tomy surprise, Firefox was the
slowest at 223 seconds.
These were all running the exactsame WASM code.
(39:55):
I just I I served it up from uhM script and Provides a little
uh built-in web server, uh EMrun that will serve up this
code.
Uh so I just pointed these threedifferent browsers at it, and uh
it really surprised me theJavaScript that Firefox was the
(40:15):
slowest one at two or something.
Wolf (40:17):
Can I ask you a question about your benchmarking?
Yeah.
Um you gave uh the time of 619seconds for the JavaScript.
Um what did you have executingthe JavaScript?
Was that in one of the browsersor Node.js or where?
SPEAKER_01 (40:36):
Uh that was in Chrome.
I I did not try JavaScript inthe various browsers.
Uh that was just running it inChrome.
Um I I uh WASM, it'sinteresting.
You can run WASM on the serverin Node.js.
Uh and when I ran uh WASM inNode.js, uh the Sudoku solver,
(40:59):
184 seconds.
And that's very, very close tothe Chrome uh runtime of 181
seconds.
And I think it's because Chromeand Node.js are running the same
JavaScript engine.
So it's not surprising they'rethat close in performance, at
least it doesn't surprise me.
Um but yeah, uh WASM is fasteruh for my tiny little benchmark.
(41:25):
I I'd I'd like to learn moreabout uh benchmarking and
profiling and stuff.
And I think I think this sort ofuh is gonna lead to another
future episode on profiling andbenchmarking and performance, uh
how to squeak squeak moreperformance out of your code.
I think that's coming up uhsometime in in the next few
episodes.
Um because we did learn a lotfrom this, and I and I want to
(41:47):
learn a lot more.
Um but yeah, uh uh WASM isfaster.
Well let me faster than than uhthan just pure JavaScript.
Wolf (42:00):
Let me ask you uh kind of a final question.
Uh what is the takeaway?
What are the things you saidthat people should remember?
SPEAKER_01 (42:14):
Well, first and foremost, I'd say if you if you
have a compute-intensive part ofyour application, uh and your
application, it's a web-basedapplication, but you've got
something that's computeintensive and you want to speed
it up, it probably makes sensefor you to implement that part
of your code in a in a compiledlanguage like C or C or Rust.
(42:36):
Uh, compile that down to Wasmand Um and then make that part
of your web app so that itdownloads that WASM code and
executes.
That will speed up your program.
I think that's the first thing.
Uh security and portability,that's one of the things that
that the Wasm people say it'smore secure.
(42:57):
Um I I don't know for sure thatit's more secure and more
portable than JavaScript,because that's gotten to the
point where it's it's prettysecure and portable, other than
the thing that Wolf was pointingout about uh you know, within
the debugger, you can look atthe you can you can poke into
the uh the JavaScript and andmanipulate it.
Uh but Wasm I think is is moresecure in that regard.
(43:20):
Uh and it's and it's veryportable.
So that's a uh uh maybe thesecond point I I wanted to make.
Um and almost certainly you'realready using using WASM-based
applications.
If you're using Google Maps andDocs and Netflix and Spotify and
Amazon and many, many more,you're you're running WASM code,
(43:41):
whether you realize it or not.
You won't even notice it's justrunning in the background.
Um so so yeah, I think that'sthat's kind of my uh my my
high-level view of of Wasm.
I I learned a lot uh looking atthis, and I I I I write
web-based apps.
(44:02):
I don't write a lot of stuffthat's that's really client
intensive, so I'm not sure thatI'm gonna need to write uh
WebAssembly code for for myapps, but just understanding
that it's there and that itworks, I think it's pretty neat.
Wolf (44:17):
Um so you did this research, and I'm gonna ask a
question of you that is um outof band.
I I'm just interested.
You you came into contact withall this new information.
Uh I I want to know what was themost um, I guess I care about
(44:38):
surprising or interesting, orwhat fact uh was a big peak in
your in your learning?
What what stands out?
SPEAKER_01 (44:49):
I I I think the fact that it's it's so widespread
used right now by the bigplayers.
Um it's out there, it's it'sbeing used.
That really surprised me.
I I I early on like i in thisconversation, I said I thought
it was kind of a research thing.
Um I I didn't know that it wasthat that that well used.
(45:12):
Uh, I think it's pretty neat.
That was a surprise to me.
Wolf (45:16):
Um I think that brings us to the end of this show.
I want to thank everybody who'slistening.
Please tell your friends.
Um if you liked it, leave us areview wherever you get your
podcasts.
If you haven't alreadysubscribed, uh subscription
would be great.
Uh, as I've already said, welove and value your feedback.
(45:39):
Connect with us on Mastodon atruntimearguments at hackyderm.io
or send us an email, feedback atruntimearguments.fm.
Um I I think we're having agreat time.
I think I speak for Jim when Isay that.
Um, but this is great for us.
(46:00):
I hope you are getting as muchout of it as we are.
Thanks for listening.
Jim, anything?
SPEAKER_01 (46:08):
Uh yeah, thanks for listening.
And uh we're we're reallyenjoying doing this.
And the fact that there'sthere's there's so many people
that are that are listening andgiving us feedback is just
fantastic.
Uh I think we would do this ifthere were one person out there
listening.
It turns out there's a lot morethan one person.
So yeah, we're enjoying it.
So thank you everybody forlistening, and we'll we'll just
(46:30):
keep doing this as long as wecan.
Wolf (46:34):
And we'll see y'all in the next episode.
Bye.
Welcome back to another episode of Runtime Arguments
with Jim and Wolf.
Uh we've both been curioussoftware engineers for quite a
while, and each episode we tryto learn something new or report
on things we've built or doneand share it.
Um topics we've covered so farhave mostly been questions that
(00:24):
came up in our conversationsover lunch, and usually tack or
tack adjacent.
We're just starting out in thispodcast world, uh, and we
appreciate you listening andhelping us get better.
Um I'm Wolf, and my friend andpartner in this show is Jim
McQuillen.
(00:44):
How are you doing, Jim?
SPEAKER_01 (00:47):
Oh, Wolf, I'm doing great, and I'm really excited
about this episode we've got foryou today.
Wolf (00:54):
Um we have gotten uh more feedback, which we love and
value.
Uh we want to get this wholething right uh and we want to
get better.
Feedback drives those things.
If you have feedback, you canreach us on Mastodon uh
runtimearguments at hackyderm.ioor by email feedback at
(01:17):
runtimearguments.fm.
Those will both be in the shownotes.
Um two pieces of feedback toshare with you from previous
episodes.
Let's start with thoughts on uhJim's cloud transition.
Jim.
SPEAKER_01 (01:33):
On our May 3rd episode, we talked about my
adventure moving from the datacenter to the cloud.
My old friend John uh uh he sentme some feedback saying that
that's a really good case studyfor uh highlighting just how
little resources you need.
Um it turns out uh most peoplethink they want the most
(01:56):
powerful server they can get,but you really don't need that.
Uh and as I showed in thatepisode, I'm using a very small
uh server with very low RAM torun lots of Docker containers,
and it's performing really quitewell.
Wolf (02:10):
Um we also got a little bit of feedback um in person uh
on our pass keys episode.
Our good friend Ron pointed outthat um he's been he's been
using a password manager, uh, inparticular one password, but
right now for every passwordmanager that we looked at, there
(02:33):
is no import or export of passkeys.
Um that is a thing they areworking on.
It doesn't look like it's vendorlock-in.
It looks like um the passkeypeople are trying to uh f come
up with a uh standard for howthat's going to happen.
(02:57):
Um there was one other thing Iwanted to mention, not on pass
keys, but on crypto, uh, andthat is um our very paranoid
friend, and and I'm paranoidtoo, so I respect this.
Our very paranoid friend Ron uhtook my uh thoughts that you
don't want to have a walletmanaged by a broker with a ton
(03:20):
of crypto in it, and he said,Well, what about where you have
two wallets, one you manageyourself, and that's where you
really keep all your money, andone that you keep on the
brokerage so that you can doexchanges and you just move the
money just in time.
So that was another thing thatwas pointed out.
Um that's our feedback.
SPEAKER_01 (03:43):
Yeah, that that that idea of two accounts, that's I
mean, that's how a lot of peopledo it with a normal bank, moving
money uh between accounts sothat if somebody hacks into your
your uh uh your checkingaccount, they can't take all
your money.
Yeah.
They only can take what what youput there.
Wolf (04:03):
Uh doesn't work that way for me because my checking
account doesn't have very muchmoney.
Um so let's actually get intothis episode.
I'm gonna hand it over to Jim.
He did all the research thistime.
Uh Jim, start us up.
SPEAKER_01 (04:20):
Yeah, I think today's episode is gonna be a
little bit different, maybe moreconversational, because uh uh
this is just something that Iresearched and I I talked a lot
with Wolf about.
Uh so we're just gonna sort oflay out what we learned.
Um years and years ago, I playedwith assembly language.
I I uh I did some x86.
(04:41):
Uh if you remember back in thedays of MS DOS, I I was writing
um um TSRs, the Terminate andStay Residence programs that
you'd run in a in a DOSenvironment that would run kind
of in the background, althoughDOS was not a uh multi
multi-threaded uh environment.
Um but I'd write uh littleservice interrupts that would
(05:02):
run when an interrupt happens,like a clock tick or a keyboard
or something, it would fire offthis little bit of assembly
code.
Um I also did some uh 6502 and6510 assembly.
Uh you know, of course, I Istarted like a lot of people
with uh a Commodore VIC-20 andthen moved up to a Commodore 64,
and those are the processes,processors that those computers
(05:26):
used.
And I played a lot with uhwriting assembly language code
on those.
Sort of cut my teeth on that.
And then as I moved into theprofessional world, I did some
assembly language on a TMS 9900chip, and that was the text
instruments, that's what theyput in their business systems.
I think they also put them intheir their little uh home
microcomputers too.
(05:47):
But I I uh I was writing COBOLcode back then, and we need to
we needed to run some thingsfaster.
Like COBOL didn't have a sortverb just for sorting arrays, so
I wrote something in assemblylanguage to sort an array.
Um and we would call that fromCOBOL, we would call out to the
assembly language routine, andit was much, much faster than
(06:08):
trying to do trying to implementit just in COBOL, or or the
COBOL way was to write it out toa file and then sort that file,
which was kind of silly.
Anyway, I I I do have someassembly language uh experience,
and Wolf, I think you said youyou dabbled in assembly language
as well.
Wolf (06:24):
I have um I've written assembly language for the 68,000
um for the x86, of course.
Um uh I'm trying to rememberwhat else.
I keep meaning oh, the PowerPC.
I wrote wrote code for that.
Uh I keep meaning to write stuffum that runs on an ARM chip.
(06:48):
I'm particularly interested inthe the M chips from Apple.
That would be interesting to me,and I just never seem to get
around to it.
SPEAKER_01 (06:56):
Cool.
Well, the reason why I'm talkingabout assembly language is uh at
one of our one of our lunchesseveral weeks ago, I I had seen
an article that somebody hadimplemented Postgres in
WebAssembly.
And I what is that?
I I'd heard of WASM, I've heardof WebAssembly, but I wow,
(07:18):
somebody's doing Postgres inthat?
That's that's pretty neat.
Uh so I thought that might be aninteresting thing to dive into
and learn about.
And WebAssembly, um, or or it'spronounced WASM, W-A-S-M.
It's it's kind of likeJavaScript, yet not at all like
(07:38):
JavaScript.
Uh, it runs in the browser, uh,although it can run server-side
in like node if you want it.
Um, but it's uh it's it's uhit's very much assembly language
like.
It's got an instruction set.
Uh, you know, when you writeassembly language, you write it
for a particular CPU, usually.
(07:58):
Uh you might write assemblylanguage for an x86 or uh or a
6502.
Well, you can write assemblylanguage for WASM and uh WASM.
Um it there's an instructionset.
Uh it's uh there's a stack-baseduh virtual machine that runs and
interprets that uh assemblylanguage code.
Wolf (08:20):
Wait, wait, can I ask you a question?
Yeah, yeah, yeah, yeah.
Um so I I know some of thethings you were doing to
research this, and I have someknowledge of WASM, uh, but
suddenly it occurs to me, do youactually can a person actually
(08:40):
write WASM?
Can you sit down in your editorand type the instructions in and
have it run?
SPEAKER_01 (08:46):
Yes, absolutely.
There are uh tools to to let youdo that.
So for you to type it and andassemble it into a binary file
that's that's uh consumable bythe browser.
So yeah, you certainly can.
It wasn't it wasn't written tobe human writable and human
readable, although you can writeit.
(09:08):
It's really meant to betranslated from another
language, like C or C ⁇ .
Wolf (09:13):
I feel like um this is a lot in this is a lot like
Postscript.
SPEAKER_01 (09:21):
Yeah, kind of.
Postscript is uh is astack-based language.
Uh I I I've written a fairamount of PostScript in my time,
and it's uh it's not exactlyhuman, it's not exactly intended
for a human to to write or read,but it's sort do certainly
doable.
(09:41):
So yeah.
Um the the the benefit of usingWebAssembly though is it
executes much faster.
Uh it's at near native speeds inthe browser, faster than than
JavaScript, certainly.
Um it's uh it's an attempt to uhto to for you to write code that
(10:05):
needs to perform well in thebrowser, uh where you might not
be happy with uh the performanceof JavaScript.
Um so in my in my digging intothis, I I looked at all kinds of
things.
And and uh first off, uh wheredid it come from?
Um it was written by uhinitially created by uh the
(10:26):
World Wide Web Consortium, uhW3C.
It was a successor to somethingcalled ASM.js, which was like a
subset of JavaScript, uhintended to be fast, um, but it
wasn't a standard.
Uh so Wasm was was kind of uhcreated as a standard way to
(10:47):
write fast code for a browser.
Uh it's first uh the the firstpublic announcement was in June
of 2015.
So we're at like, I mean, nextmonth we're gonna be at uh at 10
years.
Um actually when this when thisepisode comes out, it'll be 10
years since uh WASM was was uhinitially announced.
(11:10):
Um the first viable product, theminimum viable product, uh what
came out in 2017.
Uh and at that time in Septemberof 2017, it came out on Safari,
that was Safari 11 uh for Applepeople, and November 2017, all
major browsers uh supported it.
Um so it's you know it's it'sbeen out there for real use uh
(11:34):
for eight years now.
Um the the people in charge, W3Cis still in charge of it, but
also uh Mozilla, Microsoft,Google, and Apple are all
working uh on this, uh helpingdevelop it, uh, help helping to
keep it going.
So it's got a lot of supportfrom from the big players.
It's it's an important piece oftechnology, I think.
(11:55):
Um that that that these bigcompanies are are behind.
So I think that's good.
Wolf (12:01):
Um why exactly I'm trying to figure out what the place of
Wasm is in in the world.
I mean, people are usually usingtheir browser, that's sort of
the center of user interactionwith stuff that exists today,
uh, or else they're on theirphone and they're using an app
(12:23):
that does the exact same thing.
But my question is um what doesWASM do uh in this world?
Where does it fit?
Where does it come from?
Um tell me more about theperformance.
Why is it better?
Uh does it follow the same rulesas JavaScript?
(12:44):
Um fill me in.
SPEAKER_01 (12:46):
Well, it's uh uh yeah, the the I think the
primary goal is it's faster,faster than JavaScript.
Uh I I think that gap might beshrinking a little bit as
JavaScript uh is is continuallyuh uh getting better with their
just-in-time compilers and andstuff.
But wasm is still quite a bitfaster than JavaScript.
(13:10):
Uh it follows all the samerules.
It runs in a sandboxedenvironment within the browser,
so it doesn't by default haveaccess to any local resources.
You can't you can't uh uh send aWASM program to somebody's
browser that has that couldaccess their hard drive uh or
anything else in their computerunless that person gives it
(13:31):
explicit permission to do that.
Wolf (13:34):
Um let me ask you, uh I I just absolutely don't know the
answer to this.
Um does WASM see the same thingsthat JavaScript can see?
Does it have an interface to theDOM?
Can it can it m do things toyour web page?
SPEAKER_01 (13:54):
Uh WASM doesn't have direct uh access to the DOM.
It goes through JavaScript toget that.
There's a real nice interfacebetween WASM and JavaScript.
Uh WASM can call JavaScriptroutines and JavaScript can call
Wasm.
So it's a it's a nice back andforth thing.
Uh so getting to the DOM, um yougo through the the JavaScript
(14:17):
layer to do it.
Uh I I don't think that's wherethe performance uh benefit
happens.
Uh I think the the performanceis more on just the raw uh uh
processing of data.
Um you know maybe you've got umsome uh encryption uh uh
(14:38):
routines you want to run.
Maybe you want to encrypt data.
Uh uh you could write that codein in C, compile it onto Wasm,
and then run that in thebrowser.
Um I think that would run muchfaster than a JavaScript
implementation of that codewould.
Uh yeah.
When it comes to accessing theDOM, yeah, you'd go through
JavaScript to do that.
Wolf (15:00):
It sounds like um since WASM and JavaScript can talk to
each other, um, they must, Iknow there's sandboxes involved.
It must be that the the WASM inquestion and the JavaScript in
question, they they must betogether in the same sandbox.
Uh is that right?
SPEAKER_01 (15:21):
I I believe they are.
I think when you when you fireup a web page that that includes
Wasm, I think it it naturally uhincludes JavaScript as well.
And I think it's the JavaScriptthat invokes the Wasm routines.
So I think they're both runningin the same uh security context,
uh the same sandbox at thatpoint.
(15:41):
That's how you you can play backand forth.
Wolf (15:44):
So I know that there's not predefined hunks of WASM um that
come from the browser itself.
Um I I I know they come down uhalong with the web page and the
JavaScript for that that page.
They're another resource thatthe client is reaching out for.
(16:07):
Um is that some kind of file?
Like a like there's.js files.
What does a how where does WASMcome from on the server?
SPEAKER_01 (16:18):
Well, it it it's served up by the server with uh
with a uh a mime type, I thinkof application slash wasm.
Like normally you would youwould have uh um what do you
have application slashJavaScript?
Uh what is the mime type forJavaScript or or uh or text
slash JavaScript?
Um just like you'd have textslash HTML.
(16:40):
Um wasm comes the same way as aas a stream of data.
It is a binary stream.
It's it's it's uh I don't knowif it's compressed, but it's
certainly compiled down thebinary.
Um when you're developing, itincludes all kinds of uh uh
simple tables and and map sourcemaps and stuff.
(17:01):
So it's it can be fairly large.
But so it has source maps.
Wolf (17:06):
Source maps means that you can use a debugger.
SPEAKER_01 (17:10):
Yes, yes.
In fact, uh both Chrome andFirefox, uh the debuggers in
those browsers uh can debug Wasmcode.
And what I saw, I I didn't lookinto the Firefox debugger, but
the the Chrome debugger, you candebug at the original source
code level.
So if you wrote your program inC, compiled it to WASM, included
(17:32):
the source maps, which I thinkthey're there by default, uh,
unless you strip them, uh whenthat code gets down to the
browser, you can be debuggingyour JavaScript code, and then
when you call into a a WASMfunction, you can be looking at
it uh at the C code, and thenthere's a mode where you can
(17:52):
actually drop down to theindividual uh assembly
instructions, the WASM assembly.
Uh, you can debug at all thoselevels in the Chrome uh
debugger, and I think you can dothat uh as well in the Firefox
debugger.
Wolf (18:07):
I love the JavaScript debuggers in both of those.
Um yeah, yeah, they're bothfantastic.
I I bet the WASM debugger isjust as good, I'm hoping.
But you said compiled from Cdown to WASM.
So that makes me want to ask ifyou can compile C down to WASM,
(18:31):
what else?
SPEAKER_01 (18:33):
Well, the the the big players are the C, C, and
Rust.
Uh they're the those three arevery, very well supported.
Uh and there's a lot of code outthere that has been compiled
down to Wasm.
But there's a lot of otherlanguages uh as well.
Um C sharp is is fairly wellsupported.
Swift, you can write Swift code.
(18:53):
If you're an Apple developer,you can write Swift code,
compile that to Wasm.
Go uh is very well supported.
Uh uh Google is is doing a lotof Go stuff, and uh they can
compile that down to Wasm.
And there's many, many morelanguages.
Uh there's there's some supportfor for uh uh Python and uh you
(19:17):
can compile JavaScript down toWasm.
Uh some of the languages arevery well supported, some of
them a little less wellsupported.
Uh those are ongoing projects uhwith an aim to make it better.
Uh I'm including a link to apage that shows the various uh
languages and the things thatthey support.
(19:37):
Uh that link will be in the shownotes.
Um this podcast.
Wolf (19:43):
In my day job, uh I write a lot of Python.
I happen to really enjoy writingPython.
Um and uh I participate in thecommunity and I see people
talking, and one of the thingsthey say is, oh yeah, you You
can download uh you can compileCPython, the Python interpreter,
(20:07):
you can compile that down toWASM, send it down the pipe to
the client, and then you canwrite Python programs that run
in your browser.
Um that's interesting to me.
These things seem huge.
Like how much how much data isgoing down the pipe?
(20:28):
How big is a Hunk of WASM?
And why wouldn't uh I mean Iguess this is political, but um
it seems like there's a coupleof things that would be awesome
if they were already in WASM andalready in the client and didn't
need to come down the pipe.
(20:49):
Um I think earlier we weretalking about SQ Lite.
Um that seems like a great thingto have locally that uh that
your JavaScript andor WASM codecan access.
Uh so how big are these things?
How do they get down?
Where do they live?
How come the browsers won'tinclude some?
SPEAKER_01 (21:11):
Well, there's a lot of questions there.
Uh why don't the browsersinclude them?
Uh you open up that door, youknow, it's a Pandora's box.
You you open up that door, andpretty soon the people are going
to expect the browser to includeeverything.
I I think there's a case to bemade that let's keep the
browsers small uh and anddownload the pieces you need
(21:31):
when you need them.
Um you know, if you compile asmall uh hello world uh uh
program in C, it's it's a coupleof K, you know, a couple
thousand bytes, I think, by thetime you you compile it and link
it and convert it into WASM andall that stuff and set it down.
So that's just a few K.
That's not a big deal.
(21:52):
But uh you know, you can get upinto many, many megabytes uh
worth of payload.
The Wasm code comes down just asthough it were uh another
JavaScript module.
It's it's just uh it's a binarystream that the that the server
sends.
You know, the browser requestsit, the server sends it and it
loads it into memory and andstarts executing the code.
(22:15):
Um I I I you know some of thesebig things.
Uh you know, SQL Lite, I thinkis not that big.
Uh there is a what looks like afully supported SQL Lite
implementation on the SQLite.orgwebsite.
Um the original article that Iread was about running Postgres
(22:36):
as a WASM module.
That's probably much larger.
Postgres is a is a is a muchlarger project project.
I I don't know in terms ofmegabytes or even gigabytes how
big that would be.
Um I but I was uh it wouldn't beit It wouldn't surprise me if if
uh the some of these things aretens of megabytes in size.
Wolf (23:00):
I um I as a Python user uh a thing I sometimes do is use
Jupyter notebooks or JupyterLab, whatever.
Um and that's when you use thatalmost always you're separately
running a server.
Um it might be on the machineyou're on or it might be uh
(23:21):
across the internet somewhere,but you connect to it and it
does the real work.
A thing that people have beentalking about um is called
Jupyter Lite, and JupyterLite isa hunk of WASM that you download
to your machine and suddenly inthe client, in your browser,
(23:43):
with no connection other thanwhere you got the WASM from, you
are running a Jupyter Notebook.
Um and I looked it up.
Uh JupyterLite is about eightmegabytes.
Um and Jupyter uses Python, sothat must include a Python
(24:03):
interpreter, I would think.
I don't know that for sure.
Um what do you think?
Is eight megabytes big?
Is that a little tell me more.
SPEAKER_01 (24:13):
To me, eight eight megabytes is not that big.
I I you know I I write a lot ofJavaScript, and I try to keep my
JavaScript down um into thehundreds of K size, uh certainly
less than than half a megabyte.
Um but I don't think it'sunusual for uh for somebody to
download eight megabytes of ofWasm.
(24:35):
And I think it's you know, in inin today's uh uh broadband, uh I
don't think it's that big a dealto pull down something of that
size.
Wolf (24:44):
It's kind of breaking my heart to hear you say that.
Yeah.
Because I want things to besmall and fast.
But uh it is.
SPEAKER_01 (24:53):
Yeah.
Well, you know, uh that initialdownload will uh uh uh if it
improves the performance whileyou use the app, if it's
something you're gonna download,use real quick, and throw away,
eight megabytes is huge.
But if it's a if it's a largeapp um that that's gonna be long
running, um it's not that big adeal.
Wolf (25:15):
That's sort of a thing they say about uh various
different uh algorithms incomputer science.
Usually it's got a big O andsome some kind of expression,
but almost always it starts withcapital C plus that thing.
There's always some kind ofconstant setup time.
(25:38):
And often in the complicatedthings, C is big.
Um so I'm just sort of relatingit to a thing I'm more familiar
with, but it sounds like withWASM, C is big.
So you want to make sure you'reonly using it to solve problems
that are big.
SPEAKER_01 (25:57):
Well, sure, but there are there are plenty of
small things you might want todo.
Let's say you want to you wantto encrypt things in in your
browser.
You might have uh some text orsomething that you want to
encrypt before you send it.
Uh you could write thatencryption code in in C, compile
it into WASM, and and that couldbe potentially pretty small.
(26:20):
You know, if that was 40 or 50k,that's not a big deal.
Uh it can do really big thingsvery quickly in a small
footprint.
So I like what you're saying.
Wolf (26:32):
I do have one off-topic point about what you're saying,
which is um this is a goodexample, but in your example,
you have ordinary programmerswriting their own encryption.
Um totally off-topic.
I think that's a bad idea.
SPEAKER_01 (26:53):
Sure, but you could take a standard implementation
of uh uh some encryption.
Maybe you're calling uh anencryption library, um, and you
can compile and link that andsend it in uh convert it into
Wasm and send it to the browser.
You didn't have to write thatencryption code.
That encryption code might havebeen written by somebody else,
might be a library.
Wolf (27:13):
That sounds much better to me.
Thank you.
SPEAKER_01 (27:16):
Yeah, yeah.
You get the idea.
The code doesn't have to be bigto do important things.
Uh and and if it's if it'scompute intensive, I think WASM
makes a a a great uh case forfor itself by doing that.
Um there are an awful lot ofpeople using WASM.
It really surprised me when Istarted looking into it.
(27:37):
I thought it was a a veryobscure thing that maybe a
research kind of a thing, but itturns out uh Google's using it
in maps, uh in translate, inGoogle Docs.
Those are all used in Wasm.
Microsoft's using it in VisualCode.
Uh I think VS Code that runs inum Electron, is that right?
Wolf (27:58):
That is right.
SPEAKER_01 (27:59):
And and that's a that's kind of a browser type
thing.
Uh that's using Wasm.
Um I I won't say the entire theentirety of uh VS Code is
written in Wasm, but there arepieces of it that are written in
WASM.
I think that's pretty neat.
Um Visa is using it, uh thecredit card people, uh to make
(28:20):
more secure and reliable paymentprocessing systems.
Uh Tesla is using it uh in someof the safety critical code for
for controlling things likebrakes and steering.
I'm not sure I'm crazy aboutthat, but I'm I'm not wanting a
Tesla.
Wolf (28:36):
Thanks.
SPEAKER_01 (28:36):
No, no, no.
Um uh a lot of players.
Spotify is using it, Amazon isusing it, uh, Netflix is using
it in their in their webinterface.
Uh if you're a gamer and you'rerunning some of these games that
are that come across the web, uhUnity and Roblox are uh those
game engines are using Wasm.
(28:58):
Pinterest is using it.
Um it amazes me the the thepeople that are that are doing
this.
Uh so it's out there.
And it's and it's been out therefor for years.
I I think it's pretty neat.
Um uh there's a lot of tools.
When I when I started into this,it's like, how do I you know how
do I how do I write my helloworld program um and and run it?
(29:22):
Uh well it turns out there's athere's a project called M
Scriptin.
It's E M-S-C-R-I-P-T-E-N.
Uh and there's a link to it inthe show notes.
Um and it's uh it's the thecompiler, the the tool that you
use to take your C program oryour Rust program and convert it
into uh WASM.
(29:43):
Um it it works with uh Clang andLLVM.
And if you think about it, it'sreally kind of like a kind of
like a uh it wasm is justanother instruction set.
So if your language if yourcompiler can compile down to
down to um x86 or down to ARM,uh well inscript and allows it
(30:07):
to compile down to Wasm.
Uh so if you think about that,it just think about WASM as
though it's another CPU.
Wolf (30:14):
I'm not a hundred percent sure um how this arrangement
works.
Like, I can't imagine that theseWASM guys have written a Rust
compiler.
It's got to be your Rustcompiler that you already have.
Where does NScripton fit intothat?
SPEAKER_01 (30:33):
I think it's it's just the part that spits out the
the the uh uh machine dependentpart.
The uh the the CPU instructions,I think, come out of an M
script, and I think I I haven'tactually done the Rust part of
it.
I'm not a Rust developer uh likeyou are uh you are working to
(30:53):
be.
Uh I've only done the the C uhstuff, and somewhere in that
toolchain uh it it parses your Ccode and turns it into WASM
code.
Uh I think there's severallayers of of that happening.
Wolf (31:11):
I see.
Um I know in C you might beusing Clang and LLVM and
whatever.
Those allow you to stick inbackends to generate the right
thing.
Um that makes sense to me.
Uh I don't know enough aboutRust to know if it does the same
(31:31):
thing.
SPEAKER_01 (31:32):
Well, Rust is available for a lot of different
CPUs, so I think I think thatmechanism exists.
Um it would make sense that itdoes.
Uh anyway, I know for sure youcan compile Rust into Wasm.
Uh and there's tools to do that.
Um I uh when I when I looked atthe uh uh EMCC is the name of
(31:55):
the command you use within the Mscript and project.
Uh EMCC has a ton of options.
Just there's there's got to be200 options you can specify.
Uh different uh mallocks thatyou want to use, different
memory models, different allkinds of stuff.
Um and what I stumbled uponthough was uh WASM by default is
(32:18):
32-bit.
Uh you know, you think about uhlanguages these days and CPUs
these days, 64-bit has kind ofbecome the norm.
But by default, WASM compilesdown to 32-bit, which means the
memory pointers are 32-bit, theintegers are 32-bit.
Um, but there is a simple optionto run WASM 64 uh to generate
(32:39):
64-bit code.
Um it would make sense to methat that it would be faster,
although bigger, right?
Yeah, you your integers aretwice as long, your pointers are
twice as long.
Um so it could be that that32-bit is just fine for most
everything.
Um but the choice is there.
(33:01):
You you can do that.
Um there's another really neattoolkit.
Um uh it's pronounced Wabbit,it's W-A-B-T.
It's the WebAssembly BinaryToolkit.
That gives you a whole bunch oftools.
For instance, when I compile myhello world program uh written
in C down to WASM, it produces abinary uh.wasm file.
(33:27):
I can use uh Webit to convertthat binary file into a text
file.
Basically it converts uh WASMformat to WAT format, that's
WebAssembly Text format.
And then I can read the assemblycode.
And it's a lot like uh theassembly languages that I've
(33:51):
used in the past.
Um uh you can look at it and andplay with it.
And you can also write this isthe tool you would use if you
want to write WebAssembly byhand and then uh convert it to
uh a.wasm file.
You would use the Webit toolkit.
Wolf (34:08):
Now I have another question.
Um I'm as I said before,paranoid.
And uh a thing about havingsoftware that runs on the client
and works together with theserver is that attackers can be
running the client and they can,for instance, in the case of
(34:30):
JavaScript, um, they can see theJavaScript right there.
It's one of the things theydownloaded.
They m they can tell what itdoes, they can modify it to make
it do new things.
Um and so a lot of things thathappen, uh if they need to be uh
not influenced by the clienthave to happen on the server to
(34:54):
make sure attackers don't getany uh input in that way.
Um is WASM since it seems easyto take Wasm and disassemble it,
is it subject to the sameattacks?
SPEAKER_01 (35:11):
Well, it it it probably is, although you would
have to get that WASM code outof the web page and into a file.
And I think if you just do uhyou know your browser has a show
source mode, uh you wouldn't seeit.
I think you would actually haveto fetch that WASM code from the
server.
I I imagine you could do itusing curl or or um wget or
(35:35):
something to to get your handson that code.
Um but then you would have to ifyou wanted to do something
malicious with it, you wouldhave to modify that code and
then figure out a way to getthat code back into the browser
to execute something.
So it's it's uh I'm gonna saythere probably is a way to do
that, but it's a much higherbarrier uh than you know just
(36:00):
opening up a debugger andlooking at the JavaScript code
and manipulating it.
It it's it's quite a bit morework than that.
It wouldn't surprise me if it'simpossible to do what you're
thinking.
Wolf (36:10):
I think.
SPEAKER_01 (36:12):
But yeah, I think I think WASM is gonna turn out to
be much more secure in thatregard.
Um I I don't know if they'redoing code signing.
I would hope that there's aprovision for you to do code
signing uh of of your WASMmodules.
That'd be interesting to lookat.
Uh I'm not sure if that's there.
(36:33):
But um the the what when Iinstalled like in script m m
script, and it's kind of hard tosay.
Uh when I install that, it uhit's just a download from from
the web.
Uh the Wabbit uh WebAssemblyBinary Toolkit.
Um you can that's a Git project,a GitHub project, you can you
(36:56):
can fetch it that way.
Uh it had a few dependencies, soI just ended up uh installing it
using Homebrew.
Uh I'm on a Mac.
So I just used Homebrew toinstall it.
Uh and that was really simple.
And immediately I was able tostart disassembling Wasm code
and and looking at it.
So that was that was prettyneat.
Um I keep talking about the theone of the real benefits of Wasm
(37:21):
is that it performs better thanJavaScript.
So I did a few simplebenchmarks.
I I'm not a benchmarking guy,but I uh I took a program that
uh that that our friend Dave uhwell I I don't want to say that
he created the program, heactually used uh I think ChatGPT
to to create this program.
He's uh he's a sudoku player,and he over the years has
(37:45):
written several Sudoku solvers,and he asked ChatGPT to write
him a Sudoku solver uh in C.
And it's uh it's a real simpleprogram, it just uses the
recursive algorithm to to bruteforce solve a Sudoku puzzle.
Um so I played with that alittle bit.
(38:07):
Uh I ran the C program, uh the Cversion of it, compiled it and
ran C, and I put a loop in thereto run a million iterations of
this one puzzle.
And in C, a million iterationson a M1 Mac uh took 139 seconds.
(38:27):
I thought that's pretty fast foryou to run a million anything.
Uh 139 seconds.
Um I wrote almost line for linethe same implementation in
JavaScript, because they're thethose languages are similar
enough uh syntax-wise.
I I I rewrote it in JavaScript,and that took 619 seconds on the
(38:48):
same machine.
So 139 seconds at the commandline, 619 seconds in JavaScript
in the browser.
Um when I take that C programand I compile it using Wasm down
to uh a dot Wasm file and I runthat in the browser, um it was
quite a bit faster, andcertainly not as fast as the C
(39:11):
version, uh, but way faster thanthe JavaScript version.
Uh I tried several differentbrowsers.
Um to my surprise, Safari wasthe fastest browser.
It ran a million iterations in158 seconds.
So that's uh that's four timesfaster than the JavaScript
(39:32):
version.
Um slightly slower than the theC.
Yeah uh C was 139 seconds,Safari was 158 seconds, Chrome
was 181 seconds, uh and again tomy surprise, Firefox was the
slowest at 223 seconds.
These were all running the exactsame WASM code.
(39:55):
I just I I served it up from uhM script and Provides a little
uh built-in web server, uh EMrun that will serve up this
code.
Uh so I just pointed these threedifferent browsers at it, and uh
it really surprised me theJavaScript that Firefox was the
(40:15):
slowest one at two or something.
Wolf (40:17):
Can I ask you a question about your benchmarking?
Yeah.
Um you gave uh the time of 619seconds for the JavaScript.
Um what did you have executingthe JavaScript?
Was that in one of the browsersor Node.js or where?
SPEAKER_01 (40:36):
Uh that was in Chrome.
I I did not try JavaScript inthe various browsers.
Uh that was just running it inChrome.
Um I I uh WASM, it'sinteresting.
You can run WASM on the serverin Node.js.
Uh and when I ran uh WASM inNode.js, uh the Sudoku solver,
(40:59):
184 seconds.
And that's very, very close tothe Chrome uh runtime of 181
seconds.
And I think it's because Chromeand Node.js are running the same
JavaScript engine.
So it's not surprising they'rethat close in performance, at
least it doesn't surprise me.
Um but yeah, uh WASM is fasteruh for my tiny little benchmark.
(41:25):
I I'd I'd like to learn moreabout uh benchmarking and
profiling and stuff.
And I think I think this sort ofuh is gonna lead to another
future episode on profiling andbenchmarking and performance, uh
how to squeak squeak moreperformance out of your code.
I think that's coming up uhsometime in in the next few
episodes.
Um because we did learn a lotfrom this, and I and I want to
(41:47):
learn a lot more.
Um but yeah, uh uh WASM isfaster.
Well let me faster than than uhthan just pure JavaScript.
Wolf (42:00):
Let me ask you uh kind of a final question.
Uh what is the takeaway?
What are the things you saidthat people should remember?
SPEAKER_01 (42:14):
Well, first and foremost, I'd say if you if you
have a compute-intensive part ofyour application, uh and your
application, it's a web-basedapplication, but you've got
something that's computeintensive and you want to speed
it up, it probably makes sensefor you to implement that part
of your code in a in a compiledlanguage like C or C or Rust.
(42:36):
Uh, compile that down to Wasmand Um and then make that part
of your web app so that itdownloads that WASM code and
executes.
That will speed up your program.
I think that's the first thing.
Uh security and portability,that's one of the things that
that the Wasm people say it'smore secure.
(42:57):
Um I I don't know for sure thatit's more secure and more
portable than JavaScript,because that's gotten to the
point where it's it's prettysecure and portable, other than
the thing that Wolf was pointingout about uh you know, within
the debugger, you can look atthe you can you can poke into
the uh the JavaScript and andmanipulate it.
Uh but Wasm I think is is moresecure in that regard.
(43:20):
Uh and it's and it's veryportable.
So that's a uh uh maybe thesecond point I I wanted to make.
Um and almost certainly you'realready using using WASM-based
applications.
If you're using Google Maps andDocs and Netflix and Spotify and
Amazon and many, many more,you're you're running WASM code,
(43:41):
whether you realize it or not.
You won't even notice it's justrunning in the background.
Um so so yeah, I think that'sthat's kind of my uh my my
high-level view of of Wasm.
I I learned a lot uh looking atthis, and I I I I write
web-based apps.
(44:02):
I don't write a lot of stuffthat's that's really client
intensive, so I'm not sure thatI'm gonna need to write uh
WebAssembly code for for myapps, but just understanding
that it's there and that itworks, I think it's pretty neat.
Wolf (44:17):
Um so you did this research, and I'm gonna ask a
question of you that is um outof band.
I I'm just interested.
You you came into contact withall this new information.
Uh I I want to know what was themost um, I guess I care about
(44:38):
surprising or interesting, orwhat fact uh was a big peak in
your in your learning?
What what stands out?
SPEAKER_01 (44:49):
I I I think the fact that it's it's so widespread
used right now by the bigplayers.
Um it's out there, it's it'sbeing used.
That really surprised me.
I I I early on like i in thisconversation, I said I thought
it was kind of a research thing.
Um I I didn't know that it wasthat that that well used.
(45:12):
Uh, I think it's pretty neat.
That was a surprise to me.
Wolf (45:16):
Um I think that brings us to the end of this show.
I want to thank everybody who'slistening.
Please tell your friends.
Um if you liked it, leave us areview wherever you get your
podcasts.
If you haven't alreadysubscribed, uh subscription
would be great.
Uh, as I've already said, welove and value your feedback.
(45:39):
Connect with us on Mastodon atruntimearguments at hackyderm.io
or send us an email, feedback atruntimearguments.fm.
Um I I think we're having agreat time.
I think I speak for Jim when Isay that.
Um, but this is great for us.
(46:00):
I hope you are getting as muchout of it as we are.
Thanks for listening.
Jim, anything?
SPEAKER_01 (46:08):
Uh yeah, thanks for listening.
And uh we're we're reallyenjoying doing this.
And the fact that there'sthere's there's so many people
that are that are listening andgiving us feedback is just
fantastic.
Uh I think we would do this ifthere were one person out there
listening.
It turns out there's a lot morethan one person.
So yeah, we're enjoying it.
So thank you everybody forlistening, and we'll we'll just
(46:30):
keep doing this as long as wecan.
Wolf (46:34):
And we'll see y'all in the next episode.
Bye.
Host
Jim McQuillan and Wolf
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by Audiochuck Media Company.
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!