►
Description
Agenda ► https://rusty-days.org/agenda
Slides ►https://rusty-days.org/assets/slides/01-should-we-have-a-2021-edition.pdf
Playlist with all talks ► https://www.youtube.com/playlist?list=PLf3u8NhoEikhTC5radGrmmqdkOK-xMDoZ
Follow ►
Facebook: https://rusty-days.org/facebook
Twitch: https://rusty-days.org/twitch
Twitter: https://rusty-days.org/twitter
This video ►
In 2018, Rust adopted an "edition" system. This lets Rust evolve in ways that feel like breaking changes but are opt-in only, and that do not disturb the open-source ecosystem. Given that Rust 2018 happened three years after the initial 2015 release of Rust, this has everyone wondering: is 2021 the year we have our next edition?
In this talk, Steve lays out his own feelings on this question, as well as talks about the history of the edition system, how it works, and what it might look like in 2021.
A
All
right,
hey
everybody,
I'm
steve
thanks
for
thanks
for
coming
to
my
talk.
This
talk
is
titled.
Should
we
have
a
2021
edition
and
today
is
the
27th?
So
for
those
of
you
who
don't
know,
I
am
on
the
core
team
of
rust.
I
previously
led
the
documentation
team
and
I
wrote
the
rest
programming
language,
which
is
the
introductory
book
onrest
that
comes
with
rus
itself.
A
A
So
these
days,
I'm
like
writing,
embedded
rust
and
it's
awesome
and
we've
had
an
embedded
working
group
working
on
it
for
a
while,
and
I
appreciated
their
work
in
the
abstract
sense,
but
now
that
I'm
actually
doing
their
work
as
my
job,
it's
fantastic,
so
that's
pretty
cool
and
we
are
also
hiring.
So
if
you
are
interested
in
a
job
where
you
will
write
a
lot
of
rust,
you
may
want
to
check
that
out.
Finally,
I've
started
actually
working
on
open
source
rust
streaming
stuff.
So
I'm
doing
my
twitch
now.
A
So
if
you
want
to
watch
me
program
on
tuesdays,
that's
the
thing
I'm
doing.
Okay,
anyway
enough
about
me.
You
want
to
hear
about
additions
so
today
we're
going
to
kind
of
cover
these
like
three
major
points
in
this
order.
So
the
first
one
is
what
exactly
are
additions.
I
want
to
make
sure
that
we're
on
the
same
page
about
the
details,
because
the
details
do
actually
matter
and
matter
a
lot
here.
A
Secondly,
we've
already
done
sort
of
one
edition
release,
which
is
rest
2018,
and
so
I
kind
of
want
to
take
a
look
at
that
and
like
kind
of
how
it
went
and
some
like
thoughts,
you
know,
after
some
time
has
passed.
So
it's
kind
of
like
a
little
bit
of
a
case
study,
maybe
a
little
bit
of
retrospective.
A
You
know,
but
let's
like
talk
about
rest,
2018
and
then
finally
like
what
should
we
actually
do,
and
this
is
phrases
should
we
have
rus
2021,
that's
kind
of
like
a
big
thing.
People
have
been
talking
about
lately.
I
want
to
sort
of
emphasize,
especially
with
both
of
these
second
sections,
that
this
is
like
my
personal
opinion.
While
I
am
on
the
court
team,
I
am
only
one
person,
and
you
know
this
is
this
is
all
phrased
as
like?
Should
we
because
technically
nothing
has
been
decided?
A
So,
while
I
do
have
my
own
opinions
on
this
feel
free
to
disagree,
and
just
like
you
know
this
is
this.
Is
me
saying
this
so
take
that
as
far
as
that
goes
all
right,
so
first
up
this
first
section
what
even
are
additions
anyway,
if
you
don't
know
at
all,
thank
you
for
coming
my
talk,
even
though
you
don't
know
the
subject.
A
This
is
exactly
why
I
included
this
section,
but
even
if
you
do
there's
some
details
that
maybe
some
people
don't
always
think
about,
so
I
want
to
talk
about
a
lot
of
those
details.
There's
kind
of
two
aspects
to
additions
that
I
think
are
really
important
and
the
first
one
is
the
sort
of
social
aspect
of
rust.
A
Russ
2018
was
the
first
edition
sort
of
release
and
it
came
out
in
2018
and
we
sort
of
said
like
hey.
You
know,
rust
has
changed
a
lot
in
the
last
three
years.
You
know,
let's
talk
about
all
the
stuff,
we've
accomplished
and
add
in
some
other
things,
and
so
that's
like
largely
a
social
thing.
So
this
is
a
way
to
sort
of
reflect
on
the
longer
term,
progress
of
the
language
and
the
project
as
a
whole,
because
we
release
every
six
weeks.
A
That
is
like
a
really
great
thing
for
a
lot
of
reasons,
but
it's
really
hard
to
like
remember
how
much
work
we've
done
releases
come
out
all
the
time
and
they're
in
small
little
chunks,
and
so
it
can
be
really
really
easy
to
forget.
Like
just
how
far
along
things
came
half
the
time,
I
forget
that
it's
been
like
almost
five
years
since
rest
1.0,
because
when
things
are
happening
at
such
a
rapid
pace,
it's
really
easy
to.
You
know
lose
track
of
like
how
far
we've
come,
and
so
that's
like
really
important.
A
A
second
one
is
a
point
on
like
why
additions
matter.
Are
that
they're
a
way
to
get
new
users
into
rust?
So
this
sort
of
is
kind
of
similar
to
the
first
point,
but
a
little
bit
different.
Basically,
you
know
because
we
release
every
six
weeks,
there's
a
lot
of
people
who
don't
pay
attention
to
rest
releases
because
they
see
them
so
often
and
they
have
not
that
much
in
them
and
so
they're
kind
of
like
you
know,
hey
you
know
I,
the
new
rust
release
happens.
A
I
don't
care
with
languages
that
release
like
once
a
year
or
once
every
couple
of
years.
It's
a
really
big
deal,
and
so
a
lot
of
people
will
like
hear
about.
Like
you
know,
oh
there's
a
new
version
of
people's
plus
out
or
there's
a
new
version
of
ruby
out
or
the
new
c-sharp.
Has
these
cool
new
things
in
it
and
that's
a
way
for
people
who
don't
currently
program
in
the
language
just
sort
of
like
it
signals
to
them?
Hey.
You
know
I
should
check
this
out.
A
A
I
guess
basically,
like
you
know,
not
only
is
it
about
reflecting
on
what
we've
done,
but
also,
if
there's
sort
of
big
things
we
want
to
do
it's
nice
to
build
a
point
in
the
near
future
and
say,
like
you
know,
hey
it's
20
20.
Now
we
want
to
do
a
rust
2021
and
we
want
to
like
get
people
excited.
So,
let's
start
working
on
some
projects
that
will
like
really
generate
that
excitement
and
there's
some
like
back
and
forth
here
and
we're
going
to
talk
about
all
those
details
in
a
minute.
A
But
it
can
be
a
really
great
way
to
sort
of
get
everybody
excited
about
the
future
of
rust,
because
you
know
we
like
need
those
check-in
kind
of
points.
I
think,
but
also
additions
are
not
purely
a
social
mechanism,
they're
also
a
technical
mechanism,
and
this
this
really
matters
and
so
on
a
technical
level.
Additions
are
a
way
to
kind
of
make
breaking
changes
to
the
rust
language
without
actually
making
breaking
changes,
and
so
how
this
kind
of
works
on
a
technical
level
is
that
editions
are
opt-in.
A
So
you
say
what
edition
your
code
is
in
and
if
you
don't
update
that,
then
you
don't
update.
You
know
stuff.
So
if
new
things
are
added
in
a
way
that's
like
technically
breaking,
then
it
doesn't
break
you,
because
if
you
didn't
opt
in
to
the
new
changes,
then
your
code
still
works
forever.
So
this
is
like
very
different
than
you
know:
python,
2,
to
python
3,
for
example,
where
you
know
you
can't
run
your
code
kind
of
like
together,
and
you
know
similar
kind
of
things
like
that.
A
So
we
can
like
make
it
a
way
to
opt
into
breaking
changes,
and
that's
really
really
important
for
compatibility
reasons
and
then
finally,
additions
are
not
allowed
to
change
everything
about
rust.
This
is
a
technical
problem
as
much
as
it
is
a
social
problem
and
there's
custom
interplay
back
and
forth
between
the
two,
but
basically
like
major
major
changes
are
not
actually
allowed.
A
So
some
kinds
of
breaking
changes
are
fine,
but
there
are
some
kinds
of
changes
that
cannot
be
made
in
the
addition
mechanism
and
that's
due
to
the
technical
details
of
how
all
this
works.
It
does
also
kind
of
a
social
thing,
in
the
sense
that
it's
also
useful
for
humans,
like
if,
tomorrow
like
say,
rus
2021,
was
going
to
be
like
garbage,
collected
and
use
significant
white
space
instead
of
curly
braces.
A
So
let's
talk
a
little
bit
about
what
I
mean
by
breaking
changes
in
an
addition.
So
I
think
one
of
the
best
examples
of
a
breaking
change
was
the
async
keyword.
So
rust
has
you
know,
as
I
said,
two
editions
right
now:
2015
and
2018,
and
in
russ
2015
code
is,
you
know.
Async
is
not
a
keyword,
but
in
2018
it
is,
and
so
what
that
means
is.
If
you
look
at
this
code
that
I
have
here
on
the
left,
we
have
a
function
named
async
that
just
takes
an
integer
and
returns
it.
A
A
You
can
choose
this
little
drop
down
with
the
three
dots
and
then
pick
which
edition
you're
in
so.
If
you
choose
2015,
this
code
will
compile
and
it
runs
doesn't
do
anything
because
we
just
you
know,
pass
manager
around.
So
there's
no
output.
But
if
we
change
that
to
edition
2018,
we
will
get
an
error,
and
this
will
say
expected.
Identifier
found
keyword
async,
so
we're
allowed
to
name
a
function
async
in
rest
2015,
because
it's
not
a
keyword,
but
we're
not
allowed
to
name
it
in
async
in
rust,
2018,
because
it
is
a
keyword.
A
So
this
is
an
example
of
you
know.
If
we
purely
made
this
change
in
the
language
code
that
existed
and
ran
just
fine
before
would
end
up
breaking.
So
this
is
like
a
breaking
change,
but
because
you
can
choose
whether
or
not
to
upgrade
it's
like
not
a
breaking
change,
and
so
this
kind
of
like
duality.
A
So
you
get
to
choose
an
addition
mechanism,
an
addition
key
by
putting
2018
in
there,
and
if
this
does
not
exist
at
all,
then
it
defaults
to
2015..
So
all
the
code
that
was
generated
before
we
had
this
idea
of
additions,
it
is
able
to
you,
know,
stay
on
the
sort
of
the
default
2015
edition.
But
if
you
opt
in
then
you're
able
to
do
this
and
cargo
new
will
start
generating.
A
You
know
2018,
so
I
just
type
cargo
new
to
generate
this
and
it
defaults
me
to
the
latest,
and
so
that
way
you
know
we're
able
to
like
new
projects
start
in
the
latest
edition.
But
older
projects
stay
on
the
edition
they
were
created
with
until
their
creators
explicitly
opt-in.
So
that's
kind
of
like
the
way
that
this
happens
in
most
real
projects,
and
one
thing
that's
really
important,
though
about
editions
is
that
additions
can
interoperate
just
fine.
A
So
let's
say
that
I
had
packaged
up
my
useless
async
function
into
a
crate,
and
I
wanted
to
use
it
from
some
code
that
was
in
rust,
2018.
Well.
One
of
the
features
that
was
added
in
russ
2018
was
the
ability
to
use
a
raw
keyword.
So
I
showed
you
the
error
message
in
the
2018
code
before
but
right
below.
The
error
is
a
little
help.
Message
that
says:
hey.
A
You
can
escape
keywords
to
use
them
as
identifiers,
and
so
here,
with
this
r
pound
sign
both
at
the
call
site
and,
at
the
actual
you
know,
declaration
site,
you're
able
to
still
define
and
call
a
function
named
async,
even
though
it's
a
keyword.
So
this
would
matter.
If
you
could
imagine
that
the
you
know,
async
function
lived
in
a
2015
crate,
then
I
would
still
be
able
to
call
it
from
a
2018
crate,
and
you
know
vice
versa.
If
there
was
some
other
way
of
doing
it.
A
So
this
is
one
example
of
the
ways
that
code
can
interoperate,
but
just
in
general,
like
kind
of
the
idea
is
that
you
don't
have
to
be
worried
about
your
dependencies
at
all.
Other
code
is
allowed
to
be
in
any
edition
and
they'll
compile
into
your
project.
Just
fine
and
there's
no
like
worrying
about
this
kind
of
interoperability,
compact
compatibility
other
than
if
you
know
some
keywords
are
named
a
certain
way.
A
So
that's
a
really
like
helpful
way
to
make
sure
that
all
this
operates
smoothly,
and
so
specifically,
I
had
mentioned
before
part
of
the
way
that
this
works
is
that
additions
are
not
allowed
to
change
everything.
So
these
are
the
rules
that
were
set
out
in
the
original
rfc
and
they're
not
complete.
So
this
is
not
necessarily
like
a
full
list
of
everything
that
can
and
can't
change,
but
I
wanted
to
like
point
out
some
some
specifics.
So
an
example
of
a
thing
that
can
change
as
I've
already
showed.
A
You
is
new
keywords,
so
we're
allowed
to
define
new
keywords
and
new
editions,
and
you
know
that's
totally
fine.
It's
like
I
said
they
interrupt
across
the
boundary,
no
problems.
The
second
thing
that
additions
are
allowed
to
change.
It's
allowed
to
repurpose
existing
syntax,
and
I
say
repurpose
because,
like
you,
can
remove
existing
syntax,
it's
like
how
it
gets
repurposed
but
like
it
generally
shouldn't
only
remove
it
should
like
replace
with
something
that
does
something
slightly
different.
A
So
an
example
of
this
is,
if
you
have
a
the
usage
of
a
trait
in
this
case,
I'm
just
calling
it
trait.
But
you
know
if
you're
using
this
as
a
trade
object,
you
would
just
use
the
name
of
the
trait
originally.
So
you
have
like
box
trait
or
arc
trait.
Something
like
that,
and
so
what
we
did
in
the
2018
edition
was
we
sort
of
deprecated
that
usage
of
just
trait
on
its
own,
and
we
introduced
dyn
trait.
Unfortunately,
my
slides
kind
of
split
this
on
the
two
lines.
A
Normally,
it
would
be
just
one
line,
but
like
this
helped,
you
know
that
hey.
This
is
a
trade
object
because
we're
doing
dynamic
dispatch,
and
so
we
kind
of
like
replace
that
existing
syntax
for
doing
a
thing
with
a
new
syntax
instead
and
so
you're
able
to
you,
know,
use
this
new
syntax
and
it's
like
more
clear
to
people
that
dynamic
dispatch
is
what's
happening,
so
we're
allowed
to
kind
of
like
change
some
existing
stuff
and
add
some
new
things
and
like
tweak
things.
A
Another
example
of
something
that
changed
in
the
2018
edition
was
the
module
system,
which
is
a
pretty
big
change.
I'll
talk
about
all
the
changes
we
made
a
little
bit
later,
but
there's
also
some
things
that
we
can't
do
earlier.
I
mentioned
that
we
couldn't
make
really
big
sweeping
changes,
but
like
there's
actually
slightly
more
specific
things,
some
of
them
are
based
on
practical
limitations,
and
some
of
them
are
based
on
decisions
that
we've
made
so,
for
example,
the
coherence
rules
can't
change
across
conditions.
If
you're
not
familiar
a
coherence.
A
A
Is
that
if
I
had
say
a
type,
that's
defined
in
the
standard
library
like
string
and
I
have
a
type
that's
defined
in
a
third
party
package-
it's
not
mine,
say
maybe
like
surday,
I
can't
define
surday
serialize
for
a
string,
because
it's
not
my
trait,
it's
not
my
type,
so
that
doesn't
work.
If
I
had
made
my
own
string
type,
then
I
would
be
allowed
to
implement
sir
day's
trait
for
it
and
if
I
implemented
my
own
trait
I'd
be
allowed
to
implement
it
on
the
standard
library
string.
A
But
I
have
to
own
either
one
of
the
traits
or
the
types.
The
rules
are
a
little
more
complicated
than
that.
But,
like
that's
the
gist
of
it,
that's
the
the
biggest
thing.
So
that's
not
allowed
to
change.
We
couldn't
say,
relax
them
in
one
edition,
but
not
in
the
other,
and
that's
because
coherence
rules
are
kind
of
global
and
those
rules
happen
across
different
crates.
A
Secondly,
another
thing
that
people
sort
of
don't
always
appreciate
is
that
we
can't
make
breaking
changes
to
the
standard
library
and
intuitively
you're
like
wait.
If
I
can
change
crates
standard
libraries
just
to
create
like
why
not
well
I
mean
it
is
just
great,
but
it's
also
kind
of
not
just
great.
A
You
get
one
copy
of
the
standard
library
for
your
whole
program,
and
so,
if
you
had
a
dependency
that
used
rus
2018
and
then
you
use
rest
2015
say
then
you
would
need
both
copies.
So
it
doesn't
like
really
work
that
way,
exactly
so
we're
able
to
sort
of
deprecate
things,
but
we're
not
able
to
remove
them
and
there's
some
talk
of
maybe
having
some
sort
of
visibility
situation
where
like
they
exist,
but
there's
visibility,
rules
where
this
is
like
only
allowed
to
be
seen
in
2018
versus
2015..
A
Those
are
proposals
and
they're,
not
like
real
yet
so
you
know,
this
is
like
kind
of
half
a
true
technical
invitation
and
half
a
sort
of
social
limitation.
Somebody
asked
a
question
on
twitch.
How
does
a
deprecated
feature
move
from
deprecated
to
like
removed
and
can
that
be
done
between
editions?
So
one
interesting
thing
about
this
is
that
some
of
this
stuff
is
kind
of
up
in
the
air.
A
Policy-Wise-Ish,
basically,
like
things,
cannot
actually
error
on
the
same
edition.
So
like
usually
the
way
you
think
about
it
is
something
becomes
a
warning
in
the
old
edition
and
then
an
error
in
the
new
edition
and
the
original
rfc
talks
a
little
bit
about
code.
That's
warning
free
on
the
first
edition
should
compile.
Maybe
you'll
have
new
warnings,
but
it
won't
break
on
the
second
edition
but
like
if
there's
warnings
in
your
first
edition
code.
A
Maybe
the
second
edition
would
break
I'm
going
to
talk
a
little
bit
more
about
this
at
the
end,
because
the
exact
policy
is
like
a
thing
that
we're
talking
about
so
yeah
the
the
rules
are
slightly
up
in
the
air,
but
originally
that's
what
the
intention
was.
Was
that,
like
you,
introduce
warnings
in
the
first
edition,
you
remove
them
in
the
second
edition.
There's
some
questions
about
whether
or
not
that's
like
too
fast,
or
you
know.
A
Maybe
we
should
like
require
a
whole
edition
to
go
by
like
we
require
language
features,
to
wait
for
a
whole
release
in
nightly
before
we're
able
to
stabilize
them,
for
example,
there's
kind
of
a
minotaur
mandatory
minimum
waiting
period.
So
maybe
there
would
be
a
good
mandatory
waiting
period
for
deprecations
but
yeah.
So
I
hope
that
answers
enough
of
your
question.
Hey
jared,
but
I'll
talk
about
a
little
more
okay.
So
why
do
we
have
these
restrictions
like
on
some
level
like?
A
I
talked
a
little
bit
about
some
of
them
with
like
there's
one
crate
everywhere,
but
let's
get
into
some
details-
and
I
think
this
matters,
because
this
also
really
helps
you
understand
like
why
certain
things
are
allowed
and
why
certain
things
aren't
allowed
and
it's
also
just
kind
of
fun
to
talk
about
the
compiler
and
how
it
works.
So
this
next
section
is
going
to
be
about
editions.
I
swear,
but
it's
also
kind
of
how
the
compiler
works,
because
I
think
that's
interesting
and
kind
of
matters,
so
rust
is
currently
sorta.
A
Kinda
there's
an
asterisk
here,
I'm
gonna
get
to
it
later,
what's
called
a
multi-pass
compiler,
and
so
this
is
like
a
classic
architecture
for
compilers.
If
you
take
a
compiler
class
in
your
university,
this
is
how
they
teach
you
compilers
work.
A
lot
of
compilers
in
the
world
are
implemented
this
way.
Basically,
what
happens
is
there
are
this
concept
of
passes?
So
you
can
you
take
in
a
source
code
and
then
you
spit
out
something.
A
A
lot
of
older
compilers
are
called
one
pass
compilers
because
they
directly
turn
the
code
into
the
actual
like
binary
code.
So
if
you
think
about
like
you
used
to
have
to
be
a
lot
of
older
languages
required
you
to
define
a
variable
at
the
start
of
functions,
for
example,
that
was
because
they
had
one
past
compilers,
and
so
they
needed
to
emit
the
stack
space
for
those
variables.
You
know.
A
First,
okay,
it
seems
to
be
back
cool.
I
don't
know
why
that's
happening,
there's,
probably
something
on
my
end,
but
anyway,
so
yeah,
so
older
compilers
are
one
pass.
That's
also
why
a
lot
of
them
were
super
fast
because
they
didn't
do
a
lot
of
this
stuff,
but
over
time
you
know
we
needed
things
to
to
be
more
complicated,
and
so
then
people
developed
multi-pass
compilers,
where
you
would
do
multiple
steps,
so
you'd
iterate
over
the
source
code
in
multiple
ways
and
that's
how
it's
produced
so
in
the
rust
compiler.
A
So
there's
a
bunch
of
these
steps
and
within
these
steps,
there's
kind
of
smaller
steps
and
all
this
sort
of
like
happens
we're
going
to
talk
about
this
in
a
little
more
detail,
so
compilers
traditionally
are
kind
of
produced
in
this
three
different
phases.
That's
why
you
have
these
passes?
You
do
the
full
pass
and
the
full
pass
and
full
pass
all
three
steps.
First,
one
is
like
a
lexical
or
syntactic
analysis.
So
is
your
code
well
formed?
This
is
like
grammar
rules,
so
you
know,
does
the
sentence
I'm
saying
follow
proper
grammar
or
not?
A
Does
your
program
follow
the
languages?
Grammar
or
not?
Secondly,
is
semantic
analysis
which
does
this
code
make
sense?
So,
for
example,
you
know
I
could
I
could
say
like
you
know,
this
sentence
is
false
and
that
sentence
is
grammatically
correct,
so
it
passes
lexical
or
syntactic
analysis,
but
semantically,
it's
very
unclear
what
it
means,
because
if
it's
true,
then
it's
saying
it's
false,
which
means
it's
false,
which
means
it's
not
true.
A
So
there's
some
reflexivity
there,
it's
just
the
first
example
I
could
come
up
with,
but,
like
you
know,
you
could
imagine
gibberish,
for
example,
that
uses
all
real
words.
Maybe
it's
structurally
correct,
but
it
doesn't
actually
make
any
sense.
So
semantic
analysis
makes
sure
that
the
thing
that
you've
said
is
sensical
and
finally
code
generation.
This
does
not
really
have
a
an
analog
in
existing
languages.
I
guess
this
is
the
the
vocal
cords
turning
it
into
sound.
Maybe
would
be
the
analogy.
A
I'm
stretching
this
a
little
too
far,
but
once
we
verify
that
everything
works
and
makes
sense,
we
actually
produce
the
binary.
Finally,
out
of
it,
this
step
in
itself
has
a
bunch
of
different
passes.
For
example,
we
talk
about
optimization,
passes
and
sort
of
run
and
generate
code.
You
know
faster
so
that
all
happens
in
this
kind
of
stage,
but
you
know
these
are
kind
of
the
three
big
giant
steps
if
you've
ever
wondered
how
cargo
check
works.
A
For
example,
cargo
check
will
run
the
lexical
and
syntactic
analysis
and
the
semantic
analysis,
but
won't
generate
any
code.
So
this
is
an
example
of
how
understanding
this
can
help
you
practically
as
a
rust
developer.
Use
cargo
check
to
check
your
code
makes
sense,
but
you
don't
actually
want
to
run
it.
You
can
save
yourself
a
lot
of
time
by
not
making
the
compiler
do
code
generation.
A
So,
for
example,
mir
is
lowered
into
lvmir
or
the
ast
is
lowered
into
here,
and
the
reason
it's
called
lowering
is
that
at
every
step
along
the
way
things
get
simpler
and
we
throw
away
things
that
we've
already
validated,
which
makes
future
steps
easier.
So,
for
example,
mir
does
not
have
the
concept
of
complicated
fancy
loops
so
like
for
loops,
for
example,
don't
exist
in
mirror.
What
happens?
A
A
lot
of
semantic
analyses
are
kind
of
passes,
and
sometimes
they
will
do
transformations.
This
is
like
whenever,
basically
like,
okay,
you
know
I'm
going
to
take
your
for
loop
and
I'm
going
to
rewrite
it
as
a
while
loop
that
happens
first
as
a
pass,
because
inside
of
here
I
believe,
and
then
the
lowering
step
is
what
turns
that
simpler
form
of
here
into
mirror,
so
they
kind
of
like
work
together.
A
Okay,
so
this
is
some
example
of
actual
code
going
through
these
steps-
and
I
I
did
this
about
a
year
ago,
so
the
samples
are
a
little
dated
because
of
the
fact
that
the
compiler
output
changes
all
the
time,
but
conceptually
it's
the
same,
so
I
figured
it
being
outdated,
is
actually
a
little
better
because
you
shouldn't
get
hung
up
on
the
specifics.
So,
for
example,
let's
talk
about
taking
code
and
producing
an
ast.
If
we
have
this
function
called
plus
one
takes
i32
adds
one
to
it
returns
it.
A
We
could
actually
ask
the
compiler
to
print
out
the
json
version
of
the
ast,
because
again
these
are
all
data
structures
inside
the
compiler,
so
they
don't
really
have
a
text
representation,
but
you
can
like
print
them
out
in
things
like
json.
So,
for
example,
plus
one
a
little
bit
of
it,
looks
like
this,
so
there's
a
statements
and
that's
an
array
of
nodes
and
inside
of
there
each
node
has
a
variance.
So
this
is
like
an
expression,
and
then
you
know
it's
like
a
binary
expression.
A
That's
add
you
can
kind
of
see
how
these
little
bits
all
fit
together
and
then
you
know
we're
adding
x
and
it
keeps
going
on
to
talk
about
adding
one
and
stuff.
So
you
kind
of
get
this.
This
data
structure
view
of
your
code
and
that's
what
ast
looks
like
so
here
you
know
we
take
our
statements
and
the
statements
refers
to
an
expression.
Expression
refers
to
a
binary
expression.
The
binary
expression
says:
hey,
we
have
an
add
expression
that
adds
x
and
one
together.
A
So
this
is
kind
of
like
why
it's
called
a
tree
is
because,
if
you
see
there's
like
this
root,
which
is
the
statements
and
then
there's
the
branches
and
leaves
that
happen
to
build
a
tree,
so
this
is
like
what
an
ast
kind
of
looks
like
visually
and
so
yeah.
Fundamentally,
the
ast
is
a
data
structure
and
it's
the
way
that
our
code
looks
written
in
words,
but
is
a
data
structure.
This
means
it's
easier
to
manipulate.
A
Like
you
know,
if
you
just
have
a
data
structure,
you
can
just
manipulate
it
like
that's
what
they're
there
for,
but
if
you
had
to
do
it
on
the
like
textual
representation
of
your
code,
it'd
be
much
harder.
So
the
idea
is
that
we
break
the
text
down
into
a
data
structure,
and
then
we
do
all
our
operations
on
those
data
structures.
A
So
from
the
ast
we
move
on
to
the
here,
and
so
here
is
short
for
a
high
level,
intermediate
representation,
and
this
basically
is
like
doing
form
this
sort
of
checks.
What
I
mean
by
formness
is,
like
you
know,
have
you
imported
all
the
stuff
that
you've
used
things
like
that
and
some
things
are
simplified,
so,
for
example,
in
my
understanding
here
does
not
have
you
know
like
use
statements,
they
get
turned
into
the
elaborated
like
full
versions
of
all
the
types.
A
So
an
example
of
what
you
know
kind
of
like
the
sort
of
transformations
that
happens
here.
This
is
a
very
simple
for
loop,
there's
a
reason
I
referenced
for
loop
several
times
earlier
today,
where
we
take
a
vector
of
five
integers
and
we
loop
over
it,
printing
them
all
out.
So
the
ast
would
take
that
literal
code
as
written
and
represent
it
that
way,
but
when
it
gets
lowered
into
here,
it
ends
up
being
something
more
like
this.
A
So
this
is
like
still
rust
code
that
you
could
write
in
theory,
but
you'll
notice.
The
for
loop
is
totally
gone.
We
now
have
a
loop
with
a
match
statement
inside
and
where
we
turn
the
thing
that
we're
iterating
over
into
an
iterator,
and
we,
you
know,
call
next
on
it
repeatedly
until
the
body
of
the
loop
happens
and
all
these
things.
A
So
you
can
see
how
it's
kind
of
like
simpler
in
the
sense
that
there
are
less
language
constructs,
but
it's
more
complicated
in
the
sense
that
there's
more
code
because,
like
that's
the
reason
we
write
in
the
higher
level
stuff
in
the
first
place,
is
because
it's
easier
to
understand
for
humans,
but
the
computer,
you
know,
having
less
things,
makes
the
analyses
much
simpler.
So
we
do
that
kind
of
stuff.
A
Most
checks
in
the
compiler
today
are
done
on
here,
at
least
in
my
understanding.
So
here
was
the
original
rust
ir
that
existed.
So
the
the
first
version
of
the
compiler
or
maybe
first
is
a
little
strong
but
like
for
a
very
long
time.
The
compiler
turned
everything
into
here
and
then
it
went
to
lvm
ir
from
there.
So
you
know
it's
kind
of
like
the
og
thing,
so
a
lot
of
things
are
written
in
terms
of
here.
A
So
two
things
that
are
still
written
in
type
check
or
in
here
are
type
check
which
is
like
do
all
the
types
make
sense
and
have
you
not
made
any
type
errors
and
then
finally
method
lookup?
So
that's
done
at
compile
time
instead
of
in
some
dynamic
languages
methods.
Lookup
is
like
a
dynamic
process,
but
basically
you
know
kind
of
look
at
like
you
know.
What?
A
A
Mir
is
ultimately
about
control
flow,
so
here
is
kind
of
represented
our
code
in
the
way
that
we
wrote
it,
but
mir
totally
rewrites
it
to
be
in
a
simpler
form,
but
also
one.
That's
based
on
a
control
flow
graph
is
the
term
rather
than
an
ast,
which
is
the
tree.
So
going
from
a
tree
to
a
graph,
is
you
know
helpful
for
certain
kinds
of
analyses
specifically
like
the
graph
represents
the
way
that
the
control
goes
through.
A
Your
programs,
like
which
statement
executes
in
which
order
and
that
matters
because,
for
example,
non-lexical
lifetimes,
it
needs
to
know
how
the
execution
flows
within
your
program
to
work,
and
so
it
was
very
difficult
to
write
that
pass
on
here.
So
like
this
is
a
practical
example
of
why
this
stuff
matters
is
that
we
had
to
invent
mir
to
make
non-lexical
lifetimes
feasible,
because
we
needed
to
be
able
to
encode
that
flow
control
to
be
able
to
make.
A
A
Man,
I
don't
know,
what's
up
with
my
audio
dropping
anyway,
so
another
interesting
thing
about
mirror
beyond
the
control
flow
move
is
that
it's
kind
of
the
core
of
rust,
so
it's
kind
of
like
everything,
that's
rusty
about
rust
without
any
superfluous
extra
concepts.
So,
like
I
said
earlier,
fancy
loops
are
gone.
Everything
is
purely
loops
and
breaks.
A
It's
not
actually
rust
code,
but
it
kind
of
looks
like
it
again
we're
printing
a
data
structure
that
doesn't
have
a
real
text
representation.
So
here
you
can
see
our
add
one
function.
It
declares
two
variables
zero
and
two
or
one
is
the
first
parameter
and
in
a
bb
0
stands
for
basic
block
so
to
pay
attention
to
control
flow.
We
have
this
idea
of
blocks,
and
so
it'll
say:
hey
storage
live
means
that
the
second
variable
is
live
in
this
area,
which
is
an
analysis,
happens.
A
It's
about
control
flow,
it's
too
complicated
for
me
to
get
into,
and
I'm
too
far
in
the
weeds.
Already
here
you
could
read
the
document
compiler.
If
you
want
to
see
all
what's
happening,
you
can
see.
Our
call
to
add
you
know,
adds
a
constant
one
and
our
number
two
and
then
declares
the
storage
is
dead
and
then
returns.
This
is
kind
of
what
mir
looks
like
again,
not
anything
you
ever
have
to
worry
about
as
a
rust
programmer.
A
Lvm
is
a
compiler
toolkit
that
you
can
use
to
kind
of
like
build
stuff.
It's
a
vm
in
like
the
technical
sense
of
vm,
but
not
in
the
way
that
everyone
uses
the
word
vm,
so
it
used
to
stand
for
low
level
virtual
machine,
but
the
lvm
project
changed
its
name
so
that
it
no
longer
references
virtual
machines
because
that
got
too
confusing
to
many
people.
So
basically,
what
we
do
is
optimizations
and
code
generation
are
done
by
llvm.
A
For
the
most
part,
there
are
a
couple
optimizations
that
happen
in
mir
and
we
hope
to
do
more
of
them
in
the
future,
but
rust
would
not
be
anywhere
where
it
is
today
without
all
vm.
So
it's
very
important
to
us-
and
it
kind
of
like
is
the
lowest
level
of
the
compiler
sort
of
operates.
You
know
lvm
takes
the
compiler's
output
and
produces
the
binary,
so
we
kind
of
like
hand
it
off
to
that
library
as
the
last
couple
steps
andrew
levrett.
A
Sorry,
if
I
mispronounced
your
name
is
asking:
what
is
the
timeline
if
there's
one
to
get
cindy
support
unstable,
so
cmd
is
actually
already
unstable
for
rust,
but
only
the
x86
versions.
So
it's
also
the
low
level
unsafe
primitives.
So
I
think
maybe
you
either
one
don't
know,
that's
true,
which
is
totally
fine,
but
that
does
exist
today
or
two
you're
talking
about
higher
level
cmd,
which
is
like
what
you
would
want
to
write
as
a
regular
programmer
instead
of
the
intrinsics.
A
I
don't
actually
know
that.
There's
a
group
working
on
the
higher
level
stuff
right
now
the
low
liver
stuff
does
work,
though,
on
x86
at
least
and
given
arm's
recent
interest
in
rust.
I'm
assuming
that
arm
assembly
stuff
will
be
soon
to
follow.
I
think
maybe
some
of
it
already
works,
but
I'm
not
actually
100
sure
so
yeah
still
more
work
to
do.
There
don't
know
the
exact
timeline
yet
a
question
by
jam1
garner
what
would
go?
To's
be
used
for
in
mir
just
more
complicated
breaks.
A
Basically,
like
you
know,
structured
programming
is
useful
as
the
programmer
like
we
write
loops,
because
we
don't
want
to
have
to
think
in
go-to's,
but
go
to's
are
conceptually
simpler
because
they,
you
know,
are
allowed
to
do
whatever,
and
so
it's
actually
easier
for
the
compiler
to
understand
than
the
higher
level
constructs.
So
I
actually
like.
I
think
I
want
to
emphasize,
like
I
don't
work
on
the
compiler
myself,
so
I
believe
that
go
to's
exist,
but
I
don't
actually
100
remember
so
I
might
be
a
little
wrong
there.
A
So
you
should
you
know
if
you
care
about
this
topic.
You
should
look
at
the
details
a
little
more,
but
I
believe
that
that's
the
case,
but
I'm
not
sure.
Finally,
there's
a
question
about
working
with
rust
and
fuchsia.
I
will
talk
about
that
towards
the
end,
because
it's
not
relevant
to
this
part
of
the
conversation
so
I'll
get
back
to
you.
Spacex
jedi.
Don't
worry
about
it.
Thank
you
for
the
question.
A
Okay,
if
you're
curious
about
what
lvmr
looks
like
this
is
an
example
of
the
text
version
of
llvmir,
so
you
can
see
that
the
the
function's
name
is
mangled.
So
it's
add
one,
but
with
a
bunch
of
other
shenanigans
on
top
of
it-
and
you
know
we
add
a
number
to
that
and
return
it.
It's
very
straightforward,
there's
a
whole
bunch
of
attributes
and
other
stuff.
So
this
is
kind
of
like
what
we
hand
off
to
lvm.
A
It
does
optimization
passes
there
shouldn't
be
a
lot
of
optimizing
to
do
in
this
code,
other
than
maybe
inlining
it
into
other
code
we've
written
somewhere
else.
So
you
know
all
that
kind
of
thing.
Okay.
The
last
thing
I
need
to
mention
on
the
compiler
architecture.
Before
we
go
back
to
how
this
manages
how
this
works
with
additions,
I
hope
you'll
forgive
my
little
compiler
tutorial
here
is
that
I
said
before
we
were
a
multi-pass
compiler
and
that's
true,
but
we're
also
like
working
on
making
rust
query
based.
A
So
a
lot
of
the
compiler
is
already
query
based
and
what
that
means
is
instead
of
these
kind
of
passes,
where
you
take
the
whole
source
code,
you
turn
it
into
one
ast.
You
take
the
whole
ast
and
turn
it
into
here.
Vice
versa,
like
you're
continuing
you
know
down
that
strategy
rust
instead
uses
this
concept
called
query
to
create
an
executable.
So
what
happens
instead
is
the
rest.
Compiler
will
say
something
like
hey:
what
type
is
this
function?
A
Oh,
we
don't
have
this
function
yet,
but
you
know,
let's
load
up
the
source
code
of
what,
where
we
you
know,
I
think
it
is
and
then
we'll
look
at
the
body
and
do
all
that
work
and
then
sort
of
figure
out
that
way
and
so
it'll
sort
of
do
all
the
steps,
but
in
smaller
chunks
instead,
and
the
reason
this
is
useful
is
first
of
all
memoization.
So
you're
able
to
you
know,
reuse
results
of
these
queries
across
different
indications
of
things,
and
so
that's
helpful.
A
It's
for
compiler
speed,
but
also,
more
importantly,
it
fits
information.
Increment
incremental
compilation
couldn't
say
that
incremental
compilation,
it
fits
it
much
better,
and
so
you
know
if
we're
able
to
just
say,
like
oh
the
body
of
this
one
function
chained
that
would
map
directly
to
one
compiler.
Query
of
saying
get
me
the
body
of
this
function,
and
so
then
you
would
only
do
that
part
of
the
work
instead
of
saying
like
okay,
you
change
the
body
of
this
function.
A
Now
we
have
to
redo
the
whole
ast
and
the
whole
higher
level
ir
and
the
whole
mid-level
ir,
and
so
this
is
kind
of
the
way
that
sort
of
production
grade
compilers
are
written
today,
rather
than
the
way
that
they're
taught
in
school.
This
was
started
by
c
sharp
with
their
roslin
compiler.
So
if
you're
more
interested
in
kind
of
how
this
works,
you
should
look
into
roslin
or
rusty
as
we
continue
to
make
it
happen.
This
way,
all
the
mere
stuff
is
written
like
this.
A
In
my
understanding,
some
of
the
older
code
is
not
yet
converted,
but
this
would
kind
of
be
how
this
stuff
sort
of
works.
Also,
if
you've
been
following
rust,
analyzer
lately,
it
kind
of
has
this
sort
of
model
of
like
highly
incremental
and
like
not
traditional
architecture
that
compilers
have.
So
that's
all
how
that
goes.
A
Okay,
so
editions
aren't
allowed
to
break
everything
but
like
how
does
that
mean
like?
What's
that
mean
so
for
compilers,
basically,
like
additions
aren't
allowed
to
differ
by
the
time
you
get
to
mirror,
and
so
you
know
what
that
means
is
a
little
fuzzy
from
the
outside.
Basically,
what
it
means
is
the
core
of
rust
mirror
stays
the
same,
no
matter
what
and
that
really
matters
for
a
number
of
different
reasons.
A
It
also
means
because
we
are
compiling
down
at
the
same
thing.
We
have
this
interoperability,
we
don't
split
the
ecosystem
and
that
really
matters
hey
jared.
Has
another
question:
would
adding
more
query
based
compiler
features
to
resc,
make
rust
analyzer
and
other
sort
of
analyses
tools
more
robust,
yeah?
Basically,
that's
exactly
like
the
reason
that
c-sharp
underwent
the
roslyn
project
is
ides.
Have
very
different
needs
for
languages
than
the
traditional
compilers
do,
and
so
they
kind
of
like
reoriented
it
around.
What
happens
in
an
ide?
A
That's
exactly
why
I
phrased
it
as
kind
of
like.
Oh,
I
changed
the
body
of
this
function.
Let's
not
recompile
the
entire
world,
because
that's
what
happens
when
you're?
Actually
in
your
editor
programming,
as
you
change
little
bits,
most
of
the
programs
program
stays
the
same.
So
we
kind
of
want
to
reuse
that
work
rather
than
changing.
You
know,
throwing
it
all
away
every
single
time
and
so
yeah.
A
It's
definitely
one
of
the
reasons
why
those
tools
are
better
is
because
they
want
this
kind
of
architecture,
so
yeah,
okay
and
then
another
thing
about
like
what
is
additions
towards
the
end.
You
kind
of
think
of
additions,
as
sort
of
like
a
bigger
release
cycle,
so
rust
already
has
three
different
release:
cycles:
there's
stable,
beta
and
nightly,
and
there's
different
cadences
to
those
releases
so
nightly
is
every
night
stable
and
beta
happen
every
six.
A
Okay,
so
you
know,
edition's
kind
of
like
are
like
a
bigger
release
cycle.
That
happens.
You
know
broader
than
versions,
but
we
don't
have
a
cadence
for
editions.
Yet
this
is
kind
of
why
this
talk
exists
and
we're
working
on
an
rfc
that
I'll
get
to
here
at
the
end,
but
basically
like
we
didn't
actually
decide
whether
or
not
this
would
happen
on
a
schedule
or
not
when
we
decided
to
do
it
in
2018.
A
So
there's
no
policy
in
the
initial
rfc
about
when
edition
should
be
used.
As
I
sort
of
just
mentioned
it
didn't
talk
about
when
it
just
mostly
was
talked
about
how
and
that
way
we
could
focus
on
shipping
rest
2018
and
not
worry
about
it
until
later,
because
you
know
there's
a
lot
of
stuff
going
on
and
we
want
to
set
that
policy
immediately.
We
wanted
some
experience
with
additions.
We
wanted
to
get
2018
going
and
we
didn't
want
to
think
about
it.
A
A
So
let's
talk
a
little
bit
about
russ,
2018
and
kind
of
how
it
went.
So
I
think
overall,
russ
2018
was
a
success.
We
achieved
our
goals,
even
though
it
was
a
ton
of
work,
but
we
did
ship
the
addition
it
did
happen.
People
did
manage
to
understand
this
was
different
than
russ
2.0
and
they
didn't
like
run
away
thinking
that
we
totally
destroyed
our
you
know.
A
At
this
point
there
are
some
tweaks
and
things,
but,
like
you
know,
the
actual
out
of
the
implementation
went
smoothly.
For
the
most
part,
it
was
a
lot
of
work.
It
was
a
really
big
project
for
all
the
teams.
We
never
really
had
undertaken
such
a
big
project
before
other
than
maybe
rest
1.0,
which
is
again
sort
of
kind
of
like
an
addition,
and
so
we
managed
to
do
it
and
that's
positive
and
that
I
think
is
worth
like
celebrating.
A
A
Some
things
didn't
actually
get
finished,
some
things
changed
significantly
and
scope
had
to
be
cut
drastically
in
order
to
make
it
under
the
release
line,
and
so,
while
we
did
ship
the
mechanism-
and
it
was
successful-
it
just
barely
happened
like
the
release
is
going
to
talk
about
schedules
in
a
second
happened
in
december
of
2018..
We
actually
did
not
have
another
rust
release
that
happened
literally
at
the
last
moment,
and
so
that
also
was,
you
know,
a
sign
that
things
weren't
necessarily
as
ideal
as
they
could
have
been.
A
Secondly,
was
the
human
cost
of
the
edition
the
team
tons
of
people
put
in
tons
of
work
for
a
really
long
time
to
make
this
happen,
and
it
was
extremely
high
stakes,
because
this
was
a
really
big
thing.
It
was
the
first
time
we'd
ever
done
it,
and
so
that
contributed
to
a
lot
of
burnout
amongst
contributors.
I
believe
I
can
only
truly
speak
for
myself.
I
was
a
total
freaking
mess
by
the
time.
The
2018
edition
actually
happened,
and
I
wasn't
even
the
one
implementing
a
lot
of
this
stuff.
A
I
was
just
trying
to
like
keep
the
book
going
and
do
some
other
work,
so
other
people
worked
a
lot
longer
and
harder
than
I
did,
and
I
felt
terrible
honestly.
So
I
can
only
imagine
with
other
people.
You
know
how
they
felt
about
the
schedule,
so
we
did
it
but
like
at
what
cost
and
so
yeah
the
2018
edition
shipped
on
december
6
2018
with
rust,
1.31
and
what's
kind
of
funny
about
the
half.
A
Shipping
thing
too,
is
like
some
actual
changes
didn't
chip
until
132,
but
the
edition
itself
shipped
at
131.
So
yeah
we
shipped
a
bunch
of
different
things.
This
is
a
screenshot
from
the
blog
post,
so
non-lexical
lifetimes
happened
in
2018
module
system
changes
got
simpler
in
2018
we
did
some
more
elision
stuff.
Constant
functions
became
a
thing.
There
was
things
like
rust,
fix,
got
added
a
whole
bunch
of
lints,
like
clippy,
was
able
to
do
its
job
unstable
and
that
was
a
big
deal.
A
Documentation
got
updated.
We
had
the
new
domain
working
groups,
a
new
website.
Tons
of
things
happened
in
the
stand:
library,
lots
of
new
cargo
features.
There
was
just
like
all
sorts
of
stuff
like
2018
was
huge.
It's
a
really
big
deal.
We
shipped
a
lot
of
it
and
that's
deserved
celebrating
but,
as
I
said,
it
was
behind
schedule.
So
the
initial
rfc
had
sort
of
this
schedule.
There's
this
idea
of
a
preview
period
which
is
kind
of
like
you
can
think
about
the
addition
being
unstable.
A
So
the
idea
was
that,
like
okay,
rust
123
is
gonna,
start
shipping,
a
preview
of
the
edition
and
then
in
127
we're
going
to
like
nail
everything
down
and
actually
ship
it
and
that'll
be
when
it
comes
out.
So
to
put
some
dates
on
that,
123
was
january
4th
in
2018,
and
the
final
127
release
was
going
to
be
june,
21st
2018
so
halfway
through
the
year
and
if
you're
paying
attention
a
moment
earlier.
That
was
very
different
than
what
actually
happened.
A
So
what
actually
happened
was
the
changes
landed
in
the
nightly
compiler
on
the
6th
of
february,
so
that
was
almost
one
month
later
than
the
initial
release
was
planned
and
then
finally,
the
actual
release
was
in
december,
which
is
like
six
months
june
to
december,
something
like
that
a
long
time
later,
and
we
kept
thinking
it
was
gonna,
be
in
like
october,
and
then
that
slipped
and
then
november
and
then
slipped
and
then
december.
We
finally
got
it
out
the
door,
so
we
almost
missed
the
date
itself,
which
is
intense.
A
I
think
that
this
happened,
because
we
tried
to
do
too
much
partially.
That
was
because
there
was
a
lot
of
work
to
do
like
breast
1.0
was
a
really
small
release
and
there
was
a
lot
of
things
that
really
needed
to
be
tweaked.
We
had
this
opportunity
to
do
it,
so
we
committed
to
it
and
we
made
it
happen.
I
think
another
part
of
sort
of
some
of
the
problems
was
some
of
these
ideas.
A
We
tried
to
move
too
far
in
front
of
the
community,
so
like
some
of
the
things
around,
for
example,
the
anonymous
lifetime
were
added
and
I'm
not
even
sure
that
people
like
know
about
the
anonymous
lifetime
or
use
it
exactly
because
it
kind
of
got
lost
in
the
shuffle
a
little
bit.
But
we
had
some
ideas
about
some
patterns.
A
Then
it
got
scaled
back
and
then
some
things
got
sort
of
like
cut
or
barely
shipped,
and
we
tried
to
like
move
too
far
ahead
and
think
about
like
what
things
should
happen
rather
than
taking
what
happened
and
like
getting
the
good
parts
of
it.
There's
always
a
balance
to
be
had
there.
I
think
that
added
some
stress,
the
module
system
was
another
example
of
this,
where
we
like
kind
of
invented,
what
we
wanted
and
then
there's
a
lot
of
changes,
a
lot
of
feedback,
and
it
was
really
really
difficult
to
get
that
through.
A
Finally,
the
other
reason
why
I
think
we
bit
off
a
little
more
than
we
can
chew.
So
we
have
we're
really
really
great
that
we
have
so
many
contributors
to
us
and
we
did
at
that
time.
But
also
contributors
are
not
employees
and
it's
much
harder
to
plan
a
big
initiative
that
spans
a
whole
year
when
you
can't
be
guaranteed
that
there's
like
these
people
that
have
full-time
amounts
of
work
to
work
on
it
like
just
from
a
project
management
perspective.
A
Yet
another
positive
thing
was:
we
proved
that
the
mechanism
actually
worked
so
2015
and
2018
interoperate.
Just
fine.
The
plan
was
good.
It
happened.
You
know
you
don't
have
to
worry
about
this
thing.
We
can
have
our
cake
and
eat
it
too,
which
is
the
thing
we
always
try
to
do
in
the
rest
world.
We
didn't
split
the
ecosystem,
there's
not
a
holdout
of
people
that
use
2015
that,
like
are
sequestered
from
the
rest
of
the
community,
and
so
that's
like
really
important.
A
There
are
still
people
that
program
the
2015
edition
today,
and
they
can
do
everything
they
need
to
do
and
it
works
just
fine.
So
that's,
I
think,
a
really
important
thing.
I've
kept
some
coherence
and
I
think
that,
like
it
works
so
well,
because
it's
pretty
much
silent,
like
I
don't
think
most
users
think
about
editions,
a
whole
ton
which
is
part
of
why
I
wanted
to
start
this
talk
by
putting
out
all
the
details
because,
like
it
just
kind
of
works,
you
don't
really
think
about
it.
A
The
compiler
did
not
shift
to
rest
2018
for
a
little
while
neither
did
other
big
projects.
I
think
that's
also.
Okay,
like
expecting
everyone
to
upgrade
immediately,
is
part
of
like
an
unrealistic
expectation.
I
don't
think
we
totally
had
that,
but
there's
definitely
some
people
that
thought
that
should
happen
overall,
like
in
the
community
or
on
the
teams,
because
you
know
they
worked
on
smaller
projects.
But
you
know
some
production
users
reported
that
it
took
them
a
while
to
upgrade
to
2018
and
it
was
a
significant,
costly
kind
of
upgrade.
A
You
know,
even
if
it's
easy
to
do
still
takes
time
and
time
is
money
to
companies
and
companies
are
the
ones
that
have
the
biggest
rust
projects
because
they're
paying
people
to
work
on
things
full
time,
and
so
you
know
we
sort
of
put
a
big
burden
on
a
lot
of
our
biggest
users
and
that's
tough.
So
I
think
it's
it's
a
it's
a
challenge.
I
think
another
thing
that
happened
with
the
2018
edition
is:
it
became
feature
driven
instead
of
time
boxed.
So
you
know
normal
rust,
releases
or
time
box.
A
A
What
features
do
we
want
to
happen,
and
then
we
figured
out
how
to
make
them
happen
on
the
schedule,
but
then,
when
they
took
longer
to
implement
then
when
they
took
longer
to
implement
them,
maybe
we
thought
you
know
that
became
kind
of
an
issue,
and
so
that
was,
I
think,
a
lot
of
the
struggle
was
like.
We
need
to
get
these
features
out.
There's
this
time
deadline.
We
have
to
have
it
happen
before
the
time
that
doesn't
happen
with
normal
rust
releases,
because
there's
always
a
new
train
coming
in
six
weeks.
A
Like
part
of
the
reason
why
we
picked
the
train
model
in
the
first
place
is
because
we
knew
that
having
a
yearly
or
longer
release
schedule
was
a
problem.
So
then
we
decided
with
the
addition
system
that
we
were
going
to
do
that.
So
I
think
that
was
like
a
big
issue
kind
of
felt
like
lead
up
to
us
1.0,
where
there
was
this
big
giant
release
that
happened
and
everybody
worked
super
hard.
You
know
this.
A
2018
december
was
when
the
audition
shipped,
but
we
actually
shipped
the
the
you
know,
async
await
in
2019
instead,
almost
a
year
later,
and
I
think
that
worked
out
really
well
and
is
a
great
model
for
how
this
should
sort
of
work
in
the
future.
Is
that
we
don't
necessarily
like
you
know,
do
we
don't
force
everything
to
happen
and
we
don't
force
the
schedule
of
the
edition
to
happen
on
a
feature
basis?
We
kind
of
say
hey.
A
The
feature
is
going
to
be
on
this
cadence
and
you
know
we're
going
to
ship
the
feature
when
it
happens.
So
that's
important.
This
is
kind
of
blending
into
the
last
part
of
my
talk
here.
What
should
we
be
doing
so?
This
is
kind
of
like
my
opinion,
on
where
we
should
go
from
here.
Basically,
we
should
have
a
rest,
2021
edition.
A
First
of
all,
I
don't
think
we
have
as
much
need
as
we
did
in
2018,
but
secondly,
like
you
know,
I
think
that
it
will
just
go
smoother
if
we
don't
do
as
much,
and
I
also
think
that
a
lot
of
people
are
sort
of
craving
stability
in
the
rest
world,
and
so
I
think
that
that's
like
a
very
positive
thing,
so
a
smaller
edition
would
be
much
smaller
than
2018,
but
I
still
think
we
should
do
it
anyway.
There's
a
question
from
emmanuel
lima
in
the
chat.
A
Does
mozilla
hire
engineers
to
work
on
rusty
and
that
should
help
diminish
burnout?
No
mozilla
does
pay
some
people,
but
it's
a
very
small
amount
of
the
overall
team
and
there's
no
indication
that
mozilla
is
like
gonna
hire
10
more
people,
which
is
like
what
we
would
need.
So
yes,
while
they
could
in
theory,
do
that.
A
Basically,
but
it's
true
that
work
helps
diminish
burnout,
but
on
some
level
work
can
also
force
you
into
burnout,
because
when
it's
your
job,
you
have
to
do
it,
even
if
you
don't
want
to
so
like
deadlines
are
somehow
weirdly
more
stressful
with
jobs
than
they
are
with
open
source
projects.
I
think
so
you
know
like
I
said
I
was
a
mozilla
employee
at
the
time
of
the
2018
edition
and
I
got
burned
out
anyway,
so
I
don't
think
it's
a
pure
solution.
A
I
do
think
they
can
help
in
some
cases,
yeah,
okay,
so
release
trains.
Like
the
core
of
my
argument
with
the
2018
2029
edition
release,
trains
are
good
and
additions
are
kind
of
release,
so
we
should
have
a
train,
and
that
should
just
be
the
end
of
it
like.
We
should
no
longer
pick
date
based
releases.
A
We
should
just
always
do
trains,
because
there's
far
better
way
to
ship
software,
if
six
weeks
go
by
without
a
new
release
and
a
new
feature
in
the
regular
code
base,
we
still
put
out
a
new
rust
c
anyway.
Some
addition,
some
releases,
are
small.
Some
editions
are
big.
You
know,
that's
just
the
way
that
it
goes,
and
so
I
think
that
if
there's
three
years
go
by
and
we
don't
need
any
big
breaking
changes,
it's
totally
fine,
but
we
should
still
release
a
new
edition.
A
Sprutal
asks
a
question
in
the
chat
that
I'm
going
to
be
getting
to
very
shortly,
so
stay
tuned,
but
yeah
like
basically,
I
think
the
train
model
has
been
wonderful
and
I
think
that
we
should
do
it
with
additions
too.
There's
a
number
of
reasons:
I'm
not
going
to
get
into
all
of
them,
but
basically
like
the
shortest
version.
Is
it's
a
model
that
works
and
as
a
model
that
we've
demonstrated
is
feasible?
So
I
think
we
should
just
do
the
same
thing,
but
on
a
longer
schedule.
A
Some
people
argue
that
the
social
part
of
addition
shouldn't
matter,
and
we
should
only
make
editions
happen
when
we
have
the
feature
need,
but
I
think
that
that's
wrong.
Some
of
it
is
just
the
classic
arguments
back
and
forth
that
happen.
The
first
time
the
edition
happens
like
looking
over
the
past
three
years,
matters
getting
people
outside
of
us
to
pay
attention
and
stuff
matters,
and
all
that
stuff
still
happens.
A
I
think
that
smaller
editions
are
actually
a
nicer
marketing
message,
so
shipping
them
is
somehow
more
important
in
some
ways
than
a
big
breaking
change
release
because
it's
like
hey,
it's
been
three
years
with
rust
and
we
don't
feel
the
need
that
there's
any
big
breaking
changes,
because
we
think
the
language
is
good
enough.
That
is
a
very
strong
and
powerful
marketing
message
to
people
to
be
able
to
want
to
check
things
out.
A
People
are
still
like
leaving
comments
on
the
internet
all
the
time
about,
like
I
don't
know
that
rust
is
actually
stable
because
the
six
week
cadence
like
people,
don't
necessarily
know
how
much
time
and
effort
we
put
into
making
sure
those
things
are
stable,
and
so
you
know
every
six
weeks
seems
fast.
So
people
get
on
the
idea
of
like
oh,
I
only
deal
with
russ
every
three
years
feels
better
to
a
large
number
of
people.
So
I
think
that
really
matters.
A
So
yeah
there's
another
question
on
which
I'll
get
to
in
one
second,
so
okay,
spruta,
l,
here
is
your
question
on
a
slide.
So
what
feature
should
be
in
rest?
2021?
I
actually
don't
care
personally.
There
are
some
features
I
want,
obviously,
but
I
think
that
we
should
do
it
regardless,
and
I
don't
think
that
we
need
to
have
a
specific
feature
to
justify
doing.
In
addition,
in
fact,
I
kind
of
think
the
argument
is
stronger,
purely
on
the
like
release,
engineering
and
marketing
angles
and
not
on
the
feature
based
things.
A
Like
you
know,
if
we
do
it
on
a
feature
basis,
then
it
happens
at
random
kind
of
times.
If
we
just
say
like
hey,
this
is
the
mechanism
it
happens
on
the
schedule
period.
Then
we
can
free
our
time
actually
working
on
making
rust
a
better
language
rather
than
worrying
about
this
policy,
and
so
I
think,
that's
actually
the
sort
of
most
important
kind
of
thing.
I
will
answer
that
question
predko
afterwards,
so
why
a
three-year
cadence,
it's
just
like
a
nice
length
of
time.
A
So
the
first
draft
of
the
this
standard
of
c
plus
was
in
2008
c
plus
plus
03
was
the
previous
year
of
the
standard,
and
so
bjorn
and
some
other
people
were
hoping
that
this
would
be
c
plus
plus
08
or
o
9..
So
they
named
it
plus
ox.
The
problem
was,
is
that
they
made
it
on
a
feature
basis
and
it
took
them
so
many
years
to
get
through
all
the
details
and
ended
up
shipping
in
2011,
and
so
people
used
to
joke
that.
A
It
was
becoming
oa
because,
like
they
had
missed
like
with
the
0809
scheme,
it
strip
slipped
to
10,
so
it
should
be
c
plus,
plus
10,
but
they'd
already
said
ox.
So,
like
you
know,
this
demonstrates
some
of
this
kind
of
like
conflict
here,
and
so
that's
when
they
decided
to
move
to
the
train
model
for
the
super
plus
releases
was
like
we're
releasing
every
three
years
because,
like
this
was
just
not
great,
and
so
I
think
we
had
a
similar
kind
of
learning
from
2018.
A
So
I
think
that
that
matters,
I'm
gonna,
answer
some
more
of
these
questions
afterwards,
because
I'm
almost
done
with
my
slides,
then
we
can
get
into
sort
of
the
details
so
specifically-
and
this
is
kind
of
like
the
second
part
of
of
your
questions
brutal
earlier
so
there's
this
comment
on
the
internals
forum.
Recently,
like
hey
the
roadmap
for
the
year.
What
things
are
we
actually
going
to
do
in
2021?
So,
even
though
I
don't
think
it,
matters
should
talk
a
little
bit
about.
Maybe
what
I
see
happening.
A
A
A
A
Okay,
this
is
not
formally
done
yet,
so
you
know
we
also
need
to
plan
that,
and
so
I
think
that
even
the
stuff
the
language
team
is
talking
about
is
nothing
like
2018
like
the
scale
is
very,
very
small
overall
they're,
like
kind
of
smaller
details
about
things,
there's
an
example
of
one
thing
that's
been
talked
about.
I
don't
know
if
this
will
happen
or
not,
or
what
the
chances
are
even
there's
been.
A
Some
discussion
that,
like
unsafe
functions,
should
have
be
able
to
call
unsafe
code
in
their
bodies
without
an
unsafe
block,
or
you
should
need
an
unsafe
block
forget
which
order
it
is.
But
there's
like
things
like
that
that
are
like
really
tiny
edge
kind
of
things
and
nothing
like
the
module
system
is
being
redone.
So
I
think
anything
that
happens
in
2021
will
be
important
and
matter,
but
like
will
be
relatively
small
changes
and
not
like,
we
saw
what
happened
in
2018..
A
There
is
going
to
be
an
rfc
on
this
question
of
policy
nico
and
I
were
supposed
to
be
working
on
this.
But
honestly
I
got
busy
with
my
new
job
and
nico
did
most
of
the
work.
So
we
should
have
something
published
relatively
soon
to
answer
this
question,
and
then
we
can
have
this
discussion
as
a
community
overall,
because
you
know
it's
not.
The
teams
do
get
to
decide
what
they
want
to
decide,
but
we
want
feedback
from
everyone
to
talk
about
all
the
details.
A
So
you
know
that
stuff
kind
of
matters,
so
you
can
expect
to
see
an
rfc
in
the
near-ish
future.
Talking
about
the
policy
of
whether
we're
having
an
audition
or
not
and
then
also
the
language
team,
you
know
if
we
decide
we're
having
one,
the
language
team
would
be
able
like
what
is
actually
an
edition.
So
that's
all
going
to
come
over
the
next
four
months.
So
thank
you
for
letting
me
talk
about
that
for
an
hour.
That's
the
end
of
my
presentation
and
now
there's
some
questions
that
were
in
the
chat.
A
I
definitely
want
to
cover,
so
I'm
going
to
go
from
the
start
to
the
end
of
the
ones.
I
did
not
answer
already
so,
okay,
there
was
a
question
from
someone
whose
name
has
a
lot
of
numbers,
and
I
don't
know
how
to
pronounce
it.
I'm
sorry
does
it
seem
reasonable
to
you
to
make
an
addition,
a
snapshot
of
already
shipped
features
so
keeping
features
opt-in
until
the
next
edition,
while
making
them
shipped
and
stable
as
opt-in.
I
think
that's
nice
in
some
ways.
A
I
think
that
doesn't
always
work
in
some
other
ways
so
like
what
I
would
sort
of
like
to
see
is
that
we
have
these
like
features
that
need
an
addition.
Break
you're
sort
of
able
to
opt
into
the
addition
on
unstable,
so
it's
kind
of
like
that
preview
idea
that
happened
before
so.
Basically,
like
you
know,
the
feature
exists
and
we're
able
to
try
it
out
on
nightly.
A
But
you
know
it's
only
about
tweaking
the
edition,
rather
than
tweaking
all
the
details,
and
I
think,
wherever
possible,
we
shouldn't
use
the
addition
mechanism,
like
it
making
things
a
breaking.
Change
should
happen
only
if
they
have
to
so.
You
talk
about
the
async
keyword
being
a
breaking
change,
but
I
think
that,
like
you
know,
the
union
keyword,
for
example,
was
a
contextual
keyword
and
we
didn't
need
to
do
that.
A
Okay,
so
preco
sylvester
asked
a
question
about
why
we
don't
have
function
overloading.
So
is
this
historical
situation
or
some
design
background
kind
of
not
exactly
related
to
my
talk
other
than
in
theory?
This
is
a
big
feature
that
would
make
sense
for
additions.
I
guess
so
I
mean
one
simple
example
of
why
russell's
not
function
overloading
is
no
one
has
ever
written
an
rfc
to
suggest
adding
it.
So
some
people
have
written
pre-rfcs
and
some
people
have
done
some
of
the
work.
A
But,
like
honest
core
most
features
in
rust,
you
know
don't
exist
because
people
didn't
do
the
design
work.
Now.
This
is
a
little
controversial
with
this
specific
feature
because,
like
I
said,
some
people
have
gotten
up
there
and
I
think
there's
actually
an
open
rfc
right
now.
So
maybe
I
don't
want
to
say
is
there's
no
accepted
rfc,
but
I
think
that
specifically
function
overloading
is
interesting
because
rust
does
have
function
overloading
today
in
terms
of
traits
sort
of.
So
it's
not
the
same
as
like
when
you
think
about
I.
A
A
This
is
hard
because
function,
overloading
optional
arguments
and
named
arguments
kind
of
all
are
three
features
that
are
technically
separate,
but
are
something
as
a
language
designer
you
kind
of
want
to
consider
holistically
and
that's
a
really
big
design
space,
and
so
there's
also
some
people
that
are
interested
in
those
other
two
features
as
well,
but
you
kind
of
really
in
my
opinion
and
I'm
not
on
the
lang
team.
So
again,
this
is
my
personal
opinion
on
this.
A
One
thing
I
will
say
on
the
named
arguments
front,
though,
is
I,
with
rust,
analyzer
putting
the
names
of
arguments
displayed
in
the
text.
I
have
found
them
more
useful
to
see
that
I
would
have
thought
so.
It
actually
made
me
feel
a
little
better
about
named
arguments
than
I
would
have
otherwise,
but
I
think
that
the
again
rust
analyzer
doing
that
gives
you
all
the
benefit
without
changing
the
language.
So
putting
in
language
seems
like
a
lot
of
work.
It
doesn't
doesn't
really
get
you
a
ton
of
benefit
for
me
personally
yeah.
A
I
think
the
core
challenge
is
that
it's
really
hard
to
put
all
three
of
those
features
together
and
design
them
all
at
once.
That's
a
huge
space
and
it's
very
difficult,
so
I
don't
blame
anyone
that
cares
about
this
feature
that
has
put
in
some
of
the
work
it's
kind
of
like
not
made
it
happen,
because
it's
just
it's
really
big
topic
in
a
really
big
area.
It's
really
hard,
okay,
so
floor
b
is
talking
about
being
in
the
only
make
editions
happen
when
there's
a
need
camp.
A
A
I
think
that
part
of
that
is
because
you
need
the
social
side
to
advertise
the
technical
side
like
they're,
inherently
intertwined,
and
I
know
as
programmers
we
really
like
to
separate
out
things
and
we,
you
know,
want
everything
to
be
kind
of
in
its
own
little
box.
But
I
think
that
specifically,
like
with
big
major
changes
to
the
language
and
ones
that
are
breaking
you're
gonna
have
to
learn
about
and
stuff.
A
There
has
to
be
some
sort
of
social
component
of
letting
people
know
that
those
things
exist
and
so,
like
yeah,
you
could
argue
that,
like
we
should,
you
know,
celebrate
what
we've
done
on
a
different
cadence
than
the
release
of
the
actual
breaking
changes,
but
like
that
just
means.
We
have
kind
of
like
two
major
points
where
we
need
a
bunch
of
communication,
and
I
think
that
it
all
just
works
better
by
leaning
into
the
fact
that
they're
actually
not
separate.
A
I
do
know
that
there
are
some
people
that
feel
very
strongly
that
I'm
wrong
on
this,
and
that's
also
totally
fine.
Just
for
me
personally.
I
think
that
they're,
not
it's,
not
really
possible
to
untwine
them,
and
it's
actually
a
good
thing
that
they
are
together
because,
like
you
need
to
be
able
to
communicate
those
things,
you
need
to
make
it
work
out.
A
They
should
be
like
two
separate
ones:
kind
of
what
we
did
last
time
was
we
blogged
before
the
edition
actually
happened
to
kind
of
talk
about
what
was
going
to
happen,
and
then
the
release
post
was
kind
of,
like
more
of
you
know,
describing
the
changes
in
detail.
So
it's
kind
of
a
way
to
split
that
up
a
little
bit
to
some
degree.
A
I
think
that
when
you
start
to
separate
it
out
too
much
you
get
into
the
exact
problem
that
we're
talking
about
the
last
question
which
is
like,
I
think
they
need
to
be
around
each
other,
because
you
want
to
communicate
them
at
the
same
time.
So
I
do
think
that
including
them
all
in
one
thing
or
small,
maybe
like
in
like
a
month
kind
of
area
sort
of
thing,
but
but
yeah
hope
that
answers
your
question
jack
asks.
Would
it
be
jack
asks
to
be
clear?
A
Would
it
be
another
three
years
till
it's
available
or
just
available
in
the
next
russ
c
so
like?
Basically,
I
think
that
we
should
be
flexible
a
little
bit
about
the
exact
time
when
we
stabilize
the
edition,
like
I
don't
think
we
should
commit
to
a
specific
release,
because
I
think
that's
what
introduces
like
a
lot
of
the
problems.
A
All
right
so
also,
I
think
that,
having
the
time
before
things
are
released
matters
because
putting
something
in
addition
that
has
a
breaking
change.
As
I
said,
it
impacts
people
a
lot,
so
we
should
do
so
very
carefully,
and
so
I
think
that
one
of
the
sort
of
like
problems
of
2018
too,
was
like
we
had
these
grand
plans.
A
What
does
it
mean
if
something
misses
the
train?
Like
say,
we
had
a
gc,
which
is
not
a
thing
that
could
happen,
as
you
say,
but
it
missed.
The
train
would
be
another
three
years
yeah,
so
it
would
have
to
be
another
three
years
unless
what
missing
the
train
would
mean
would
mean
that
the
stuff
that
needs
to
be
backwards
and
compatible
would
miss
the
release.
A
So
imagine
if
we
did
not
make
async
a
keyword
in
2018,
it
would
have
to
be
a
keyword
in
2021,
and
that
would
mean
that,
like
async,
await
couldn't
have
shipped
yet
because
the
time
wouldn't
have
happened.
So
I
think
the
feature
implementation
missing.
The
train
is
totally
fine,
like
that's
what
happened
with
async
right,
like
the
breaking
change
made
it
in,
but
the
implementation
didn't
happen
until
later.
A
Great,
I
think
that's
totally
fine,
and
in
fact
I
think,
is
the
model
that
should
kind
of
happen.
Is
that,
like
the
stuff
that
is
breaking?
That's
not
ready?
Yet
we
don't
worry
about
making
sure
that
it's
actually
happened
exactly
by
you
know
the
time
the
release
happens,
and
some
of
this,
I
think,
is
because
two
it
takes
time
for
the
ecosystem
to
catch
up.
A
So,
for
example,
with
async
like
async,
even
if
async
await
had
landed
on
the
day
of
rest
2018,
the
ecosystem
would
not
be
ready
yet
and
so
for
most
people
like
it's
already
been
almost
a
year,
since
these
await
happened.
Time
flies
and
the
ecosystem
is
really
still
only
now.
Finally,
getting
into
a
production
ready
state
like
async,
await,
wasn't
really
a
2018
feature.
A
It
was
really
a
2021
feature,
and
so
I
think
that,
like
really
a
lot
of
the
edition
stuff
should
be
looking
back
over
the
last
three
years,
rather
than
looking
forward
to
the
new
stuff
and
so
like
in
some
sense,
the
stuff
that
we
reserve
in
this
edition.
You
know
gets
used
by
folks
and,
like
is
only
really
part
of
rust
world
until
the
future,
and
I
think
there's
some
weird
interplay
there,
and
that's
also
why
it's
kind
of
hard
to
do
these
kind
of
bigger
macro
level,
changes
and
thinking
about
things.
A
So,
yes,
and
no
like,
I
think
that
there's
two
things
that
are
tied
up
here,
one
is
that
I
don't
think
it's
possible
to
have
a
unified
run
time
for
everything,
because
rust
is
used
in
too
many
places.
So,
for
example,
like
I'm
a
big
fan
of
both
of
those
projects,
but
I
also
do
embedded
rest
work
now
and
there's
some
stuff
that
maybe
would
be
good
as
asynchronous.
I'm
not
going
to
be
running
tokyo
on
like
my
embedded
device.
A
So
I
would
need
an
embedded
executor
that
makes
very
different
trade-offs
than
tokyo.
Tokyo
is
built
for
network
services
specifically,
so
it's
made
several
trade-offs
that
make
lots
of
sense
for
those
things,
but
it
wouldn't
make
sense
for
my
microcontroller
and
the
same
token
like
if
I
was
building
a
web
service,
I
wouldn't
want
to
use
my
microcontroller
async
await
impul
because
it
made
the
wrong
trade-offs
for
me.
So
I
think
that
it's
not
possible
for
what
what
rust
is
trying
to
accomplish
to
have
a
unified
run
time.
A
That
said,
it
should
be
possible
to
make
libraries
you
run
time
agnostic,
so
it
doesn't
matter
what
you
run
time,
I'm
using
and
that's
like
kind
of
one
of
those
open
things.
That's
still
being
worked
on
and
you
know
like.
I
don't
think
this
is
the
kind
of
thing
that
happens
from
a
big
top-down
perspective.
I
think
that
it
just
takes
time
in
the
ecosystem
for
folks
to
hash
out
what
they
need
and
what's
going
on,
then
we
compare
experiences
and
we
consolidate
where
possible.
A
So
there
hasn't
been
any
big
news
on
that
front
lately,
but,
like
all
the
people
involved
are
still
working
on
it
and
I
think
everyone
cares
about
making
things
agnostic,
at
least
conceptually,
because
nobody
wants
things
to
be
locked
down
into
one
specific
area.
So
it's
just
it's
just
really
tricky,
but
a
lot
of
a
lot
of
libraries
are
agnostic
today,
but
not
as
many
as
there
could
be,
and
there's
still
more
work
to
do
there
for
sure
all
right.
A
I
definitely
agree
with
what
you're
getting
at
that
would
be
really
nice,
but
just
like
I,
it's
not
really
possible
basically
and
yeah.
I
am
doing
great
now.
Thank
you.
Just
took
a
while
to
get
at
a
burnout,
okay,
so
best
question,
I
I
I
it's
basically
like
there's
only
15
minutes
left
and
I
almost
lost
my
voice.
As
I
said,
there's
still
more
questions.
I've
not
answered
I
apologize
and
not
get
on
to
them,
but
we
pretty
much,
don't
really
have
a
ton
of
time.