►
From YouTube: Panel Discussion: National Association of W Lovers: How We Can Create a Thriving Wasm Ecosystem
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Panel Discussion: National Association of W Lovers: How We Can Create a Thriving Wasm Ecosystem - Moderated by Matt Butcher, Microsoft Azure; Taylor Thomas, Cosmonic; Bailey Hayes, SingleStore; Oscar Spencer, Grain
Speakers: Taylor Thomas, Bailey Hayes, Oscar Spencer
Just as Java beget a littany of J-titled projects and Kubernetes gave us everything from KOPS to K3S, the emerging Wasm landscape is littered with W names. Wasm Fever has officially begun! And we at DeisLabs are releasing many Wasm-related projects. While it might seem like we're peppering the landscape with arbitrary tools and projects, we have a bigger vision in mind--one focused on building a community and an ecosystem that enables a new generation of portable and secure applications. In this talk, we articulate our ambitions for the WebAssembly community as a whole, and show how our open source projects fit in.
A
Well,
it's
been
a
great
day,
thank
you
again
for
joining
us
online
and
for
in-person.
It's
an
interesting
way
to
run
something
like
this,
but
it
has
been
a
lot
of
fun.
I
feel
like
we've
hit
a
lot
of
topics
today.
We've
hit
everything
from
machine
learning
to
networking,
to
programming,
languages,
data
storage
and
just
about
everything
in
between,
and
I
think
that's
a
good
testament
to
the
potential
we
see
in
webassembly.
A
So
I'm
matt
butcher,
I'm
going
to
be
the
moderator
of
this
panel,
I'm
going
to
pass
things
down
and
have
each
person
introduce
themselves
and
then
we'll
kick
it
off.
With
a
couple
of
questions,
I
of
course,
have
some
planned.
If
you
have
some
good
questions,
you'd
like
to
direct
to
the
panel
just
raise
your
hand
or,
let's
see
ralph,
you
can
raise
your
hand
for
any
of
the
ones
on
slack
and
I'll,
try
and
get
those
in
there
as
well
again
thanks.
A
C
D
B
We
had
a
lot
of
stuff
in
flex,
which
is
basically
flash
for
building
web
applications,
and
part
of
that
was
very
vast
graph
data,
visualization
library
and
we
at
the
same
time
had
a
bunch
of
things
like
mobile
was
starting
to
become
a
thing.
People
had
some
rumblings,
maybe
about
html5,
and
the
problem
was
okay.
How
do
we
pivot
quickly
and
and
deliver
something
in
you
know?
I
think
I
was
given
six
months,
and
so
I,
like
spanned
the
web,
there's
this
thing
called
pinnacle.
B
There
was
this
thing
called
asm.js
that
was
kind
of
hacky,
maybe
crazy,
and
we
had
cpul's
pulse
code
that
we
were
working
on
for
our
mobile
applications.
So
I
took
our
cpus
plus
code
used
a
thing
called
emscripton,
which
is
awesome,
thank
you
alone,
sakai
and
mozilla,
and
we
ended
up
with
something
shipping
that
year
and
we
were
really.
C
Yeah
for
me,
as
2017
mid-2017
and
webassembly
had
just
been
turned
on
by
default
in
all
major
browsers,
and
for
me
you
know
being
a
person
who
was
interested
in
programming
languages.
I
saw
this
as
a
unique
opportunity.
This
was
a
real
opportunity
to
bring
new
languages
or
even
existing
languages
to
the
web
without
needing
a
compiler
to
javascript
I
mean
granted.
You
know,
I'm
a
fan
of
languages
that
compile
javascript,
but
it
was
exciting
to
have
a
brand
new
assembly
language
where
the
world
was
our
oyster.
C
D
D
Alum
worked
with
matt
and
radu,
and
a
couple
other
people
you've
probably
seen
the
community
and
that
year
I
had
actually
joined
the
team
officially,
and
this
is
2019
and
I
was
working
on
helm
three,
so
helm
three
was
taking
over
my
life
and
everybody's
life,
who
was
working
on
helm
and
so
after
we
were
all
like
done
with
that.
I
got
into
kind
of
that
december
time
frame
and
was
working
on
crestlet.
The
thing
that-
and
let
me
tell
you
how
hacky
it
was.
It
was
hacky.
D
You
could
only
like
do
something
in
one
name:
space
it
was.
It
was
gnarly
and
it
was
just
but
you're
going
like
all
swedish
of
like
dirty
dirty
dirt,
just
trying
to
get
this
all
together
and
so,
but
like
that's
when
I
started
kind
of
looking
and
helping
out
and
trying
things
with
it,
so
we
were
working
on
just
kind
of
dabbling
around
it
was
out
there
in
the
wild
and
then
all
of
a
sudden.
D
I
think
it
might
have
been
ralph
your
wonderful
mc
for
this
occasion,
who
put
something
on
slack
and
I
had
happened
to
see
it
in
over
the
weekend,
and
I
saw
that
hey
it's
like
somewhere.
It
was
somewhere
in
the
top
five
in
hacker
news,
and
I
was
like
oh
and
so
that's
where
that's,
where
all
of
a
sudden,
everyone
was
jumping
all
over
chrysler
loved
it,
and
then
I
kind
of
took
over
to
the
project
lead
and
have
been
that
since
working
on
on
the
project.
D
A
I'm
gonna
kick
the
next
question
right
back
over
to
you
as
well,
because
everybody
wants
to
know
the
answer,
but
I
don't
want
to
be
anywhere
near
the
person
who
answers
it.
So
people
ask
quite
frequently
is
web
assembly
the
technology
that's
going
to
beat
containers.
Are
we
going
to
beat
kubernetes
kind
of
when
you
look
at
the
light
and
remember
you're
at
like
the
day
before
kubecon,
so
there's
a
crowd
with
pitchforks
outside
just
in
case.
D
I
know
I'm
waiting,
I'm
waiting
for
those
pitchforks
to
come
through
the
door
with
this
the
mob
to
come
in
here,
but
I
I
so
the
there's
a
couple
ways
to
look
at
this,
and
one
of
the
things
is
that
webassembly
offers
a
lot
of
things
that
could
that
containers
could
never
do
so.
Being
blunt,
like
we
always
thought,
oh
well,
it
can
run
on
any
system.
No,
it
couldn't
docker
containers
just
they're
a
linux
technology.
D
There's
zero
way
to
do
that
and
then
the
stuff
that
that
I
was
talking
about
with
matt
with
bindle
like
composing
applications
like
that
you
can
do
it,
but
it's
a
way
more
complex
process
that
involves
other
tools
and
other
connection
things
for
for
containers.
And
so
I
don't
think
that
it's
necessarily
one
or
the
other.
But
I
do
think
webassembly
is
a
better
fit
for
a
large
number
of
use
cases,
particularly
as
it
matures.
D
A
Look
the
door
just
open
yeah,
then
I'll
just
go
on
down
the
line.
Actually,
this
one,
I
would
like
everybody's
input
on,
but
oscar
I'll
start
with
you
once
we
get
to
a
standard
by
code
format,
standard
runtime,
you
know:
do
you
see
what
are
the
implications
you
see
for
what
programming
languages
and
developer
experience
using
those
programmer
languages?
A
C
I
think
it
it's
definitely
interesting
to
look
at
right.
I
think
the
the
first
point
that
I
would
definitely
look
at
is
the
debugging
story
in
webassembly.
I
think
that's
the
number
one
complaint
that
we
hear
from
folks
is
it's
really
hard
to
debug
my
my
webassembly
code
for
a
hot
minute.
We
had
support
for
source
maps
in
webassembly,
and
then
you
know
that
that's
gone
now
and
and
now
it
looks
like
we're
gonna
be
like
using
dwarf
for
everything
which
is
fine,
it'll
work
in
in
webassembly.
C
I
have
thoughts
and
feelings
about
it,
of
course,
but
yeah
I
mean
I
think
overall,
the
the
beauty
of
webassembly
is
the
fact
that
we,
it
is
a
binary
format
that
we
can
get
any
language
that
we
want
to
compile
to
it.
So
you
know
if
you're,
writing,
python
right
you're
going
to
get
to
use
all
the
tools
you
know
and
love
with
python.
You
don't
have
to
do
anything
specific
to
webassembly
and
that's
the
same
thing
with
you
know
with
russ
like
everyone
uses,
rust
and
loves
developing
in
rust.
C
C
B
B
I
definitely
fixed
a
compilation
error
between
two
different
optimization
levels
and
I
only
found
it
by
stepping
through
the
basically
assembler.
So
if
I
never
do
that
again,
that
would
be
really
cool,
but
the
the
other
side
of
it.
I
totally
agree
that
it's
it's
a
little
interesting
that
we're
this
excited
about
a
compilation
target.
B
You
know
I
I
mean
I'm
I'm
super
into
it,
it's
just
whenever
I
explain
it
to
anybody
else.
They're,
like
I
mean
I
don't
know,
I
don't
know,
and
I'm
like
yeah,
it's
secure.
It's
all
these
awesome
things
and
it's
going
to
enable
so
many
different
types
of
workloads
and
the
reality
is
yeah.
Five
years
from
now.
I
I
I
don't
know
that
we
necessarily
will
be
talking
about
wasm,
we'll
just
be
talking
about
all
the
cool
things
that
we've
enabled.
A
B
B
I
definitely
have
somewhat
resisted
learning
a
ton
of
sql
and
when
I
was
in
college
I
was
learning
mongodb,
and
that
was
because,
in
the
like
2010
range,
that
was
the
hotness
everybody's
doing
nosql,
because
we
need
to
be
able
to
scale
our
workloads
out.
We've
got
things
running
across
the
globe
and
now
we
kind
of
realized
that
we
can
design
databases
in
a
different
way.
Relational
databases,
of
course,
existed.
B
Definitely
in
the
70s.
I
don't
I'm
not
going
to
go
back
to
the
50s,
definitely
in
the
70s,
and
we
realized
that
this
type
of
having
a
relational
database
and
having
those
types
of
structures
makes
it
really
powerful
for
finding
answers
to
things
and
that's
why
you're,
seeing
all
these
different
new
databases
crop
up
that
are
being
able
to
handle
these
new
types
of
workloads,
some
people
call
them
new
sql.
Some
people
are,
you
know,
calling
them
htap
trying
to
do
this
type
of
blended
thing
and
the
the
key
difference.
B
I
think
right
now
is
the
just
the
breadth
of
data
that
we're
operating
on
and
all
the
different
data
sources
that
we're
getting
information
from
like
we're
going
to
be
streaming
things
from
iot
devices
and
on
the
edge
in
your
warehouse
right
everywhere.
So,
if
I'm
going
to
just
like
participate
about
how
things
are
going
to
be
different,
I
I
think
most
people
are
going
to
be
building
against
a
single
platform
and
those
details
will
again
fade
back
into
the
background,
and
I
really
hope
that
all
these
applications
underneath
are
built
with
webassembly.
E
Let
me
interrupt
okay,
okay,
if
you
can
are
we
on
here?
Are
we
on
so
we
had
do?
We
have
we
have
a
couple
of
questions,
but
there's
one
from
anthony
who
says:
where
do
you
see
that
it's
different
it's
a
different,
take
on
the
future
of
wasm?
Where
do
you
see
the
future
of
wasm
on
the
web?
Will
wasm
actually
be
more
useful
on
the
back
end
than
its
original
front?
End
use,
or
do
you
think,
there's
still
a
great
amount
of
potential
for
wasm
on
the
and
the
web.
C
I
I
feel
qualified
to
talk
about
this
yeah.
I
mean
even
like
just
looking
at
grain.
You
know
back
in
the
day,
we
honestly
thought
that
webassembly
was
going
to
only
exist
in
the
browser.
There
was
no
thought
that
web
assembly
was
going
to
exist
on
the
server,
and
especially
now
when
we
see
you
know
where
things
are
going
where
folks
are,
are
loving
using
webassembly
in
server
context.
There
are
people
fighting
to
make
sure
that
the
browser
context
is
not
left
behind.
C
Some
people
will
die
on
a
hill
to
make
sure
that
webassembly
in
the
browser
happens,
and
I
think,
there's
a
ton-
an
absolute
ton
of
potential
for
webassembly
in
the
browser
of
course,
like
the
major
use
case
like
for
me,
you
know
thinking
about
languages
is
yeah.
I
want
to
be
able
to
bring
my
language
to
the
browser.
I
want
all
languages
to
be
able
to
bring
their
language
to
the
browser.
I
don't
want
everyone
writing
javascript,
forever,
javascript,
it's
a
great
language.
C
It's
an
amazing
language
that
has
come
so
far
for
being
designed
in
like
a
week
or
two
right.
It's
it's!
It's
really
good!
Where
we've
we've
come,
but
we
can
do
better
right,
we
can
bring
languages
that
people
have
been
incredibly
productive
in
to
web
context.
I
think
the
moment
we
start
seeing
better
support
for
all
these
languages
in
the
browser
there's
going
to
be
a
huge,
huge
boom
that
you
haven't
seen
the
likes
of
before
happening
in
the
browser.
C
It's
definitely
on
its
way,
keep
your
eyes
open,
because
it's
going
to
happen,
especially
with
we
have
so
many
web
assembly
proposals
now
for
especially
like
bindings
to
the
dom
bindings
to
be
able
to
interact
with
javascript
a
lot
easier
than
we
do
now.
Reference
types
is
already
in.
We
can
already
start
doing
a
lot
of
these
things
now,
but
a
lot
more
is
going
to
happen.
A
C
And
even
just
to
add
on
to
to
what
I've
said,
looking
at
the
module
linking
proposals
looking
at
the
interface
types
proposal
and
looking
at
bundles
right,
actually
we're
going
to
get
to
a
really
interesting
place
where
you're
going
to
be
able
to
write
whatever
library
you
want
in
whatever
language
you
want
consume
it
from
any
other
language
you
want.
So
maybe
you
need
that
cryptography
library
and
I
love
grain
of
depth.
But
I
want
someone
to
write
that
cryptography
library
in
rust.
C
But
then
maybe
you
don't
need
to
have
that
super
low
level
systems,
processing
thing
and
you
want
to
write
some
sort
of
high
level
thing
and
you
can
write
that
in
grain
or
you
can
write
that
in
the
next
super
high-level
language
for
webassembly
that
comes
along
and
these
things
will
all
be
able
to
come
together
and
then
we're
going
to
see
the
true
dream
of
the
web
of
having
and
folks
who
talk
about
web
components.
Well,
we're
going
to
actually
make
a
real
reality.
E
D
You
apparently
question
provocateur
apparently,
but
no
so
I
I
think
I
don't
know
who
asked
that
question,
but
I
think
that's
a.
I
would
like
to
reframe
it
a
little
bit
which
totally
sounds
like
a
dodge.
I'm
not
dodging
it.
The
the
real
thing
with
with
webassembly
is
that
it
isn't
a
language
per
se.
It
is,
but
in
the
way
we've
been
talking
about
it
here,
it
isn't
a
language.
D
I
don't
think
web
assembly
in
its
raw
form
will
become
the
lingua
franca,
but
I
do
think
it
will
become
the
build
target
that
things
will
will
go
for
in
most
cases
if
it
continues
evolving
the
way
it
does,
and
that's
where
this
is,
where
I'm
going
to
latch
in
a
little
shout
out
to
the
community
and
people
who
are
listening
here.
That's
what
we're
looking
for
help
on
we're.
Looking
for
people
to
do
things
like
use
grain,
try
out
the
crazy
features
that
single
store
is
doing.
D
Give
us
feedback
on
bindle,
like
whatever
it
might
be.
Whatever
interests
you
in
the
webassembly
community,
it's
to
go
out
and
try
it,
because
we
need
the
effort
from
people
who
are
doing
these
things,
because
there
is
no
way
just
a
few
of
us
can
think
of
all
the
different
edge
cases
and
ways
that
this
could
be
used.
E
So
we
could
do
the
speculative
question
just
to
throw
it
out
there.
There
aren't
any
other
questions
currently,
but
the
speculative
question
is
a
little
bit
different,
which
is:
do
you
think
that
wasm
has
the
potential
to
achieve
native
level
performance
given
enough
time
and
potentially
custom
hardware
support,
so
pretty
speculative
go
for
it?
That.
A
No
thanks,
I
I
I
think,
I'm
pretty
optimistic
on
that.
I
think
when,
when
the
jvm
was
going
through,
some
of
its
early
iterations
and
technologies
took
off,
then
you
start
to
see.
We
started
to
see
performance
go
in
directions.
We
had
not
anticipated
some
of
the
like
reprofiling
and
dynamic
recompilation
stuff
was
super
cool
and
with
a
lot
of
the
ahead
of
time,
compiling
stuff
in
webassembly.
A
I'm
excited
about
that
too,
but
that
last
little
bit
in
that
question
is
what
really
has
me
excited
the
the
prop,
the
proposition
that
we
might
be
able
to
push
some
or
all
of
this
down
to
a
hardware
layer
or
even
be
able
to
you
know,
implement
hardware,
layer,
memory,
boundaries
or
things
like
that
that
might
allow
us
to
to
take
advantage
of
very
low
level.
Hardware
acceleration
would
be,
would
be
a
lot
of
fun
and
you're
nodding.
D
Yeah-
and
I
guess
the
other
thing
too-
that's
really
interesting
about
webassembly
modules
is
they're
very
easily
introspectible.
Is
that
word
introspectible,
and
so
you
can
take
a
look
at
it.
You
know
exactly
what
kind
of
functions
it
exports
you
can
figure
out
where
it's,
what
it's
trying
to
call
and
what
it
needs,
and
so
like.
I
think
that
that
that
to
me
sounds
like,
though
I
am
not
a
performance
expert
that
you
could
really
really
start
to
introspect
a
module
just
ratchet
down
all
the
little
bits
and
loose
pieces
to
make.
D
It
just
run
super
smoothly
on
whatever
you
need
to
do.
I
mean
just
the
fact
that
the
thing
I
always
point
out
to
people
and
if
you've
been
talking
to
me,
you've
heard
this.
So
I'm
sorry
and
you're
hearing
it
again,
but
webassembly
one
of
the
big
overlooked
parts
of
webassembly
is
the
ability
to
choose
at
runtime
the
characteristics
of
it.
D
You
can
choose
when
you
run
the
thing,
if
you
want
it
as
interpreted
jit,
aot,
whatever
it
might
be,
and
so
that
that,
combined
with
the
fact
that
you
can
just
look
at
a
module
and
really
like
just
crank
it
down,
and
you
there's
even
things
right
now,
like
wazomat,
that
just
we
were,
I
was
doing
some
testing
with
with
wasmcloud
actors
the
other
day
and
we
were
getting
20
savings
just
from
using
that,
and
so
I
think,
there's
going
to
be
a
lot
of
different
ways.
We
can
optimize.
A
So
kind
of
building
on
that
and
going
in
a
slightly
different
direction
and
security
is
always
a
big
deal
for
all
of
us
right
and
we've
heard
in
a
couple
presentations
today,
some
of
the
good
security
features
of
webassembly
that
make
it
attractive.
It's
one
of
my
favorite
things
about
webassembly
is
that
we
basically
built
something
that
matched
the
browser
security
model
and
then
went.
Oh
this
matches
all
these
other
security
constraints
we
have,
but
you
know
what
kinds
of
things
do
you
think
we
could
do
better?
B
I'll
take
that
one
so
we're
adding
a
bunch
of
different
extensions
with
wazi
with
each
introduction
of
a
new
abi.
That's
a
new
surface
area
of
attack,
but
at
the
same
time,
like
one
of
the
number
one
questions
that
I'm
getting
from
the
people
I'm
talking
to
is
like.
When
can
I?
When
can
I
get
a
hold
of
a
socket?
B
When
can
I
make
a
rest
call
and
if
I
enable
it
in
a
certain
way,
that's
not
secure
and
not
well
thought
out
like
support
for
a
content
security
policy
validating
my
headers,
making
sure
all
the
things
that
are
already
in
place
in
browsers
today,
then
it
would.
I
feel
like
that
that
vector
does
kind
of
keep
me
up
at
night,
because
I
know
I
want
to
enable
it.
But
I
don't
want
to
turn
it
on
in
my
database
until
somebody
with
a
very
strict
security,
mind
has
also
validated
it.
C
Yeah,
I
think
all
of
my
worries
around
security
have
to
do
with
module
linking
as
it
stands
right
now,
because,
typically
right
now,
for
you
know
anyone
who's,
not
using
the
official.
You
know
interface
type,
spec
and
module
linking
specs,
you're
kind
of
just
rolling
your
own
thing
and
you've
got
different
wazo
modules
coming
together,
all
sharing
a
single
memory
right
I
can.
I
can
wasn't
my
32.load
whatever
I
want.
C
And
and
that's
not
great,
but
with
where
module
linking
is
going,
a
lot
of
these
problems
are
being
solved.
The
way
interface
types
is
going
and
multiple
memories
in
webassembly.
All
of
this
is
being
solved,
so
I
I
mean
overall,
I
I
think
we
have
a
as
I've
been
saying.
We
have
a
bright
future
ahead,
yeah
right
but
yeah.
I
I
think
it's
it's
not
too
much
to
worry
about
right
now.
D
And
it's
the
the
thing
about
sharing
the
memory
space
is
honestly
what
scares
me
a
little
bit.
I
remember
the
first
time
I
went
trawling
through
the
wasm
time
code
and
this
is
not
for
any
wasn't
time.
People
listening.
This
is
not
like
something
unique
to
watson
time,
I'm
just
it's
the
one.
I
was
trawling
through
at
the
time
and
like
I
was
sitting
there
going.
Oh,
that
is
just
a
pointer
to
a
random
place
in
memory.
D
Okay,
now
well
like
giddy
up
like
guns
in
the
air
shooting
on
a
horse
kind
of
wild
west
thing.
I'm
like
okay,
that's
a
little
scary.
I
mean
it's
very
well
like
sandboxed
and
put
together,
but
the
fact
that
you
are
just
taking
a
random
pointer
to
a
random
block
of
allocated
memory
screams
to
me
of
being
something
scary.
So
I
I
can
see
there
being
some
some
possible
issues
there.
A
Yeah
and
I
think
yeah,
a
good
distinction
to
make
in
some
of
these
is
the
danger
to
the
guest
module
from
itself
or
the
libraries
it
loads
and
the
danger
to
the
host.
That's
running
the
guest
module,
a
lot
of
the
ones
we're
talking
about
here.
Are
the
guest
module
being
able
to
do
bad
things
to
itself.
Some
of
these
could
potentially
become.
You
know
we
expose
an
api
into
the
guest
module
that
allows
it
to
make
system
calls.
A
That's
when
I
think
it
does
start
getting
dangerous,
but
one
of
the
things
that's
really
building
on
what
you
said
oscar
one
of
the
things.
That's
really
exciting
me
about
the
way
some
of
the
component
stuff
is
going
is
that
it
looks
like
if
things
play
out
the
way
that
they're
moving
right
now
say
you
have
the
typical
case
where
openssl
has
a
has
a
bug
in
it
and
in
containerland
that
means
we
have
to
go
rebuild
every
single
container
image
that
compiled
in
that
particular
openssl.
A
One
and
one
of
the
things
that's
exciting,
is
that,
with
the
component
model,
we
may
be
able
to
hot
swap
in
a
patched
version
version
of
openssl
without
so
much
as
redeploying
things,
and
that
would
be
that
would
be
just
so
great
to
see.
I
know
we
are
now
out
of
time.
Thank
you
all
very
much
for
joining
us
today
and
again.
Thank
you
to
all
of
you
who
have
stuck.