►
From YouTube: Rust: A Language for the Next 40 Years - Carol Nichols
Description
Learn what makes the programming language Rust a unique technology, such as the memory safety guarantees that enable more people to write performant systems-level code. Hear about how Rust Editions evolve the language and the compiler without breaking existing code. See who’s trusting Rust for critical products today. Join us on Rust’s journey to the future.
Philly ETE 2019 Playlist: https://www.youtube.com/playlist?list=PL9oQ7yETvN10Lopbg81O_bwElm9grUkDB
On the Chariot Solutions site: http://chariotsolutions.com/screencasts/
A
A
So
if
you
want
to
be
able
to
follow
up
on
references
and
check
out
some
more
things,
this
short
link
will
take
you
to
a
repo
where
there's
link
to
view
the
slides
on
the
web
and
the
readme
has
just
the
links
pulled
out
as
sort
of
alluded
to
in
the
intro
I'm,
the
co-author
of
the
rest
programming
language
book,
which
is
available
for
free
online
and
available
in
print
from
no
starch
press
I'm.
Also,
a
co-author
on
a
Manning
live
video
series
called
rusted
motion.
A
That's
in
early
access
right
now
and
thanks
to
Manning
I,
have
three
codes
for
free
access
to
this
rest
in
motion.
So
the
favorite,
my
favorite
three
questions
are
going
to
get
access
to
this.
So
please
ask
wonderful
questions
on
the
slide
slide.
Oh
question
asking
platform:
I
am
also
a
co-founder
of
integer
32,
the
world's
first
rust
consulting
company
and
I
am
an
organizer
of
rust
belt,
rust,
a
regional
rust
conference
this
year,
we're
going
to
be
in
Dayton
Ohio
on
October,
18th
and
19th
and
I'm
on
the
rust
core
team.
A
So
if
you
were
hoping
for
an
objective,
unbiased,
look
at
rust,
you're
not
gonna,
get
that
from
this
talk.
I
clearly
have
a
slant
here:
I
love
rust.
So
much
that
my
favorite
hockey
player
is
two-time,
Stanley
Cup,
winning
champion
Brian
rust
from
the
Pittsburgh
Penguins.
And,
yes,
you
may
throw
tomatoes
at
me
or
batteries
or
whatever
it
is
that
you
do
here
in
Philadelphia.
I
could
take
it
alright.
So
in
this
talk
today
we're
gonna
talk
a
little
bit
about
the
railroad
industry,
but
you
weren't
expecting
that.
But
we
are
we're.
A
Gonna
talk
about
C,
we're
gonna
talk
about
rust
and
we're
going
to
talk
about
what
the
software
industry
can
learn
from
the
railroad
industry.
So
a
little
railroad
industry,
history,
commercial
railroads
in
the
United
States
started
being
built
around
1830
and
trains
are
really
great.
They
let
you
get
across
this
huge
country
of
ours,
a
lot
faster
than
things
like
stagecoaches,
and
they
really
took
off
built
lots
of
lines
of
Braille
all
around
the
country
really
fast,
but
as
the
miles
of
rail
and
as
the
train
trips
grew
injuries
and
deaths
also
grew.
A
It
turns
out
that
once
you
get
a
big
train
moving,
it's
kind
of
hard
to
get
it
to
stop
again,
and
there
were
lots
of
collisions.
There
were
lots
of
accidents
and
one
of
the
most
dangerous
jobs
on
the
railroads
was
that
of
the
brake
man,
because
the
way
you
used
to
have
to
get
trains
to
stop
is
someone.
A
The
engineer
would
blow
a
certain
signal
with
the
whistle
that
he
wanted
to
stop
and
then
people
would
have
to
go
off
on
the
top
of
each
car
and
turn
this
wheel
to
put
the
brakes
on
and
then
move
to
the
next
car,
and
eventually
the
train
would
slowly
come
to
a
stop
as
all
the
brakes
were
applied.
But
this
wasn't
really
an
exact
science.
So
if,
at
best
case,
if
this
didn't
go
well,
you
would
miss
the
station.
A
You
were
trying
to
stop
at
worst
case
if
you
needed
to
stop
in
a
hurry,
probably
couldn't
and
you
there
were
collisions
and
accidents
and
this
job
being
on
top
of
the
train
when
it
was
rainy
or
icy.
It's
pretty
dangerous
and
a
lot
of
brake
men
would
fell
to
fall
off
the
train
and
be
killed.
This
was
a
this.
Is
the
thousands
of
brakeman
died
every
year?
This
is
second
only
to
mining
as
the
most
dangerous
career
in
the
eighteen.
Hundred's
enter
George
Westinghouse,
a
an
amazing
Pittsburgher.
A
He
invented
lots
of
things
was
part
of
making
electricity
viable
and
and
commercially
available,
and
in
1869
he
invented
the
first
air
brake.
There
have
been
improvements
made
over
the
years,
but
essentially
his
air
brake
is
what
trains
use
today.
The
way
air
brakes
work
are
that
they're
controlled
by
compressed
air
rather
than
a
physical
wheel.
On
top
the
car.
A
There's
a
control
up
in
front
for
the
engineer
to
turn
the
brakes
on
and
off,
so
they
don't
have
to
use
the
whistle
to
communicate
all
the
cars
are
connected,
so
that
when
the
engineer
turns
the
brakes
on
all
of
the
cars
start
breaking
all
the
same
time
and
a
later
failsafe
was
added
so
that
when
there
isn't
pressure
to
each
car
through
this
connection,
the
brakes
are
on
so
that
this
is
safe
by
default.
You
would
have
to
apply
the
pressure
to
turn
the
brakes
off
and
get
the
car
moving.
A
So
if
something,
if
all
the
Scotch
is
connected,
the
Train
would
would
come
to
a
stop
instead
of
continuing
to
go,
and
this
system
was
a
lot
more
complex
than
the
hand
brakes
and
there
was
some
skepticism.
This
was
a
quote
from
Vanderbilt
who
was
the
guy
behind
Vanderbilt
University
eventually,
but
he
he
couldn't
believe
that
that
error
was
going
to
be
what
stops
trains,
but
they
did
a
lot
of
public
tests.
A
lot
of
demonstrations
that
involved
people
riding
in
train
cars
with
like
pillows
everywhere
testing.
A
All
these
sorts
of
different
kinds
of
brakes
and
like
running
into
the
wall
is
because,
when
different
kinds
of
brakes
didn't
work,
but
the
air
brakes
were
passing
all
these
public
tests
and
there
were
a
lot
safer
and
a
lot
better
at
getting
the
trains
to
stop,
then
the
hand
brakes
were
railroads
are
adopted.
These
four
passenger
trains
pretty
quickly
because
consumers
demanded
it.
This
is
an
advertisement
for
a
particular
train,
and
the
this
yellow
part
here
says
that
the
Swift
operation
of
these
nightly
carriers
is
safeguarded
by
Westinghouse
air
brakes.
A
So
this
is
something
that
the
market
demanded
that
that
they
there
were
people
who
were
scared
to
ride
trains
because
they
couldn't
stop.
But
these
air
brakes
gave
people
the
confidence
that
they
could
ride
the
train
safely.
However,
on
freight
trains,
it
took
a
lot
longer
for
these
air
wrecks
to
be
adopted,
and
there
was
this
person
named
coffin.
A
Who
was
a
big
advocate
for
mandating
these
air
brakes
be
used
on
all
trains
and
he
worked
for
the
Iowa
Railroad
Commission
and
when
he
started
he
said
that
the
people
on
the
Commission
just
kind
of
thought
that
this
was
the
way
it
was.
Trains
are
dangerous
and
brakeman
were
going
to
die,
so
there
wasn't
really
much.
We
could
do
that.
This
is
just
how
things
were,
but
he
a
coffin
got
kept
getting
all
these
reports
about
brakeman
being
killed
and
was
like
no.
This
is
these
are
all
the
same
cause.
A
We
have
to
do
something
about
this,
so
he
did
a
lot
of
advocacy.
There's
this
there's
transcripts
of
a
Senate
hearing
for
the
run,
the
Interstate
Commerce
Committee
that
I
just
find
riveting
I
like
reading
these
Senate
transcripts
from
1890
and
they're
amazing
coffin
had
a
lot
to
say
in
favor
of
mandating
air
brakes
on
all
trains.
The
industry
people
were
didn't
want
to
be
regulated,
so
they
had
a
lot
of
interesting
arguments.
A
A
They
were
like
the
air
brakes
are
still
gonna
fail,
sometimes
the
like
it
doesn't
matter
the
hand
brakes
fail.
The
air
brakes
are
also
going
to
fail.
So
why?
So?
Why
should
we?
They
simultaneously
made
two
arguments.
They
said
we
are
already
innovating
without
legislation.
We
are
testing
new
things
all
the
time
to
improve
the
safety
of
the
Train.
If
you,
if
you
regulate
that,
there's
some
minimum
standard,
we're
gonna,
adopt
the
thing.
That'll
meet
the
law
and
we're
gonna
stop
innovating.
So
that
was
one
argument
in
like
the
next
breath.
A
This
guy
at
so
liberating
testimony
said
and
what,
if
something
better,
comes
along
and
we've
already
have
all
this
sunk
costs
into
these
air
brakes?
It's
like
wait.
A
second
wait.
Are
you
saying
you're
gonna
keep
innovating?
Are
you
saying
you're
gonna
stop
innovating,
because
now
you're
saying
what
we're
gonna
happen,
they
really
just
didn't
want
to
be
regulated.
A
They
said
they
have
other
means
they
have
to
pay
for
they
can't
possibly
afford
these.
They
said
you
should
have
regulated
this
twenty
five
or
thirty
years
ago.
All
sorts
of
things,
my
favorite,
my
favorite
objection
from
the
president
of
the
Pennsylvania
Railroad
Company
was:
are
you're
gonna
regulate
the
trains?
What's
next,
are
you
gonna
regulate
the
bridges?
It's
like?
Yes,
please.
A
We
want
the
bridges
to
be
safe
too.
Actually
so
yeah.
It
turns
out
that
the
US
railroad
safety
appliance
Act
passed
Congress
in
1893,
mandated
the
use
of
air
brakes
and
standard
couplers
to
connect
the
trans
together
in
1900.
It
was
fully
enforced
and
all
trains
whether
a
passenger
freight
had
to
be
using
these
safety
devices
and
accidents
and
deaths
of
both
people
being
run
into
both
people
and
things
being
run
into
by
trains
and
brakeman
operating
the
trains
went
way
down.
This
helped
a
whole
lot.
It
wasn't
perfect,
but
it
was
way
better.
A
So
now
we're
gonna
talk
a
little
bit
about
C.
So
why
might
companies
choose
C
who-who
works
at
a
company
who
has
Z
code
in
production
today,
okay,
yeah
good,
all
right,
you,
you!
Might
you
probably
have
a
variety
reasons?
Why
you're
doing
that?
It's
a
proven
solution
that
has
worked
for
40
years.
It's
fast.
It
has
very
little
overhead,
it's
kind
of
close
to
the
Machine
close
to
the
assembly
language.
It
uses
very
little
resources.
A
A
You
might
have
a
lot
of
existing
C
code
or
you
might
want
to
interface
with
existing
C
code.
That
makes
it
easy
means
using
C
would
make
that
easier
and
C
doesn't
really
change
a
whole
lot
and
enterprise
software.
The
field
moves
rather
slowly
and
you
don't
want
to
have
lots
of
parts
changing
out
from
underneath
you
and
having
your
code
become
obsolete.
A
So,
but
in
order
to
get
all
these
advantages,
you
have
to
agree
to
what
I
see
as
a
huge
disadvantage
that
outweighs
all
of
that
is
that
C
has
all
these
memory
safety
problems?
It's
not
memory
safe.
These
problems
include
use
after
free
double
free
memory,
leaks
buffer
over
reads
and
over
writes
no
pointers.
Databases.
Oh
my.
This
is
just
a
lot
of
problems
that
you
have
to
sign
on
to
when
you
are
shipping
C
in
production
and
I'm.
A
Sure
those
of
you
who
have
seen
production
can
tell
lots
of
stories
about
problems
caused
by
all
of
these
and
a
lot
of
people
say
well,
it's
you
just
be
more
careful.
Then
we
can
avoid
these
problems.
It's
not
a
matter
of
being
more
careful,
we're
in
it's.
The
experience
in
past
40
years
has
shown
we're
not
capable
of
being
careful
enough.
A
There
is
a
vulnerability
called
stage
fright
in
Android,
and
this
blog
post
was
illustrating
some
C
code
to
try
and
explain
what
the
root
cause
of
stage
fright
was,
and
he
said,
you'd
have
to
be
more
careful
than
the
entirety
of
the
Android
security
team.
Every
C
developer
shipping
code
impression
has
to
be
more
careful
than
that.
A
A
There
have
been
some
efforts
to
make
C
safer.
There
are
tools
like
valgrind
there's
tools
like
address
sanitizer
undefined
behavior,
sanitizers
I
found
this
tool
called
IKOS
that
does
abstract
interpretation
as
a
static,
static
analysis.
It's
from
NASA,
so
you'd
have
passive,
has
a
really
rigorous
engineering
discipline.
A
So
if
that's
the
kind
of
investment
you
want
to
make,
you
can
check
out
tools
like
that
there
are
the
misra
guidelines.
All
of
these
kind
of
strike
me
as
things
you
do.
After
the
fact,
you
write
the
code
first
and
then
you
try
and
make
it
safe,
which
you
have
to
make
sure
you
do
those
things
you
can't
forever
forget
you
have
to
build
them
in
the
processes.
You
have
to
allocate
time
to
do
that
and
fix
the
problems
you
find
it
seems
like
kind
of
patching
it.
A
None
of
these
have
really
caught
on
much
you're.
Still
writing
C.
That
has
very
little
abstractions.
You
have
to
reinvent
the
wheel
all
the
time
you
don't
have
modern
tools
that
go
with
it
and
if
you're
gonna
be
switching
languages
anyway.
I
advocate
that
you
look
at
all
your
options
and,
of
course,
they're
C++,
which
improves
some
things
by
not
everything,
there's
still
a
lot
of
undefined
behavior.
There's
still
a
lot
of
pointer
problems
you
can
get
into
multi-threaded
programming
is
still
a
big
problem
in
C++.
So
what
can
we
do
about
this?
A
So
Russ
is
a
language
out
of
Mozilla
research.
It's
trying
to
learn
from
the
mistakes
of
C
and
bring
in
ideas
from
a
bunch
of
other
languages
too
I
see
it
as
moving
our
industry
forward
and
trying
not
to
repeat
the
same
mistakes
over
and
over
again.
I
have
five
reasons
why
I
think
Russ
is
ready
to
last
as
long
as
C
has.
The
first
reason
is
that
it
fixes
these
memory
safety
problems.
A
A
The
owner
of
that
memory
is
this
variable
X,
and
when
that
owner
goes
out
of
scope,
that's
when
the
heap
memory
it
gets
cleaned
up
automatically
rust
kind
of
inserts
a
looks
at
this
code.
I
was
compiling
inserts
a
statement
at
compile
time
that,
at
the
end
of
main,
that
cleans
up
that
memory,
so
we
don't
have
to
write
free
free,
the
memory
that
X
manually,
but
there's
also
not
a
garbage
collector
running
at
runtime.
This
is
all
compile-time.
A
This
is
another
example.
In
this
example,
we've
got
the
same
string
in
X,
then
we
say
let
y
equals
2x
and
we
try
to
print
out
X.
This
line
here
moves
ownership
of
the
string
from
X
to
Y,
and
this
code
does
not
compile
because
we're
trying
to
use
X
again
after
we've
moved
it
into
y.
So
we
see
this
data
still
only
has
one
owner.
A
After
that
point,
we've
moved
it
into
y
Y,
we'll
clean
that
up
and
X
note
is
no
longer
valid
and
we're
no
longer
allowed
to
use
it
after
we've
moved
it.
So
we
don't
have
double
three
problems
and
we
can't
use
after
free
this
code
instead
of
moving
ownership.
This
borrows
Y
is
a
an
immutable
borrow
of
X.
It's
allowed
to
read
the
the
data
that
X
owns,
but
X
is
still
responsible
for
cleaning
up
the
memory.
A
In
this
example,
we
are
trying
to
create
a
dangling
pointer.
We
have
an
inner
scope
and
we're
trying
to
return
a
reference
to
heap
data
from
that
inner
scope.
The
problem
is
that
the
way
rust
ownership
works,
X
is
going
to
get
cleaned
up
at
the
end
of
that
inner
scope.
So
this
code
doesn't
compile
because
we're
trying
to
use
the
reference
after
that
data
has
been
cleaned
up
and
rust
can
see
that
at
compile
time
and
doesn't
let
us
run
this
code
because
X
gets
cleaned
up.
A
Rust
has
a
lot
of
other
safety
mechanisms
that
I
don't
have
time
to
get
into
fully.
One
of
the
rules
about
references
is
that
you
can
have
either
one
mutable
changeable
reference
at
a
time,
or
you
can
have
many
immutable
references
for
reading
at
one
time.
So
this
prevents
databases
so
that
you
can't
change
a
value.
While
someone
else
is
trying
to
read
it.
A
There
are
no
no
pointers,
there's
the
option
type
that
represents
either
something
and
holds
a
value
or
there's
none.
The
none
value
and
the
compiler
makes
sure
you
handle
both
some
or
none
at
compile
time
out
of
balance,
array,
axises
or
data
structure
accesses
at
run
time.
It
just
stops
the
program
immediately
and
doesn't
let
you
continue
with
invalid
data
that
isn't
part
of
your
data
structure.
A
The
ownership
rules
apply
across
multiple
threads
there's
parts
of
the
type
system
that
allow
you
to
express,
transferring
ownership
or
borrowing
across
multiple
threads.
So
now,
programming,
parallel
or
concurrent
programs
is,
is
checked
at
compile
time
that
you
don't
have
data
races
across
threads.
A
It's
what
you
can
keep
in
your
head
all
at
one
time
and
trying
to
keep
all
these
rules
and
keep
make
sure
you're
doing
all
these
things
right
in
your
head
with
C
is
really
tedious
and,
as
we've
seen,
is
error-prone,
it's
it's
too
much
for
one
person
to
hold
your
head.
In
addition
to
your
problem,
domain
is,
and
but
there's
someone
who's
really
good
at
keeping
track
of
tedious
things
and
making
sure
that
they're
right
every
single
time.
A
A
A
Okay,
compiler
I
understand
that
you
can't
ensure
that
this
code
is
going
to
be
safe,
every
single
time
I
as
a
person
I'm
going
to
audit
this
specific
code
and
I
will
make
sure
that
I'm
following
the
Murray
rules-
and
this
is
useful
in
certain
performance
cases,
when
you're
trying
to
express
certain
pointer
arithmetic
when
you're
trying
to
call
to
external
code
that
the
compiler
can't
possibly
know
anything
about.
So
as
and
as
long
as
you
don't
put
your
entire
program
in
an
unsafe
block.
A
What
I
like
about
this
is
that
when,
if
you
have
a
seg
fault
or
memory
access
problem
at
runtime,
you
know
it
came
from
one
of
those
unsafe
blocks.
It's
like
hey
look
over
here.
This
is
probably
where
the
memory
problem
came
from,
because
the
compiler
didn't
check
this
part,
so
you've
you've
lessened
the
places
you
have
to
look
to
debug
to
figure
out
those
problems.
A
A
This
is
this
is
the
default,
is
too
bright,
safe
code
and
you
can
opt
out
of
it
if
you
need
to.
If
you
want
more
information
on
writing
unsafe
code,
there's
this
great
talk
for
building
an
unsafe
foundation.
The
other
neat
thing
is:
you
can
build
safe,
abstractions
out
of
unsafe
code
and
there's
a
whole
book
on
unsafe
code
called
the
Resta
nomicon.
A
Like
air
breaks,
sometimes
don't
stop
a
train.
Rust
doesn't
prevent
all
problems,
you
might
have
a
software,
it
does
not
prevent
you
from
having
logic
bugs.
It
can't
tell
that
you
meant
to
tell
the
program
to
do
one
thing
and
it's
actually
doing
another.
So
you
stole
the
need
things
like
tests
and
you
still
need
to
write
things
like
buzzers,
but
by
choosing
to
use
rust,
you're
getting
memory
safety
you're
not
going
to
have
all
those
problems
that
C
has.
So,
let's
go
back
through
the
reasons
that
you
might
choose
C
and
C.
A
What
we're
trading
off,
because
there's
always
trade-offs
and
in
any
sort
of
decision
you
might
make
performance
Russ,
is
on
the
order
of
C's
performance.
There
aren't
the
the
additional
checks
that
Russ
does
are
mostly
at
compile
time.
There
isn't
a
garbage
collector.
It
isn't
checking
much
at
run
time.
You
can
still
get.
A
We
have
the
goal
of
having
zero
cost
abstractions,
which
means
that
the
abstractions
you
use
our
compiled
down
to
code
that
you
could
not
write
better
by
hand.
Of
course,
there
are
always
things
we
can
improve
on,
but
zero
cost
abstractions
are
what
we're
aiming
for,
we're
hoping
that
rust
will
perform
as
well
as
C
in
the
situations
you
want
to
use
it
portability,
Russ
compiles
to
LVM
intermediate
representation,
so
you
can
write
rust
and
compile
it
for
any
platform
that
ll
be
I'm
Ken.
A
There
are
C
compilers
that
target
platforms
that
LVM
doesn't
there
could
be
a
non
LOV,
M
back-end
for
us
there
isn't
one.
Yet
there
isn't
I
reason
that
why
there
couldn't
be
other
than
people
putting
in
the
work.
So
if
you
need
to
write
code
for
one
of
the
platforms
that
Russ
doesn't
support,
that
could
be
a
deal-breaker
for
you,
but
we
do
support
a
lot
of
platforms.
So
this
one
is
a
little
bit
of
both.
A
A
I
actually
have
a
whole
talk
on
porting,
a
library,
the
softly
compression
library
that
was
written,
C,
porting
it
to
rust
function
by
function,
keeping
it
compiling
and
passing
tests
at
every
commit,
and
the
thing
I
like
about
this
technique
is
that
you
don't
even
have
to
finish.
You
don't
have
to
convert
the
whole
thing
to
rest
to
see
benefit.
A
You
could
convert
just
the
parts
that
change
the
most
the
parts
that
happen
most
bugs
and
you
could
set
it
aside
for
a
while,
if
you
have
other
high
priority
things
to
work
on,
but
you
still
get
those
benefits
along
the
way
of
converting
little
pieces
to
rust.
So
you
don't
have
to
rewrite
all
of
your
stuff
in
rust.
To
see
benefits,
stability
is
one
I
want
to
spend
a
little
more
time
on.
There
is
a
new
version
of
rust
that
comes
out
every
six
weeks.
A
We
have
a
train,
really
small
sort
of
like
Firefox
and
Chrome
do
so.
You
might
think
that
Russ
is
really
unstable
and
it's
gonna
change
all
the
time,
but
we
have
really
strong
backwards.
Compatibility
guarantees,
we've
committed
to
rust,
100
came
out
in
May
2015,
so
we've
been
stable
and
shipping
stable
codes
every
six
weeks.
Since
then
there
is,
we
do
have
a
little
bit
of
an
out
we've.
Given
ourselves,
we
reserve
the
right
to
fixing
piler
bugs
patch
safety
holes
and
change
type
in
France
in
ways
that
occasionally
require
a
new
type
of
annotations.
A
A
This
question
I
feel
like
we
need
to
change
the
wording
of
it
a
little
bit
because
it
doesn't
really
distinguish
between
breaking
compilation,
which
is
what
our
stability
guarantees
are
really
about,
versus
breaking
runtime,
behavior
or
slowing
down
your
code
at
runtime
or
speeding
it
up.
You
don't
you
broken
it
in
that
way,
and
I'd
like
to
I'd
like
to
be
able
to
get
into
those
problems
a
little
bit
more
and
see
how
we're
really
doing
on
our
compiled
time.
A
Another
part
that
I
think
part
of
our
stability
story.
That
will
let
us
last
for
40
years
is
that
we
have
a
goal
of
stability
without
stagnation.
We
want
to
be
able
to
evolve
rust,
to
learn
from
our
own
mistakes,
to
make
the
language
easier
to
use
and
to
learn,
while
still
not
breaking
our
backwards.
Compatibility
guarantees
and
the
mechanism
that
rust,
we've
designed
to
use
in
rust
is
called
additions,
and
this
is
a
link
to
a
detailed
specification
of
what
additions
are
I'm
gonna
go
over
the
hi
love
idea.
A
Mainly
they
are
opt-in
about
every
three
years
is
what
we're
thinking
we've
just
made
Russ
2018
edition,
and
the
original
edition
of
Russ
is
2015,
so
we
have
two
editions
right
now.
What
they
are
is
it
the
biggest?
The
biggest
change
we
want
to
make
that's
not
backwards
compatible
is
adding
new
keywords
for
adding
new
features
so,
for
instance,
we're
going
to
be
adding
asynchronous
functions
to
Russ
the
language
soon,
and
we
wanted
the
async
keyword
to
be
able
to
do
that,
but
your
existing
code
might
have
function
async.
A
A
But
if
you
did
nothing
to
your
code,
upgraded
your
compiler,
it
would
still
treat
it
as
rust,
2015
edition
code,
and
it
would
continue
to
treat
async
as
not
a
keyword
and
can
you
could
compile
your
code
when
I
first
heard
of
this
idea,
I
thought
it
sounded
terrible
from
a
compiler
maintenance
point
of
view.
You
have
to
maintain
two
ways
to
use
every
feature
forever,
because
we
wanted
to
commit
to
all
editions
being
supported
forever,
but
it's
actually
not
that
bad.
A
The
way
editions
way
the
compiler
works
today
is
you
have
your
Russ
source
code,
the
compiler
turns
it
into
a
high
level,
intermediate
representation
and
then
turns
it
into
mid
level.
Intermediate
representation,
then
turns
it
into
LLVM.
Intermediate
representation
and
LLVM
turns
it
into
machine
code.
A
lot
of
the
complex
analysis
that
the
compiler
does,
such
as
borrow
checking
optimizations
and
code
generation
happen
at
this
mirror
this
mid
level,
intermediate
representation
level.
A
The
way
additions
have
been
implemented
is
that
they're
kind
of
at
the
surface
level,
they
affect
the
code,
the
source
code,
that
you'll
write
and
they
affect
the
high
level
intermediate
representation.
But
once
you
get
to
the
mid
level
representation
it,
the
mid
level
stuff
is
all
the
same,
whether
it
would
no
matter
which
Edition
you
came
from.
A
So
all
this
complex
analysis
code
can
stay
the
same
for
both
editions
and
it's
only
the
the
first
part
of
this
conversion.
That
is
an
a
maintenance
burden
this,
because,
because
the
compiler
understands
both
editions
and
multiple
editions,
once
we
have
more
and
can
compile
2015
code
or
2018
code,
that
means
we're
not
going
to
have
an
ecosystem
split
Russ,
Russ
2015
project
can
depend
on
a
project
written
using
Russ,
2018
idioms
and
vice
versa.
So
it
doesn't
matter
if
all
your
dependencies
have
opted
in
or
not
the
same.
A
Compiler
can
understand
either
code
and
can
compile
it
all
together
and
the
important
things
about
this
is
that
you
get
to
pick
when
you
decide
to
change
which
Edition
you
want
to
use.
You
can
keep
upgrading
your
compiler
every
six
weeks,
but
you
don't
have
to
switch
on
that
flag
to
change
the
idioms
until
you
decide
the
benefits
outweigh
the
cost
of
upgrading
and
never
is
a
totally
valid
choice.
We
plan
to
support
Russ
28
2015
edition
code
for
as
long
as
rust
exists
in
order
to
decrease
the
burden
of
switching
editions.
A
We
also
have
a
tool
call.
It
Russ
fix
that
for
as
many
changes
that
we
can
do
automatically,
it
will
apply
those
changes
and
fix
up
your
code
and
move
you
to
the
new
edition
automatically
so
we're
trying
to
if
you
do
want
to
switch
to
the
new
edition
we're
trying
to
make
that
as
painless
as
possible.
Also,
the
editions
concept
I
am
confident
that,
with
using
this
to
evolve,
the
language
means
we're
never
going
to
have
rust.
A
You,
oh
we're
not
going
to
break
backwards-compatibility,
so
we
hope
to
be
as
stable
as
c
is
for
the
next
four
years.
We
do
have
a
lot
of
things
that
aren't
done
yet
with
rust.
That
might
prevent
you
from
using
it
in
your
company.
We
don't
have
a
standard,
that's
going
to
take
a
long
time
and
a
lot
of
work.
We
do
want
to
get
there
someday,
but
it
was
years
and
years
before
C
has
a
standard,
so
we
do
want
to
get
there,
but
we're
not
there.
A
Yet
we
don't
have
a
certified
compiler
that
will
matter
in
some
industries.
We
do
want
to
have
a
long
term
support
release
that
gets
things
like
security
fixes
and
certain
bug
fixes.
We
don't
have
a
policy
for
that.
Yet
cargo
is
the
build
tool
that
rust
kind
of
expects
you
to
use.
If
you,
you
don't
use
that
it
gets
a
little
hard
to
tinker
with,
and
some
companies
have
build
systems
that
everything
needs
to
feed
into
and
we
have
work
to
do
to
make
cargo
fit
into
build
systems
that
are.
A
If
you
have.
We
have
an
open-source
package
registry
for
open
source
code.
We
don't
have
good
solutions
for
libraries
that
you
might
want
to
keep
private
only
share
within
your
company
and
the
ecosystem
is
still
growing.
So
there
might
not
be
a
library
for
everything
you
might
want
to
do
in
rust
yet,
but
these
are
all
things
we're
working
on
and
we
hope
to
get
there
soon.
A
Another
reason
I
think
we're
going
to
last
is
that
there
are
today
a
number
of
large
enterprise
software
companies
using
rusts
and
they've
invested
their
products
in
rust,
so
they're
invested
in
rusts
future.
The
biggest
one,
of
course,
is
Mozilla.
He
heard
of
the
Firefox
quantum
release
a
while
ago,
where
Firefox
got
a
lot
faster.
A
One
big
reason
of
that
was
a
big
component
got
that
was
rewritten
in
rust
were
shipped
with
that
the
component
was
the
CSS
rendering
that
can
now
render
all
the
CSS
properties
in
your
page
in
parallel,
and
they
did
some
analysis
of
the
security
bugs
in
this
component
that
was
written
in
C++
and
found
that
since
the
beginning
of
Firefox,
there
were
69
security
bugs
in
this
CSS
component.
If
they
could
have
gone
back
in
time
than
written
in
rust
from
the
beginning,
rust
would
have
prevented
51
of
those
which
is
about
3/4
of
them.
A
A
Apple
I,
don't
know
of
any
public
uses
of
rust
at
Apple.
They
have
Swift,
which
actually
is
really
similar
to
rust.
I
was
in
the
Swift
talk
earlier,
and
they
have
a
lot
of
the
same
problems
and
a
lot
of
trying
to
solve
the
same
problems
that
rust
is
but
use
different
words
for
it.
So
I
was
like
sitting
there
trying
to
translate
him
like
stats.
A
The
fifth
reason
that
I
think
we're
set
up
to
last
is
our
project
governance,
like
the
trains.
The
adoption
of
this
is
not
only
for
the
technical
reasons,
there's
also
political
reasons
and
I
think
we
are
we're
building
a
good
foundation
here.
We
don't
have
a
be
DFL
a
benevolent
dictator
for
life,
there's
not
just
one
person
making
final
decisions
on
on
rust.
A
We
have
a
number
of
teams
and
working
groups
made
up
of
multiple
people
responsible
for
different
parts
of
language,
and
we
have
a
lot
of
different
people
represented
on
those
teams
and
working
groups.
We
have
programming
language,
theorists,
people
with
PhDs
and
programming
languages.
We
have
people
using
rust
for
a
product
for
a
company.
We
have
people
using
rust
for
fun.
We
have
people
who
come
from
the
low
level
languages
like
C
and
C++.
We
have
people
from
high
level
languages
like
I
come
from
Ruby
and
in
our
surveys.
A
I
feel
really
strongly
that
as
an
open-source
person
that
this
is
important,
that
this
isn't
driven
Rus
direction
is
not
driven
by
a
corporate
closed
entity,
making
decisions
in
secret
that
you
have
no
idea
why
they're
doing
and
we're
not
going
to
take
it
in
some
surprising
direction.
If
we
do
you'll,
if
we
do
take
it
in
a
different
direction,
you'll
know
that
we're
doing
it
you'll
be
able
to
see
us.
Do
that.
A
Another
big
you
think
part
of
our
governance
is
that
we
have
a
code
of
conduct
and
have,
since
the
language
was
open-source
and
I
loved,
that
this
has
been
since
the
beginning.
So
we
don't
have
to
have
the
argument
about
whether
we
should
adopt
one
or
not.
That
decision
has
already
been
made.
We
have
one.
We
are
trying
to
make
a
professional
space
for
professionals
to
work
on
technology
and
without
problems.
A
This
the
software
industry
has
a
reputation
for
being
a
little
bit
arrogant.
We
think
we
can
do
things
better
than
other
fields
have
done
them.
There's
the
time
that
a
software
company
thought
they
could
do
juice
better
than
other
people
and
actually
didn't
work
any
better
than
squeezing
juice
packet
by
hand.
A
There's
the
time
that
there
were
people
stuck
in
a
cave
and
Elon
Musk
thought
he
could
do
cave
rescues
better
than
the
people
who
specialized
in
that
sort
of
thing.
So
so
we
think
we're
better
than
other
industries.
If
you
just
add
a
little
software,
we
can
totally
fix
these
long
standing
problems
that
other
industries
have
had
were
so
much
better.
I
think
I
think
we
have
to.
We
have
to
work
to
prove
it.
If
we,
if
we
actually
are
better,
we
need
to
show
that
we're
better
and
we
binding
regulation
to
do
this.
A
But
there's
a
problem
is
that
it's
it's
pretty
easy
for
everyone
to
understand
that
if
you
can't
stop
a
train,
people
are
gonna,
get
hurt.
People
are
gonna,
kill.
Pretty
uneasy
to
understand
that
being
on
top
of
a
moving
train
in
any
weather
is
a
dangerous
thing,
but
it's
it's
not
easy
to
understand
what
what
memory
on
safety
even
is,
and
it's
not
easy,
even
easy
for
us
to
see
what
the
effects
of
that
are.
So
like
I'm,
trying
to
imagine
the
the
Senate
transcripts
from
reading
that
in
the
future.
A
From
now
of
software,
people
trying
to
explain
memory
on
safety
to
senators
and
it's
terrible-
it's
I
don't
see
this
going
well,
so
I,
don't
think
I.
Don't
think
government
is
going
to
improve
the
safety
of
software,
but
I
think
we
can
improve
ourselves.
We
can
be
our
own
improved,
informed
consumers
that
demand
that
our
dependencies
are
safer
before
we
incorporate
them
into
our
software,
because
we
understand
our
own
problems.
That
is
the
part
that
we
can
show
that
we
are
better.
A
The
railroad
industry
got
really
started
in
1830
Westinghouse
invented
the
air
brake
in
1869,
and
then
everyone
was
using
it
by
1900.
So
this
is
about
80
years.
You
know:
no,
that's
not
right!
7
years
about
40
years
to
invent
a
safer
thing
about
30
years
for
people
to
start
using
it,
rust
became
stable
in
2015
I'm,
arguing
that
that
is
a
better,
safer
sea
I,
don't
know
how
long
it's
gonna
take
us
to
adopt
something:
that's
memory
safe!
Can
we
do
better
than
the
railroad
industry?
A
I
don't
know,
I
want
us
to
be
better
I'm,
not
sure
if
we
are
better
I
hope
that
we're
better
all
right.
That's
that's
most
of
my
arguments
if
you're
still
feeling
a
little
skeptical,
that's
totally
fine,
I'm
I'm
willing
to
be
wrong.
I
I
am
willing
for
us
and
to
not
be
the
solution
as
long
as
we
do
something.
Let's
just
do
something
to
fix
these
memory
safety
problems
that
keep
happening
over
and
over
and
over
again,
maybe
maybe
it's
not
gonna,
be
rushed.
Maybe
there's
something
better
than
rest.
Maybe
it's
sake.
A
Dick
go
to
the
next
talk.
I'm
pleading
fortitude.
Maybe
maybe
it's
go,
there's
a
go
talk
tomorrow,
or
maybe
maybe
it's
all
of
them.
Maybe
it's
there's
not
gonna,
be
one
replacement,
maybe
there's
different
replacements
that
are
better
for
different
situations.
That's
fine,
I'm!
Totally!
Okay,
with
that,
you
don't
have
to
choose
rest
I,
just
I
just
want
us
to
stop
making
the
same
mistakes
over
and
over
again.
A
Okay
again,
this
is
the
link
to
my
slides
and
links
that
I
reference,
I'm
carol's
ten
cents,
there's
a
code
for
everyone
to
have
that
will
get
you
40%
off
anything
I'm,
Manning,
calm,
and
that
code
is
right.
There
and
I
would
like
to
thank
my
test
audience.
My
daughter
Vivian
and
my
cat
baby.
They
were
very
patient,
provide
valuable
feedback.
A
Okay,
let's
do
what's
with
the
name
rust,
there's
there's
multiple
stories
here:
the
people
who
started
rust
enjoyed
riding
bicycles
and
bicycles
often
have
to
deal
with
rust.
The
logo.
Our
logo
is
kind
of
a
bicycle
gear.
There's
also
a
fungus
called
rust
that
grows
on
wheat.
Sometimes
that
is
a
potential
inspiration
that
has
been
suggested
as
why
why
rust
I
like
to
think
of
it
as
something
something
something
stable,
something
that
has
been
around
a
long
time:
a
stable,
strong
coating
on
the
outside
there's.
Actually,
this
Corten
steel,
the
u.s.
A
steel
tower
in
Pittsburgh
has
built
out
of
it.
It's
steel
that
is
meant
to
rust
on
purpose,
to
protect
it
instead
of
paint
so
I
like
thinking
of
Corten
steel,
so
partha
I
liked
your
question.
If
you
are
still
here,
I
have
an
envelope
for
you
there
yeah!
Thank
you,
okay,
why
would
you
recommend
rust
Oberg?
Oh
I,
also
like
this
question
so
anonymous
who
asked
this.
If
you
would
make
your
way
to
the
front
while
I'm
answering
there
are
a
couple
of
big
differences
in
rust
and
go.
A
There
actually
is
aiming
for
slightly
different
spaces
I.
They
I
think
they
get
compared
a
lot
because
they
came
out
around
the
same
time
and
they're
both
aiming
to
be
kind
of
C++
alternatives.
Go
has
a
garbage
collector,
which
might
be
a
deal
breaker
in
your
application.
So
if
you
can't
have
something
at
runtime
using
resources,
then
I
would
recommend
rust
if
you're
trying
to
interface
with
Google
products,
I
think
go
is
probably
going
to
be
a
really
smooth
way
to
have
everything
all
in
the
same
language
for
simplicity
purposes,.
A
And
like
yeah
III
think
you
should
check
them
both
out
and
you
should
make
I
think
one
of
them
is
going
to
resonate
with
you
over
the
other.
So
I
think
you
should
do
some
intro
programming
in
both
of
them
and
and
make
your
own
choice.
So
is
someone
going
to
fess
up
to
asking
that
question
for
a
free
code?
No,
okay,
all
right!
Arguably
one
of
the
reasons
for
choosing
C
these
days
is
a
great
IDE
support.
Does
the
rest
have
solid
IV
integration
we're
working
on
it?
A
A
Okay,
this
is
this
is
a
good
question.
I
mentioned
a
new
async
in
2018
magician
and
the
it's
async
already
in
the
2015
mission.
It's
actually
in
neither
Edition
right
now
when
we
created
the
2018
magician,
we
just
reserved
the
keyword
for
async
and
we
wanted
to
have
a
sync
support
done
by
the
time
we
shipped
the
Edition.
But
it's
it's
not
it's
not
done.
People
are
working
on
it
right
now.
There's
a
lot
of
open
discussion
on
the
RFC's
about
the
exact
syntax,
the
exact
way
it's
gonna
work.
A
So
if
you're
interested,
you
can
go
check
that
out,
but
it's
is
not
an
either
and
if
once
it
is
done,
it
will
probably
be
available
in
both
it's
just
that
the
syntax
in
Rus
2015
isn't
is
not
going
to
use
a
key
word,
so
it's
not
going
to
be
as
nice
as
syntax
as
it
will
be
in
Rus
2018.
So
who
asks
the
async
question
all
right,
then
that
is
all
the
codes
I
have
and
I
think
I'm
just
about
out
of
time.
So
thank
you
very
much
for
having
me.