►
From YouTube: 4 October 2018 Meeting
Description
The Rust WebAssembly Working Group meeting from 4 October 2018.
B
A
Yeah,
so
this
RFC
has
been
open
for
a
bit
of
a
second
I
really
should
have
popped
this
up
ahead
of
time.
Good
job
me
anyways,
I,
wanted
to
check
in
and
see.
I
know
that
there
is
a
question
of
what
the
algorithm
that
was
impact
will
use
when
writing
this,
which
I'm
happy
to
write
out
I,
don't
think
it
will
be
terribly
complicated,
but
I
just
wanted
to
see
if
there
was
any
like
outstanding
things
to
address
that
haven't
hasn't
been
commented
on
it.
B
Thing
that
I
forget
who
it
was,
but
someone
was
asking
about
and
I
think
it
was
a
fine
point
to
to
bring
up,
was
like
why.
Why
not
generate
the
package.json
from
the
car
Gautama
like
we
agreed
Eve
it
like
what
we
want
to
emit
is
a
package.json
right,
because
that's
what
all
the
JavaScript
tooling
uses,
there's.
Also
the
question
of
like
like
since
they're
at
different
phases
like
we
could
potentially
generate
the
car.
The
package.json
from
the
card
with
jamon
I.
B
A
For
the
sake
of
anyone
watching
this
video
I
can
talk
about.
Why
I,
don't
think
that's
a
good
idea
here
and
then
I
will
make
sure
that
it's
clear
in
the
RFC,
but
in
using
a
package.json
is
beneficial
because
they'd
have
towards
us
some
cool
new
features,
as
well
as
juices
the
complexity
of
trying
to
take
one
package
management
system
and
jam
it
into
another
one,
and
so
I'm
gonna
start
with
the
jamming
one
package
management
system
into
another
one,
and
then
I'll
finish
with
why
it
gives
us
some
cooling
features.
A
So
the
first
thing
to
say
is
that
Westpac
has
always
generated
a
package
JSON
and
it
will
continue
to
generate
a
package.
Json
writing
package.
Json
is
from
hand,
can
be
a
huge
pain
in
the
butt
and
I.
Don't
recommend
them
and
I
think
that
this
process
can
also
probably
help
us
avoid
having
people
to
write
package
Asians
from
hand,
but
I'll
talk
about
that
in
a
second.
So
the
big
thing
is
that
first
off
there
is
no
section
for
NPM
dependencies
in
a
cargo
travel,
so
we'll
have
to
create
one
to
house.
A
A
So
I,
don't
think
we
want
to
do
that,
and
so
that's
why
I
don't
want
to
put
them
in
there,
but
the
other
cool
thing
about
having
people
write
out
a
package
JSON
which
I
believe
POW
and
actually
like.
This
is
not
necessarily
my
idea.
This
is
a
Howard's
suggestion
on
the
RFC.
Was
we
don't
currently
like
right
now?
We
basically
make
a
cargo
Tamil
or
make
a
packages
I'm
from
your
cargo
table
all.
A
However,
if
there
are
things
in
your
cargo
tamil,
that
you
would
want
to
change
as
it
becomes
a
package
JSON,
you
currently
have
to
do
that
manually.
If
we
have,
you
generate
like
write
a
package.json
and
then
that
gets
processed
by
wise
impact.
What
we
can
do
is
instead
of
ignoring
redundant
fields
across
your
package.json
and
cargo
Tamil.
You
can
use
the
package.json
that
you
include
in
your
crate,
to
override
fields
in
your
cargo
tombow.
A
Different
is
like
a
good
idea,
but
having
you
write,
a
cargo
tamil
or
having
you
write,
a
package.json
that
is
then
processed
through
web
pack
will
give
you
some
options
to
override
stuff,
which
I
think
it's
cool
and
it's
currently
not
an
option.
And
if
we
wanted
to
give
people
the
option
to
override
package.json
fields,
then
I
would
recommend
that
they
write
a
package
JSON
anyways
and
we
would
just
do
a
dip
on
those.
A
So
I
don't
know
it
seems
like
it
has
several
benefits
and
then,
additionally,
with
the
packages
and
I
guess
like
if
you
push
a
package
JSON
like
source
up
to
github,
all
of
these
tools
know
how
to
use
it.
Like
NPM
audit
knows
how
to
use
it.
Greenkeeper
depend
a
lot.
I
personally
am
NOT
interested
in
teaching
something
like
greenkeeper.
How
to
read.
Npm
packages
out
of
a
cargo
gobbled
and
I
I
feel
like
it's
a
hard
sell,
though
again
I
can
admit
that
it's
certainly
possible
to
do,
but
I
don't
think
it's
idea.
B
B
I
just
wanted
to,
like
reiterate
that,
like
basically
like,
like
I,
think
it
would
be
viable
to
generate
a
package
JSON
from
like
extra
metadata
fields
in
a
cargo
tunnel,
but
like
I,
think
the
reason
that
we
shouldn't
because
of
the
things
you
listed
but
like
to
generalize
them
all
into
like
a
one-sentence
thing,
would
be
like,
like
you,
don't
have
to
figure
out
what
the
mapping
is
like
like
you're
trying
to
generate
a
package.json.
It's
not
like
something
that
you
can
ignore.
You
have
to
kind
of
know.
B
What's
going
in
there,
and
so
you,
you,
don't
have
to
figure
out
a
mapping
from
anything
to
what
does
that
mean
it's
going
to
generate
in
my
package
JSON
like
I,
you
just
get
to
control
it
directly
and
I
think
that's
a
valuable
thing
to
have,
but
so
backing
up
a
little
bit.
You
said
something
about
lesson:
pack
is
always
generated
package
JSON
and
how
we
don't
want
people
to
write
a
catchy
songs
by
hand,
but
that
also
seems
at
odds
with
like
we're.
A
A
So
there's
plenty
of
functionality
in
the
NPM
client
that
we're
wrapping
as
well
as
stuff
that
we
can
add
ourselves
there
like
typing
like
wise
and
pack
depth
or
something
where
we
could
basically
just
have
it
write
them,
write
it
for
them,
so
I,
don't
I.
Don't
actually
think
that
that's
like
an
incredibly
difficult
thing
to
do
is
something
NPM
already
does,
and
we
can
also
do.
B
A
But
as
I
can
get
a
bunch
of
what
I
just
said,
written
down
and
probably
like
a
more
coherent
way,
I
guess
I
just
want
to
see
if
there's
any
like
huge
blockers,
because
there
was
a
lot
of
conversation
on
the
RFC,
but
a
lot
of
it
felt
like
it
was
a
bit
hard
for
me
to
necessarily
be
able
to
tell
how
much
of
it
was
relevant
and
how
much
of
it
wasn't.
So,
if
there's
any
like
big
things
in
our
head
that
we
think
are
like
real
blockers.
B
So
the
the
one
potential
crinkle
that
I
have
is
say:
I'm,
writing
a
library
crate,
not
something
that's
compiled
to
Assam,
but
something
that
is
designed
for
wasm
and
crates
that
are
themselves
compiled.
Azzam
to
use
and
I
want
to
have
a
dependency
in
the
final
generator
wasm.
On
some
NPM
package
like
say,
if
console
error,
panic
hook
wanted
to
depend
on
NPM
package
to
pretty
print
objects
or
whatever
some
kind
of
thing
like
that,
like
is
use
webpack,
going
to
find
its
package
JSON
and
bring
that
into
the
larger
project
as
well
and
I.
B
A
D
Would
say
at
least
at
least
for
me:
I
would
probably
be
advocate
for
saying
that
the
MVP
should
include
the
recursive.
Traversal
was
so
clean
in
transit,
Lee,
but
I
also
think
it's
it's
pretty
simple
to
do
in
terms
of
like
we
would
just
sterilize
out
a
directory
containing
karo
Tamil
for
all
lesson.
Bunch
and
stuff
I
wasn't
banjo.
We
just
always
do
this
and
it
was
a
package
that
iterates
over
all
those
and
slips
of
JSON,
so
I
think
it
will
petition
wise.
It's
pretty
simple,
yeah.
A
I,
don't
anticipate
it
would
be
hard.
I
was
just
trying
to
think
because
I
did
not
think
about
this.
Yet
I
wasn't
sure
if
there'd
be
anything
weird
but
I,
don't
know,
I.
Think
you're,
naive
first
thing
that
actually
does
the
recursive
call
shouldn't,
be
that
difficult
and
like
practically
speaking,
I'm,
not
sure
we
have
those
crates
yet
so
that's
kind
of
strays,
oh
but
I
mean
we
should
have
them
soon.
So
I've.
D
B
A
B
B
D
D
A
D
A
Okay,
so,
like
one
thing,
I
want
to
do
is
just
say:
I'm
gonna
make
a
final.
It's
probably
not
correct,
but
like
a
big
revision
to
the
RFC
I
would
really
love
to
get
it
approved
by
the
next
meeting,
because
I
think
the
next
releases
should
contain
the
implementation,
or
at
least
whatever
we
decide,
is
the
first
level
of
that
implementation.
B
D
I
don't
know
if
we
want
to
talk
about
it
here,
but
we
haven't
been
able
to
make
a
lot
of
progress
on
the
inheritance.
Sorry,
well,
the
only
other
RC
we
have
that
we
could
possibly
be
and
I
don't
know
if
we
wanna
like
schedule
a
particularly
dedicated
meeting
to
talk
about
that
or
do
about
through
that
here,
but
we
might
just
want
to
try
and
make
some
progress
on
this
to
try
and
push
a
forest.
It's
got
a
little
bit
of
discussion
recently
as
well
and.
A
B
A
D
D
Engine
updates
we've
been
fixing
bugs
I.
Guess
we
fixed
a
bug.
We
fixed
a
few
bugs
with
platform
compatibility,
which
we
realized
from
the
obsess
release
for
people
to
actually
tried
examples
and
browsers,
and
they
didn't
work
which
is
great
treinen.
So
some
issues
with
safari
have
been
fixed,
like
I,
do
and
like
scoping
of
that
I
kind
of
forget
and
then
there's
another
one
with
in
edge.
D
We
don't
support
age,
does
not
have
support
for
text
in
clear
text,
decoder,
texting,
Twitter
and
texting
cooter,
so
that's
been
tweaked
and
fixed
in
a
sense
that
we
had
like
some
example
with
it
when
that
web,
that
configuration
of
one
way
to
do
it,
although
it's
highly
unlikely
to
be
the
most
idiomatic
way
to
do
it
so
group
install,
was
welcome
to
the,
but
otherwise
all
the
examples
compiled
online
should
be
working
on
worse
than
that
I.
Don't
even
II
as
a
budget.
A
So
I
have
not
super
paid
attention
to
was
in
pack
after
the
huge
release.
Last
week,
this
small
break,
which
was
nice
but
and
what's
really
awesome,
is
that
was
a
huge
release,
but
we
haven't
gotten
that
many
issues
so
either
is
that
means
that
nobody
is
using
it
or
maybe
more
optimistically,
it's
actually
working
pretty
well.
We
did
get
this
one.
C
A
Parcel
plugin
wasm,
which
I'm
not
actually
familiar
with
and
is
something
that
I'll
bring
up
when
we
talk
about
the
bundler,
but
it's
issue
380,
and
you
can
definitely
see
that
the
path
is
doing
something
pretty
bonkers
uh-huh,
and
so
one
of
the
things
that
I'm
kind
of
curious
about
is
like
we
do
test
on
App
there.
So
this
means
that
it's
not
our
app
fair
test,
don't
cover
this
and
it.
A
Was
mackenzie
clark
who
has
been
doing
a
bunch
of
stuff
on
guys
impact
lately
opened
up
a
pull
request
which
is
using
this
canonicalized
path
function,
which
I
guess
is
different
from
canonicalize,
but
anyways
I.
It
might
just
be
something
we
want
to
pay
attention
to
because
I
don't
know
I,
don't
know
how
that
Bend
and
also
it's
not
covered
by
our
caste.
So
I'm
like
a
little
surprised,
I.
B
I
wouldn't
be
surprised
if
this
was
introduced
in
the
parcel
plugin
but
like
either
way.
It
seems
clear,
like
we
just
need
to
dig
in
further
and
isolate
the
issue.
Yeah
I
yesterday,
just
in
general
lesson
packs
that
yesterday
I
saw
someone
tweet
that
they
were
live-streaming
going
through
the
rust
and
web
assemblies
tutorial
and
so,
like
I
took
notes.
I
watched
them
like
the
first
hour
or
so,
and
I
took
notes
on
what
they
were
doing
and
the
like.
The
biggest
thing
to
come
out
of.
B
That
was
like
something
that's
already
on
our
radar,
but
just
makes
me
prioritize.
It
more
is
emitting
output
for
commands
that
wasm
Packard's
that
are
taking
a
while,
because
the
first
time
you
do
build,
you
have
to
build
lesson
behind
Jim
right
and
like
that
takes
like
longer
than
a
minute,
and
then
you
just
have
this
like
spinner
sitting
there
and
basically
like
the
person
who
is
streaming
and
all
the
people
in
the
chat
like
everyone
was
like.
Is
it
doing
anything?
Is
it
just
like?
Is
there
a
bug.
A
B
A
A
A
It's
like
or
to
target
note,
even
though
we
have
that
functionality
and,
like
literally
somebody
had
a
question
on
the
issue
tracker
it
was
like.
Can
I
use
this
for
note
and
then
I
think
good
tozi
was
confused
about
what
they're
asking
and
like
wrote,
something
that
was
kind
of
weird
but
then
I
just
followed
up
and
I
was
like
yeah.
We
we
can
do
that.
Does
this
work
for
you
and
they
were
like.
A
Oh
yeah
thanks,
it's
perfect,
so
I
would
really
love
to
have
the
website
have
kind
of
like
three
calls
to
action
which
are
like
I,
don't
know,
learn
more
about
bind
JNT
internals
like
create
like
your
hello
world,
for
the
browser
and
create
a
hello
world
for
note
and
we're
completely
missing
the
node
one
right
now
and
there's
like
basically
zero
documentation
on
it.
So
that
would
be
really
beneficial,
and
then
this
goes
into
the
bundler
stuff,
but
also
making
the
examples
less
vendor
specific.
B
A
Impact
site
that
has
like
the
installer
I
would
like
to
have
something
right
below
it.
That
says
like
these
are
the
things
that
you
can
do,
because
one
of
the
biggest
feedbacks
about
like
Gigwise
impact
announcement,
so
that
if
you'd
like
don't
know
what
wise
impact
does
like
you
probably
still
do,
and
so,
if
there's
an
opportunity
to
be
better
about
that
and
I
think
calls
to
action.
That
say
like
do
this
and
then
a
tutorial
that
follows
will
will
make
that.
B
A
B
I
was
interacting
with
them
a
little
bit
like
they
went
through
the
same
kind
of
cycle
that
the
web
web
pack
template
went
through,
or
the
web
pack
plugin
where
it
was
like
they're
trying
to
require
source
Lib
RS.
It's
like
that's,
not
the
greatest
like
if
you
have
to
require
a
file
and
not
just
like
a
directory
or
something
like.
Probably
the
best
thing
to
do
is
like
the
cargo
Tommy
I
guess
even
that
can
be
moved
and
not
exist
in
parvathamma,
but.
B
D
Taking
a
look
at
the
plug-in
itself,
we
Miller
to
help
out
with
her
as
well
and
since
the
it
looks
like
it's
generating
like
JavaScript
glue
and
like
kind
of
poly
filling
yes
stuff,
but
that
might
also
be
parcel
limitations,
as
opposed
to
cuz
like
like,
ideally
with
a
bundle
or
like
everything,
is
he
has
modules
and
works
out,
but
I.
Don't
think
that
personal
supports
modules
where
they
had
import
supports
over
they
had
exponents,
and
so
this
might
be
Paula
feeling
that
what
the
current
personalized
this.
Today's
that
looks.
A
D
A
A
I
was
talking
to
Jamie
when
I
think
it
may
have
been
cat.
Sigma
showed
up
in
the
Wesen
pack
issue
tracker
and
he
commented
on
the
issue
to
help,
try
and
clarify
what's
going
on,
but
I
think
I.
Think
one
of
this
like
if
I
recall
correctly,
the
parcel
was
an
implementation.
Doesn't
leverage
was
in
pack
or
wasn't
binding?
So
maybe
this
is
a
community
trying
to
work
around
that
so.
A
A
Issue
that
that
is
filed
on
wasn't
tech
suggest
that
it's
wrapping
its
using
wise
impact
in
the
background,
which
is
the
information
I'm
operating
on
I,
obviously
need
to
dig
a
little
deeper
and
figure
out
exactly
what's
happening
here
it.
It
may
be
something
and
I,
don't
know
how
we
feel
about
this
like
do.
We
think
it
would
be
worth
it
to
document
bundler
strategies,
so
it's
like
so
you
wanna,
like
leverage
our
tool
set
with
a
bundler.
D
B
So
again,
there
are
a
few
things
I
noticed
from
watching
that
stream,
but
ways
you
can
improve
the
tutorial
they're,
all
pretty
small
things
like
having
more
precise
wording
in
exercises
or
whatever
couple
typos
I,
don't
really
have
much
than
that.
I,
don't
think,
there's
been
there's
there's
one
person
who
was
actually
going
through
in
like
filed
an
issue
because
they're
having
trouble
with
one
of
the
exercises
like
in
the
middle
end
of
the
tutorial,
so
that
was
pretty
sweet
that,
like
this
person,
was
actually
going
through
the
whole
thing
and
doing
the
exercises.
B
B
D
Mostly
just
kind
of
wanted
to
bring
this
up
in
the
sense
that
there
are
a
lot
of
feature
features
coming
down
the
road
from
upstream,
like
webassembly
spec,
and
these
include
things
like
threads
and
Atomics.
They
also
include
things
like
Cindy,
and
this
is
stuff.
The
rest
is
very,
very,
very
well
poised
to
doing
so
or
to
actually
leveraging
and
kind
of
like
using
the
reproductive
fashion.
So
this
isn't
necessarily
related
to
kind
of
like
the
packaging.
D
It's
forward
like
the
functionality
story
and
I
just
kind
of
would
Eve
as
a
quick
update
where
the
Atomics
and
threads
we
had
a
really
good
chat
with
Luke
and
a
few
other
folks.
We
have
a
pretty
solid
idea
of
how
to
do
this,
and
so
I'll
be
working
on
putting
that
and
having
like
some
story,
for
why
is
impacted
by
some
by
engine
and
like
wise
and
pack
is
going
to
be
absolutely
crucial
to
this
and
this.
Instead,
it
will
be
like
this.
D
The
vision
is,
depending
on
an
MPI
package
in
a
very
transparent
way.
Well,
yeah.
We
don't
actually
know
that
it's
fitting
an
NPM
package
and
so
like
that's
where
tool
is
starting
to
really
shine
but
stuff
like
that
and
with
Cindy
Olivia
was
making
a
lot
of
good
progress,
but
I,
don't
I
was
realizing
last
night
that
no
VM
actually
supports
Cindy.
D
So
there's
no
way
to
run
any
one
code
that
has
Cindy
so
that
part's
kind
of
stone
up,
but
otherwise
I'm
personally
always
interested
in
kind
of
how
rest
will
be
supporting
future
fat
future
wasm
features.
And
so,
if
anyone
has
any
questions
about
things
like
the
freedom
reach
out
to
me,
I
suspect
not
here,
but
maybe
thinking
either.
D
D
E
E
D
D
B
Yeah
I
final
note
on
just
like
threads
was
in
the
meeting
that
Alex
referred
to
earlier.
We
kind
of
came
up
with
the
goal
of
like
something
like
Mandelbrot,
where
we
can
just
like
have
a
specific
thing
that,
like
we
can
do
working
threads
that
doesn't
require
using
imports
from
threads
and
like
we
don't
need
to
have
everything
working
the
way
we
envision
envision
it
working
like
long
term
but
like
getting
a
demo
out
there.
A
Have
one
thing
before
we
dive
into
that
sorry-
and
it's
just
this
so
I've
been
talking
to
tail
and
I-
think
it
would
be
very
useful
for
us
to
work
on
getting
some
type
of
analytics
for
our
toolset.
Both
around
adoption
and
usage
and
I've
been
talking
with
tail
about
kind
of
like
what
is
some
low-hanging
fruit,
particularly
native
modules,
in
node
and
stuff.
A
Crazy,
I/o
downloads
were
already
like
a
bad
measure
and
now
they're,
like
even
useful,
so
I
do
think
that
we
should
at
least
start
thinking
about
how
we
are
going
to
do
that
type
of
work.
In
addition
to
outreach,
also
just
because
I
don't
know,
I've
been
doing
a
lot
of
workshops
and
I
think
that
helps
but
I
want
to
make
it
a
more
integrated
part
of
our
team.
That,
like
it's,
something
that
everybody's
working
on.
B
A
B
A
Yeah
I
think
if
we
end
up
implementing
like
a
technical
solution
it
absolutely
you
should
be
an
RFC
and
I
think
potentially
long-term.
If
we
see
enough
usage,
we
will
want
a
technical
solution,
but
I
think
before
we
really
even
think
about
the
technical
solution
we
should
be
trying
to
like
do
what
we
can
now
like,
if
that's
from
like
count
the
number
of
blog
posts
that
happened
count.
The
like
I
think
that
those
numbers
are
important.
A
A
I
mean
even
just
from
like
my
conversations
with
Sandra
and
the
dev
rel
and
marketing
people.
They
are
very
excited
about
marketing
web
assembly
and
so
I
think,
there's
kind
of
like
a
lack
of
investment
on
the
technical
side
and
so
I
just
like
this
is
how
you
work
in
orgs.
Like
you
get
the
numbers
and
I
think
it's
it's
a
good
thing
to
do
so.
A
D
D
It's
the
domino
good
business
so
as
various
pros
and
cons
that
I'm
not
gonna
go
too
much.
That
was
just
great
just
yet
the
primary
alternative
is
using
DRF,
where
we
just
say
that
every
type
just
dear
s
to
the
parent
class.
This
is
like
the
rough
straight
d
rift,
and
so
that
is
also
a
modern
way
to
model
hierarchy
sort
of,
but
is
really
done
elsewhere
in
rust.
It's
just
a
way
to
do
it
here.
Some
of
the
more
recent
discussion
has
been
revolving
or
some
of
the
discussion
about
ver.
D
Today,
by
default,
we
will
mark
methods,
is
what
I'm
going
to
call
final.
It's
a
great
name
for
coming
out
of
this
question
and
by
final
I
mean
that
we
pick
a
function
out
of
the
prototype
like
we
literally
reach
inside
the
prototype
capital,
at
food,
prototype,
dot,
method,
name
and
then
whatever
we.
You
call
a
function
like
it
says
like
that
function,
object,
dot,
call
of
all
the
various
arguments,
and
so
by
doing
this
we
are
bypassing
all
trait
sorry
prototype
lookup
in
JavaScript.
D
By
saying
we
want
only
this
one
precise
function
do
not
do
prototype.
Lookup
do
not
do
anything
related
to
that
now,
there's
a
way
to
subvert
distance
in
resin
version,
where
you
can
say
that
a
method
is
being
bound
as
structural
and
structural
means
that
the
shim
that
is
generated
by
my
engine
actually
look.
D
You
very
much
do
because,
if
I
give
a
subclass
like
a
ampersand
vary
based
on
class
on
a
column
method,
destruction
of
the
final
version
would
call
always
call
the
very
very
small
subclass,
whereas
you
probably
want
like
the
superclass
cover
over
over
routed.
So
do
a
and
there's
some
discussion
about
whether
do
you
actually
want
to
switch
wise
imagined
to
structural
by
default,
where,
instead
of
final
by
default,
which
is
what
we
have
right
now
and
some
performance.
D
Some
very
naive
performance
gathering
seems
to
show
that
the
final
method
which
we
thought
was
going
to
be
faster
and
not
only
in
the
current
term,
but
also
in
the
long
term,
with
host
bindings
and
actually
currently
slower
or
roughly
the
same
speed
as
structural,
which
is
the
prototype
chain
lookup,
and
so
this
is
a
case
where
those
two
strategies-
it's
not
clear.
If,
if
we
switch
to
structure
by
default,
it
kind
of
changes,
the
calculus
of
whether,
like
the
pros
and
cons,
different
traits
and
whatnot.
A
D
And
so
this
goes
of
the
pros
and
cons
of
the
two
is
that
casket
over,
but
so
d
ref
is
very
simple.
It's
very
easy
to
implement
and
it's
kind
of
very
natural
to
understand
from
perspective
we're
not
introducing
obstructions
we're
not
trying
to
say
this
is
how
you
got
to
show
abstract
over
things
and
it's
so
it's
kind
of
a
it's
very
easy
to
grasp
for
new
people
or
as
treats
so
it's
like
I.
D
D
Can
go
more
into
the
cons
of
I,
mean
I'll
go
more
into
the
concentrates,
which
is,
but
so
you
it's
best
contrasted
with
that,
and
so
it's
like
right
now.
The
one
of
the
biggest
pros
is
that
it
does
handle
the
inherited
strictly.
If
everything
is
final,
but
some
of
the
cons
are
that
it
does
like
like
that.
I
have,
it
looks
pretty
rough,
and
so
this
is
a
little
bit
biased
towards,
like
I,
suppose
the
trade
side
so
traits
the
treats
are
inherently
just
very
complicated.
D
D
Where
are
you
saying
like
if
I'm
passing
it
all
these
subclasses
and
they're,
all
going
in
their
own,
their
own
monomorphic
version,
whereas
in
the
DRF
version
you
just
take
ampersand
base
class
and
as
long
as
it
structure
a
little
all
work
out,
how
one
person
it
it
works
and
it's
much
smaller
and
code
size
and
then
also
kind
of
like
I,
think
the
trade
object
like
it's.
It
really
is
just
the
complexity
of
traits
of
like
dealing
with
trade
objects
dealing
with
generics
and
now
everyone's
writing.
D
A
D
Is
interesting
in
the
sense
that,
like
this
is
I
I
see
this
as
like
a
detail
of
the
library
author,
as
opposed
to
details
of
consumers
where
DRF
means
that
consumers
just
don't
even
worry
about
it?
They
just
don't
even
know
that's
happening,
they
just
use
dot
methods
and
they
get
a
linear
dance
present
treats.
It
affects
everyone,
both
the
library,
authors
and
the
consumers,
so
the
consumers
have
to
say,
like
how
am
I
taking
the
treat
I
have
to
go
import
the
trick
everywhere.
Things
like
that
ya.
A
D
Have
taught
we've
considered
like
this
is
not
the
first
attempt
to
model
a
treat
in
a
class
inheritance
hierarchy
from
a
foreign
language
in
rust,
and
every
conclusion
previously
has
been.
Let's
not
use
dear--if
for
various
reasons,
and
so
favorite
drf
is
very
interesting
here,
but
that's
in
the
sense
that
it's
very
specific
to
JavaScript,
we're
like
on
the
Webster's
side
of
things
like
the
deer.
If
doesn't
work
when
you
have
like
I,
forget
exactly
all
the
other
precise
reasons,
but
all
its
largely
related
to
inheritance
and
over
writing
actual
methods,
whereas.
A
D
The
web
I
for
the
weighted
web
sis-
it
doesn't
matter
at
all
because
there's
like
we
did
some
analysis
and
there's
like
no
shadowing
new
anywhere,
so
there's
no
overwriting
at
all
or
effectively
none
and
then
for
the
NPM
at
large.
If
we
use
structural
everywhere,
then
it
also
solves
that,
and
it's
not
clear
why
you
would
not
use
structural
everywhere
because
there's
like
some
points
about
like
it's.
Actually,
it's
just
less
of
a
click
on
like
you.
Just
can't
get
it
wrong,
if
always
you
structural
and
for
the
web
siscri,
we
were
generating
it.
D
So
we
know
where
we
know
we're
right
and
it'd
be
very
easy
for
us
to
generate
final
annotations
there,
and
so
it's
actually
a
pretty
compelling
case
to
me
that
we
should
switch
to
structural
default
and
then
just
in
our
generated
code,
wherever
we
need
performance
in
the
hypothetical
feature
that
hosts
bindings
to
super
format.
That's
where
we
start
applying
final
and.
A
D
B
The
other
thing
I
want
to
mention
about
the
like
trade
based
thing.
Is
that,
like
no
matter
which
version
you
choose,
you
don't
really
get
a
good
result
like
you
can
either
use
generics,
and
then
you
get
a
code
blow-up
form
on
an
organization
right,
but
it's
not
actually
like
useful
code
blow
up
because
you're
not
getting
like
new
inlining
capabilities
or
whatever
right
and
then,
if
you're,
using
trait
objects,
you're
creating
an
indirection
but
like
that
interaction
is
unnecessary
because,
like
the
JavaScript
side
of
things
already
kind
of,
has
this
indirection
inherent
in
it.
B
D
In
terms
of
procedurally
I,
don't
really
know
the
best
way
to
proceed
on
the
server
see
in
terms
of
like,
like
that
is
a
radically
different
RC
saying
like
let's
rethink
everything
from
the
ground
up
and
say
everything,
structural,
beautiful
now,
hey,
look
giraffe
makes
a
lot
more
sense
because
it
has
the
major
downside
is
not
going
and
so
I
don't
know.
If
that
would
want
to
have
a
revision
to
the
Circe
or
like
try
and
post
it
on
the
server
see,
you
know,
I
think
that's
probably
a
new
RFC
well.
A
A
If
we
want
to
make
everything
structural
and
like
summarize,
that
put
that
out
there
and
then
say
like
would
one
of
us
want
to
write
that
RFC
like
the
new
one,
because
we
can
post
that
and
then
maybe
post
that
at
the
same
time
as
posting
a
separate
RFC,
don't
close
the
current
one
necessarily
right
away
and
then
like
just
kind
of
have
that
information
out
there
and
then
like
see
how
the
conversation
proceeds
but
like
I,
think
I.
Think
that
that
that's
how
I
would
proceed
that.
D
A
I
mean
this
kind
of
leaves
open
the
fact
that,
like
if
this
new
RFC
is
like
not
a
good
attempt
at
finding
like
a
intermediate
consensus
and
then
presenting
it
and
moving
forward,
all
the
conversation
will
just
happen
on
the
old
RFC
and
then
will
be
like.
Oh,
that
was
a
mistake
and
then,
like
triage
I
would
anticipate
that
things
will
move
over,
but
it
does
at
least
always
give
that
opportunity.
So
it
doesn't
seem
like
you
know.
B
E
B
D
A
A
D
A
A
B
Know
that,
like
we
were
getting
a
bunch
of
complaints
from
people
about
how
slow
like
rebuilding
was
and
getting
those
complaints
anymore
and
so
like
a
answer
to
that
is
like
everyone
stops
using
it.
But
I,
don't
think
that's
true
given
like
people
are
still
going
through
the
tutorial
and
stuff
right
and
they
used
to
go
through
the
tutorial
and
complain
about
rebuilding
and
now
they're
still
going
through
the
tutorial
as
far
as
I
can
tell,
but
they're
not
complaining
about
the
rebuilds.
So
that
sounds
like.
A
A
Know
one
thing
I've
been
thinking
about
doing
and
I
don't
know
if
it's
a
good
idea
goes
back
to
the
metrics
thing
is
because
we
write
a
package.json.
I
could
just
add
a
custom
key,
that's
called
like
flies
and
pack
or
something
and
then
crawl
the
NPM
registry,
and
find
out
how
much
stuff
ends
up
on
there.
It
would
mean
if
I
mean
someone
could
obviously
manually
remove
the
key
in
then
we
wouldn't
know
but
trying
to
get
a
sense
of
if
people
are
even
using
it.
Who
knows.
D
A
A
E
A
D
A
A
B
I
think
it
would
be
nice
if
browsers
shared
all
this
stuff,
like
chrome,
shares
all
of
its
whatever
data
like
usage
of
like
CSS
or
whatever,
and,
like
certainly
like,
we
have
access
to
the
Firefox
data
via
all
of
our
connections
right.
So
indeed,
we
have
I
think
we
have
ways
like
push
to
say:
hey
like
you
should
be:
releasing
this
information
for
everyone
to
see.
Yeah.