►
From YouTube: Keynote: View from Above: A Birds-eye View of the Wasm Landscape and Where... Bailey Elizabeth Hayes
Description
Keynote: View from Above: A Birds-eye View of the Wasm Landscape and Where It's Heading - Bailey Elizabeth Hayes, Principal Software Engineer, SingleStore
The technology landscape for Wasm is growing every day. Join me for a tour of WebAssembly, where we will analyze areas of rapid growth for Wasm to predict the future of application development. Wasm is finding a home in every layer of the technical stack. When it comes to creating plugins and adding extensibility to projects, Wasm is rapidly becoming the de facto solution with excellent support for multiple languages. Another trend is serverless where we are seeing Wasm revolutionize application development via actor and event-driven architectures. Looking towards the future, it's not hard to imagine Wasm becoming the default runtime for the entire stack. Imagine applications compiled to Wasm, distributed and networked with a Wasm filter, admitted by a Wasm Open Policy Agent rule, versioned using a Wasm native package manager, Wasm clients that run on any device in the web or edge device, and the expressions used to operate on data are driven by Wasm.
A
So
my
name
is
bailey
hayes
and
I
am
a
principal
software
engineer
at
single
store
and
today
I'm
going
to
give
you
a
bird's
eye
view
of
the
webassembly
landscape,
but
first
we're
going
to
do
a
little
brief
history.
So
it's
2012
and
I
realized
that
I
have
a
need
for
wasm,
but
wasm
doesn't
exist.
Yet
we
have
a
very
large
code
base.
A
That's
a
data
visualization
library,
but
and
we're
already
found
a
way
to
take
portable
c
plus
plus
code
and
run
it
in
a
number
of
different
clients,
both
in
desktop
environments
and
in
mobile.
And
now
we
want
to
find
a
way
to
do
that
with
the
web
and
that's
where
we
enter
with
what
I
believe
is
the
greatest
hack
of
all
time.
A
A
Finally,
at
the
end-
and
this
was
the
last
thing
that
made
our
code
work
in
ie,
because
we
were
running
out
of
memory
trying
to
jit
our
asm.js
and
so
this
kind
of
forced
it
into
an
interpreted
mode,
so
hacks
all
around
so
with
asm.js.
We
proved
a
point
that
there
was
a
need.
There
was
more
than
just
games
that
were
interested
in
running
real
code.
A
In
the
web
computationally
intensive
code
in
the
web
and
that's
when
a
number
of
the
browser
and
vendors
got
together
and
pushed
forward
a
specification
webassembly
and
that
design
phase
started
in
2015.
Basically
the
moment
it
was
available
in
any
browser,
we
began
compiling
to
it
with
a
tool
called
emscripton,
and
you
know
by
2019
it's
a
recommended
web
standard
and
officially
the
fourth
language
of
the
web,
now
we're
all
here
at
wasmday.
A
I'll,
give
you
a
quick
definition
and,
and
the
way
that
I
think
of
it,
is
that
webassembly
is
a
compilation
target,
it's
portable,
it's
language,
agnostic,
but
more
than
anything,
we
always
have
running
jokes
here
at
these
different
conferences
and
for
the
rest
of
the
week.
You're
gonna
hear
jokes
about
yaml
because
of
kubernetes,
and
so
I
have
to
say
this:
it's
webassembly
is
neither
web
nor
assembly.
Even
in
2015.
A
We
knew
that
we
were
targeting
something
that
wasn't
just
for
browsers:
that's
really
surprising
to
people
given
the
name,
and
I
would
say
that
around
that
time
we
didn't
quite
have
the
term
cloud
native.
I
actually
looked
it
up
and
wikipedia
in
2019
was
when
cloud
native
became,
like
you
know,
kind
of
a
more
common
term.
The
the
the
cncf
I
believe
was
founded
around
2015,
so
you
know
we
could
have
ended
up
with
web
native
as
our
term,
for
example.
A
This
is
what
we
were
kind
of
thinking,
even
in
2015,
for
for
the
problem
that
I
was
talking
about
that
I
was
trying
to
solve.
I
have
an
application
I
have
to
deploy
to
a
bunch
of
different
targets,
those
targets
I
have
to
have
specific
platform
bindings
for
each
one
of
those.
So
it's
almost
like.
I'm
writing
my
own
little
runtime,
that's
specific
to
my
application
on
every
platform
and
I'm
compiling
each
of
those
and
that's
incredibly
expensive,
and
then
for
each
one
of
those
projects.
We
had
separate
teams
running
each
one
of
them.
A
Now,
what
I
would
love
to
see
is
being
able
to
compile
an
application
once
to
webassembly,
as
as
a
common
compilation
target
and
and
then
have
the
runtimes,
be
something
that
that's
sort
of
managed
in
an
open
way.
That's
common
across
many
different
applications,
and
so
I
told
you
I
was
going
to
give
you
a
bird's
eye
view.
A
A
A
Is
that
say,
for
example,
one
of
the
one
of
the
early
things
that
reported
is
being
able
to
access
environment
variables
and
if
I
wanted
to
have
a
driver
program
and
has
access
to
envs,
then
only
a
set
of
the
keys
that
are
exposed
to
my
webassembly
instance
are
available
to
me
via
wazzy
and
to
compile
to
wazzy
it's
it's
really
simple.
You
typically
in
any
of
your
top
level
languages.
You
have
a
top-level
target.
A
A
One
other
thing
that
I
do
mention
is
that
there
is
no
networking
protocol
yet
for
that's
been
approved
for
wazzy,
but
there's
a
really
interesting
take
on
this,
which
kind
of
pushes
the
the
work
into
the
run
time
via
waggy.
So
long
as
your
runtime
is
waggy
compatible
and
your
webassembly
module
meets
some
of
those
contractual
pieces,
then
you
are
able
to
do
networking
style
work
and
I
think
we'll
get
a
few
more
talks
about
that
today.
A
Now
I
keep
talking
about
the
runtime
and,
and
the
reality
is
that
there
are
a
lot
of
them.
There
are
20
plus
runtimes
that
are
out
there.
There
are
many
different
compilers,
because
working
on
performance
is
fun
and
but
more
than
anything,
there
are
also
many
different
platforms
that
are
cropping
up
for
webassembly.
A
A
lot
of
these
are
really
interesting
to
me.
Personally,
I
think
that
they're
new
evolutions
on
new
types
of
computing
paradigms
and
it's
incredibly
exciting
as
far
as
languages.
Well,
there
are
a
ton
of
them,
so
I'm
not
going
to
list
them
all.
I
think
again
it's
about
20
plus,
but
if
you
have
a
compliant
language
and
that's
your
favorite
language,
while
you're
in
luck,
it's
very
likely
that
that
has,
as
already
has
support
for
wasm.
A
The
reason
why
I
wanted
to
touch
the
slide
specifically
is
because
there's
this
common
misconception
that
you
have
to
write
and
rest
to
be
able
to
work
with
webassembly,
which
is
kind
of
hilarious.
For
me,
because
you
know,
obviously
my
original
case
was
c
plus
plus
and
that's
what
I've
been
bringing
forward
all
along.
A
But
I
would
say,
even
in
2015,
cpus
plus
and
c
were
still
the
main
things
that
you
were
able
to
use
with
webassembly,
because
web
assembly
and
its
precursor,
as
in
js
and
and
that's
largely
because
inscription
built
off
of
the
llvm
tool
chain
now
obviously
rust
is,
is-
has
had
an
amazing
complement
with
wasm
they've
really
grown
and
supported
each
other.
And
if
you
think
about
it,
a
lot
of
the
things
that
are
really
nice
and
rust,
and
a
lot
of
things
that
motivate
developers
to
use
rust
are
really
similar.
A
Now
I
added
a
c
in
front
of
these,
and
that's
because
it's
taken
the
c
interpreter
and
and
that
piece
has
been
what's
been
compiled
to
webassembly
now
there
are
a
few
wasm
specific
languages
like
grain
and
assembly
script
for
simply
script.
I'm
going
to
call
that
out
specifically
because
it
is
also
you
know
you
would
say,
an
interpreted
language
if
you're
not
familiar
with
assembly
script,
but
you
are
familiar
with
typescript
you'll
find
using
assembly.
A
Script
is
really
nice
because
the
syntax
is
very
similar,
but
one
key
difference
is
that
assembly
script
is
ahead
of
time
compiled.
I
think
that's
really
compelling
and
really
interesting,
very
innovative.
What
we've
been
seeing
is
a
lot
of
interpreters,
get
copaldo,
asm
and
and
not
a
lot
of
scripting
languages
getting
ahead
of
time
compilation.
So
I'm
really
looking
forward
to
seeing
the
innovation
that
happens
in
this
space
going
forward.
A
A
The
idea
is
that
it's
a
language,
neutral
approach
to
building
webassembly
applications
and
you're
able
to
build
them
on
top
of
each
other,
like
branches.
If
you
thought
I
was
done
with
the
bird
analogies,
you
don't
know
me,
and
so
as
you're
able
to
build
many
different
wasm
modules
on
top
of
each
other.
We
can
do
something.
That's
really
incredible!
That
hasn't
been
done
before.
A
Have
you
ever
experienced
the
situation
where
you're
you're
working
at
a
company-
and
you
know
you're
mostly
invested
in
one
language
and
you
go
to
your
boss
and
you
say:
hey.
I
found
this
library.
It
does
exactly
what
we
need.
I
don't
have
to
write
all
this
code.
Can
we
use
it
and
they
say
well?
Am
I
going
to
have
to
enable
the
sego
flag
and
you
say
well
yeah,
maybe,
and
they
say
no.
We
can't
do
that.
A
So
something
like
the
component
model
can
really
mix
things
up
and
change
things
for
the
better.
So
before
I
was
talking
about,
you
know
this
giant
matrix
that
you
have
of
applications
by
you
know
by
operating
operating
systems
and
targets
to
just
having
one
single
compilation
target,
but
now
imagine
that
I've
really
exploded
that
sandbox
right,
because
now,
if,
if
things
support
the
component
model,
we
can
get
to
the
point
where
we
have
access
to
millions
of
different
tools.
A
If
that
excites
you
and
you
find
it
interesting,
I
recommend
pushing
your
company
to
join
the
by
code
alliance.
It's
pushing
that
proposal
and
many
others
forward
if
you're,
an
individual
contributor
and
you're
interested
in
working
like
in
the
w3c,
which
is
pushing
for
the
webassembly
specification
or
you
just
want
to
get
involved
in
the
community.
The
place
that
I
linked
here
is
wasn't
builders,
that's
a
really
great
place
to
get
started.
A
Now
we're
going
to
enter
a
part
where
I
think
is
a
little
bit
more
of
my
opinions
of
the
web
assembly
landscape,
but
we'll
start
with
a
really
simple
one.
These
are
terminals
that
are
written
in
rust
when
something
is
written
in
brass.
It's
sort
of
a
no-brainer
to
write
to
to
make
your
plug-in
model,
be
something
that
uses
wasm,
because
rust
and
wasm
are
so
complementary
to
each
other.
A
A
A
If
you're
interested
in
that,
I
recommend
checking
out
the
their
engineering
blog.
It
has
a
fantastic,
deep
dive
now
we're
here
at
cncf,
so
you're,
probably
already
familiar
with
these
two
projects.
Envoy,
is
a
sidecorp
proxy.
It
there's
a
cloud
native
computing
foundation,
project
called
wasmproxy
that
lets
you
extend
envoy
so
that
you
can
write
your
own
http
filters
and
transformations.
A
I
think
that's
one
of
the
trends
that
we're
going
to
start
seeing
more
is
near
data
processing,
and
hopefully
that
gives
us
better
performance.
But
more
than
anything,
it
means
that
we
didn't
have
to
move
that
data
out
over
a
network
request,
so
we're
getting
data
locality
as
a
bonus.
Now,
I'm
not
an
expert
in
this
space,
but
what's
been
explained
to
me,
is
that
smart
contracts
run
on
the
blockchain
and
once
some
set
of
conditions
has
been
met,
the
smart
contract
executes
any
computer.
A
That's
participating
on
the
blockchain
like
that
could
be
your
own
desktop
can
execute
that
smart
contract.
That's
got
to
be
safe
and
secure
in
sandbox.
Well
to
me,
that's
a
plug-in
and-
and
so
all
of
these
so
far
are
really
in
my
mind,
different
ways
of
writing.
Plugins
now
a
lot
of
people
don't
think
of
data
processing
as
a
plug-in
system,
but
there
are
several
out
there
already.
A
A
So
this
is
a
term
that
we're
starting
to
see
crop
up
more
often
when
people
talk
about
webassembly
and-
and
so
this
is
like
the
case
that
I
work
on,
which
is
compile
your
code
to
wasm
using
you
know,
whatever
language
is
supported
and
then
using
a
single
sql
statement,
you
say,
create
function
and
you
pass
in
your
wasm
module,
maybe
over
an
http
url,
but
what's
so
interesting
about
this.
Is
that?
Because
we
take
that
wasm
module
and
we're
a
distributed
database,
we
now
are
able
to
move
it
across
many
nodes
in
our
stack.
A
Now
I
live
in
north
carolina,
so
you
might
not
know
this
bird
but
he
lives
in
my
backyard.
I
took
a
picture
of
him
and
then
I
drew
this
picture.
It's
called
a
woodpecker
and
he
the
woodpecker,
that's
in
my
backyard,
is
constantly
trying
to
break
into
my
house,
and
so
I
thought
he
was
the
perfect
analogy
for
talking
about
security.
A
A
But
that's
not
the
interesting
part
here.
The
interesting
part
is
thinking
about
all
the
trends
and
pressures
that
we're
experiencing
as
an
industry
and
how
that's
going
to
really
push
people,
I
believe
to
wasm
the
first
one
being
that
software
supply
chain
attacks
are
increasing
every
day
and
finding
ways
to
mitigate
all
the
different
vulnerabilities
that
we
have
across
our
hundreds
of
dependencies
for
applications
is
going
to
be
key.
Wasm
is
a
really
interesting.
Take
on
that
approach.
For
example,
there's
a
methodology
that
firefox
employs
that
is
very
novel.
A
It
takes
basically
parts
of
their
application,
stack,
compiles
those
to
wasm
modules
and
then
takes
those
wasm
modules
and
runs
them
eventually
in
machine
code.
So
what
it
means
is
that
it
mitigates
entire
swaths
of
zero-day
vulnerabilities
for
a
single
monolithic
application.
So
it's
really
in
my
mind,
taking
the
way
that
you
write
applications
and
twisting
it
to
be
sort
of
like
a
plug-in
model
within
your
apps.
A
I
believe
liam's
been
pushing
this
idea
several
times
now.
I
haven't
heard
a
lot
of
other
people
talk
about
it
and
I
think
it's
really
key
when
we
think
about
how
and
where
we
store
our
data
with
webassembly.
We
are
very
explicit
about
our
memory
model
and
who
shares
what
and
and
where,
and
so
the
capability
based
design
of
wazi,
I
think,
is
going
to
be
really
key
and
considering
things
like
privacy
law.
A
They
typically
have
many
different
libraries
they're
connected
to
many
different
data
sources,
they're
running
across
many
different
devices,
typically
deployed
in
some
type
of
orchestration
across.
You
know
many
many
different
operating
systems
in
theory,
so
my
question
to
you
is:
where
would
I
write
only
one
language
anywhere
in
this
stack?
Do
I
expect
only
one
language
to
exist?
Ever
probably
none
of
these.
Probably.
A
I
want
portability
in
each
layer
of
this
stack,
obviously,
everywhere
we
need
safety,
security
and
performance,
but
when
we
think
about
you
know
what
are
the
things
that
each
layer
of
the
stack
actually
need.
We
know
that
we
need
many
different
languages,
portability,
safety,
security,
but
also
you
know
just
being
fast
to
download
and
start
because
it's
not
just
one
tree,
it's
a
forest.
A
So
let's
talk
about
the
next
area
with
serverless
and
functions
as
a
service.
Now
I
believe
that
one
of
the
main
reasons
why
this
hasn't
been
as
popular
as
what
I
originally
expected
it
to
be
is
because
of
cost.
At
the
end
of
the
day,
we
were
still
running
the
same
amount
of
compute
and
memory
needed
to
run
a
specific
task,
but
with
wasm
we
really
have
an
interesting
take
on
how
to
vastly
reduce
our
cost
for
these
cases.
A
So
because
wasm
starts
faster
than
containers,
because
it's
lighter
weight
and
has
a
smaller
memory
footprint
and
also
because
we're
we're
able
to
actually
scale
it
to
zero,
because
it
is
so
fast
in
many
cases
and
and
functions.
We
have
to
already
have
some
pre-warmed
state
of
it
so
that
we're
able
to
service
requests
quickly
right,
because
containers
may
take
several
seconds
to
start.
A
But
webassembly
modules
may
take
a
few
milliseconds,
maybe
even
microseconds,
but
I
think
more
than
anything,
that's
going
to
push
people
to
to
enter
our
webassembly
landscape
is
cost,
and
what
we
know
is
that
the
cloud
is
expensive.
It's
given
us
a
lot
right.
We've
been
able
to
write
in
microservices,
deploy
faster,
independent
of
each
other,
but
people
aren't
going
to
use
our
technology
the
technologies
that
we
create
unless
it
solves
problems,
and
one
of
the
biggest
problems
in
cloud
today
is
cost.
A
So
let's
talk
a
little
bit
about
the
future.
This
is
completely
my
opinions
and
I'll
start
with
a
really
aggressive
one,
which
is,
is
webassembly
going
to
be
the
next
default
compilation
target.
Well,
if
you
believe
me
that
it
is
the
last
plug-in
model
that
you'll
ever
need,
then
wasm
really
could
be
a
default
compilation
target,
especially
for
many
languages,
obviously
the
languages
that
directly
support
webassembly
as
a
first
language,
but
I
expect
many
others
now.
A
A
If
you
know
that,
then
what
we're
really
talking
about
in
the
space
of
innovation,
it's
really
the
future
of
runtimes
as
a
whole
and
if
we're
there
well
do
we
have
one
package
manager
to
roll
them
all.
No
we've
been
trying
that
for
a
long
time
we
just
introduced
new
ones.
I
don't
expect
that
to
be
the
case,
but
I
do
expect
package
managers
to
start
serving
webassembly
because
other
many
of
our
top-level
languages
now
support
wasm
and
can
pull
them
in
and
link
against.
So
with
we're
already
seeing
this
really
with
npm.
A
So,
with
the
component
model,
we're
going
to
finally
get
universal
language
and
library
support,
but
we'll
also
see
because
of
that
the
democratization
of
our
software.
We
will
be
able
to
work
with
every
layer
of
the
stack
because
they're
able
to
finally
interrupt
between
each
layer.
It's
no
longer
the
case
that
you're
a
front-end
engineer,
and
you
can't
use
a
really
interesting
breast
library
or
you're
a
systems
level
engineer,
and
somebody
wrote
something
in
go
that
you
want
to
be
able
to
use.
A
You
know
at
a
lower
level.
I
think
something
like
this
is
really
going
to
make
it
so
that
it
doesn't
matter
who
and
where
you
are
on
your
skills
journey,
you're,
going
to
be
able
to
use
the
best
component
and
library
and
tool
for
the
job
and
that's
really
exciting-
and
I
think
we're
all
here
today
so
that
we
can
push
this
technology
forward.
And
you
know
I
I
really
encourage
everybody
to
to
reach
out
in
the
community,
because
you
know
birds
of
a
feather
flock
together.
Thank
you.