►
From YouTube: Rust Programming Techniques
Description
Nicholas Cameron
http://lca2018.linux.org.au/schedule/presentation/22/
Rust is a language for fearless systems programming. It offers memory safety, data race freedom, and a modern programming environment, without sacrificing low-level control over performance and memory usage.
Learning a new programming language is hard. Even after mastering the syntax and type system, learning the libraries and techniques can take years. If you've read or written Rust and want to improve, this talk will give you a turbo boost! This will be a very practical tutorial, aimed at taking your Rust programming to the next level. We'll teach some core Rust design principles by covering a few key topics in depth. This tutorial is aimed at those with some Rust experience, but if you're a total beginner, you'll still learn a lot about what Rust programming is like in practice.
The tutorial will start with programming 'in the small': we'll explore some key library types (Option, Result, and Iterator) and cover practical error handling. Putting these together we'll see how to structure your control flow to write clear, succinct programs. We'll then cover some larger-scale design issues - using ownership as a primary architectural principle, and abstraction using traits.
You'll learn how to be more productive in Rust by writing clean and idiomatic code. You'll learn to work with the language rather than fighting against it.
This talk was given at Linux.conf.au 2018 (LCA2018) which was held on 22-26 January 2018 in Sydney Australia.
linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/
#linux.conf.au #linux #foss #opensource
A
B
B
B
What
an
alternate
title
I
played
around
with
this
talk
was
kind
of
thinking
in
rust
and
why
I
want
you
to
get
to
what
I
want
to
help
you
do
is
to
really
get
into
kind
of,
like
the
mindset
of
an
experienced
rust
programmer
so
you're,
not
kind
of
like
fighting
the
rust
compiler
anymore,
you're
kind
of
like
working
with
it
and
winning
so
the
it's.
It's
mostly
going
to
be
kind
of
like
a
chalk
and
talk
kind
of
tutorial,
I
didn't
realize.
We'd.
B
B
Okay,
so
the
tutorials
going
to
be
in
kind
of
two
halves.
The
first
half
is
gonna,
be
kind
of
programming
in
the
small
so
like
how
to
write
better
function,
bodies
how
to
write
better
kind
of
like
code,
the
micro
kind
of
level
so
gonna
cover
a
few
of
the
really
key
fundamental
data
types
that
every
Russ
program
I'd,
like
users
will
have
you
Russ
program
uses
a
lot.
B
The
second
half
of
the
tutorial
is
gonna,
be
kind
of
like
programming
in
the
large,
although
it's
more
kind
of
like
the
medium
are
not
so
much
gonna
touch
on
kind
of
architectural
issues,
so
much
is
kind
of
like
design
issues
how
to
design
the
kind
of
like
data
types
and
abstractions
in
your
programming.
How
to
do
error
handling
in
your
in
your
program.
B
B
Safe
and
fast,
this
is
like
the
kind
of
the
foundation
of
everything
and
rust
we
we
want
to
be
like
a
systems,
programming
language,
and
that
means
it
has
to
be
fast
like
as
fast
as
C
or
C++,
or
even
like
hundred
and
assembly,
and
a
lot
of
cases,
but
it
has
to
be
safe
memory.
Safety
is
like
a
big
selling
point
and
rust
in
this
respect,
we
kind
of
as
safe
as
like
a
higher-level
garbage-collected
language,
but
also
safe
in
other
ways.
B
We
want
to
like
avoid
giving
you
so
many
options
for
shooting
yourself
in
the
foot,
as
you
have
in
some
programming
languages,
but
really
this
is
just
like
this
I
mean
this
would
be
quite
cool
in
a
language
if
you
just
have
safe
and
fast
write,
but
actually
this
is
just
like
the
starting
point.
This
is
like
what
we
consider
like
table
stakes
or
any
kind
of
like
new
feature
in
the
language
and
what
we
want
kind
of
like
move
towards.
B
B
Okay.
So,
let's
start
throwing
in
the
small.
So
just
to
let
you
know
what's
coming
up,
the
data
types
are
going
to
talk
about
option
results
and
iterator
and
I
reckon
that
in
any
given
like
Russ
program,
maybe
50
percent
of
the
types
that
you
ever
use
are
these
three
types.
Basically.
So
these
are
really
kind
of
like
fundamental
to
rust
and
in
terms
of
control
flow.
We're
going
to
touch
on
the
match
statement,
which
is
a
kind
of
pattern,
matching
construct
and
iteration
in
just
kind
of
it
in
in
general.
B
B
Okay,
so
I'm
gonna
start
with
some
C
code,
so
this
is
fairly
idiomatic
C
code,
although
it's
not
actually
doing
very
much
or
C++.
Sorry,
we're
gonna,
take
her
to
stern
objects
of
type
foo
and,
of
course,
we're
good
programmers.
So
we're
going
to
do
a
null
check
because
there
could
be
a
null
pointer
and
if
it's
not,
then
we're
going
to
call
a
method
on
this
object.
B
There's
actually
quite
a
lot.
I
mean
it's
pretty
easy
to
forget.
The
null
check
I
mean
hopefully
we're
all
excellent
programmers.
No
one
here
would
ever
forget
doing
a
null
check,
but
it's
a
pretty
easy
mistake
to
make
if
you're
a
beginner
and
actually
much
more
common,
is
you
don't
need
the
null
check?
Because
there
is
some
invariant
established
somewhere
else,
but
of
course
it's
code
and
code
evolves
and
that
invariant
changes
and
all
of
a
sudden
you
need
a
null
check.
B
The
this
pointer
variable
could
get
mutated,
I
mean
probably
not
in
the
function
as
it's
written
at
the
moment.
But
you
know
if
this
were
a
more
complex
function
and
especially
if
that
variable
is
aliased
and/or,
it
gets
passed
to
some
other
function.
It's
actually
pretty
easy
for
a
variable
to
get
mutated
without
it
being
obvious
from
the
from
the
code
and
pointer
could
be
like
it
could
be
non
null,
but
it
might
be
like
otherwise
invalid
so
I
mean
it.
B
Could
it
could
just
be
a
random
punch
in
numbers
right
or
it
could
point
to
memory,
that's
already
been
freed
or
to
memory,
that's
never
been
initialized
and
your
null
check
isn't
gonna
catch
that
so
here's
what
the
same
code
looks
like
in
rust
and
you
don't
have
any
of
those
problems
which
is
nice.
So
let
me
kind
of
explain
what's
going
on
here,
as
you
say,
I'm
not
really
going
to
like
explore
in
this
tutorial.
Why
you're
not
getting
all
of
those
problems
just
kind
of
like
some
of
them?
B
You
have
to
set
my
word
for
it
on
the
others.
So
the
really
interesting
things
that
are
happening
here.
Let's
start
with
the
type
of
the
points
who
are
passing
in
so
the
amps
and
foo
is
a
is
a
reference
to
foo
and
references
are
pointers,
but
they
are.
They
can
never
be
known.
Okay,
if
you
want
to
represent
a
pointer
that
might
be
null,
you
have
to
wrap
it
in
this
option.
Type
and
an
option
says:
either
you
have
something
or
you
have
nothing
okay.
So
it's
just
like
a
null
pointer
like
ether.
B
It
like
we've
got
something
and
we're
pointing
all.
We've
got
zero
and
we're
pointing
at
nothing,
except
that
it's
explicit
in
the
type
and
rust
okay,
so
you
have
to
opt
in.
You
know
that
it's
there
and,
unlike
a
null
pointer,
you
are
forced
by
the
type
system
to
check
whether
you
have
something
on
nothing.
If
you
try
to
just
run
this
G
method
on
the
the
PTR
variable,
it
would
be
a
type
error.
Instead,
we
have
to
use
this
match
statement
and
a
match.
B
Does
a
pattern
match,
and
there
are
two
patterns
that
this
option
can
be.
It
can
either
be
sum
or
it
can
be
none,
and
in
the
son
case
you
can
go
ahead
and
use
the
value.
That's
there
and
you
know
that
it's
there
and
in
the
none
case
we
do
nothing
and
we
return
exactly
like
we
would
in
the
null
check
and
because
of
the
scoping
in
this
statements,
it's
impossible
to
mutate.
The
the
PTR
variable
once
you've
done,
the
equivalent
of
the
null
check.
B
So
these
these
two
two,
these
two
key
concepts
option
and
match,
and
it's
gonna,
come
out
drill
into
into
these
a
little
bit
so
match
is
an
exhaustive
pattern.
Matching
it's
a
little
bit
like
a
switch
statement,
except
that
we
force
it
to
be
the
compiler
kind
of
like
checks.
That
will
be
exhaustive.
So
here's
a
really
simple
example:
we've
got
an
enum
type
with
three
variants:
a
B
and
C,
and
assume
that
X
has
type
foo.
B
B
B
A
switch
statement,
the
match
statement,
can
be
used
as
an
expression,
so
oh,
and
also
it
binds
variables
in
the
pattern
matching.
So
we've
changed
the
enum
a
little.
So
now
the
a
variant
takes
a
value
with
it,
so
either
it.
So
if
we
have
a
foo
like
X,
is
meant
to
be
a
foo
here,
then
we've
got
three
options:
either
it's
an
A
or
it's
a
B
or
it's
a
C
and
if
it's
an
A,
then
it's
carrying
with
it
a
32-bit
integer.
And
so
when
we
pattern
match
using
the
match
statement.
B
In
the
a
case,
we
can
bind
this
new
variable
n
to
the
value
and
we
can
use
that
value
in
the
code
block
and
we
can
or
we
can
kind
of
return
it
as
the
value
of
the
match
statement
and
in
this
case,
like
all
the
branches,
have
to
have
the
same
type.
So
in
the
default
case
we
use
0,
and
then
we
assign
all
that
into
the
the
variable
little
case.
Food.
B
So
that's
a
very,
very
brief
introduction
to
match.
There's
a
lot
more.
That
match
can
do
you.
You
can
have
quite
fancy
patterns,
you
can
it
does
deep
pattern
matching
if
you
have
kind
of
like
nested
types
that
you
want
to
match
into.
There
are
kind
of,
if
guards
that
you
can
have
on
the
the
match,
arms
and
so
forth.
But
that's
if
your
interests
in
that
you
can
can
look
it
up.
B
B
B
It's
very
easy
to
use
because
it's
so
common,
it's
part
of
the
Russ
prelude.
That
means
like
you,
don't
need
to
import
the
name
or
quad
or
qualify
the
name.
When
you
use
it,
you
can
directly
use
kind
of
the
option
or
some
or
none
the
names
of
the
variants
directly
in
your
Russ
program
and
also
in
arms
are
kind
of
optimized
cleverly
by
the
vampire.
B
So,
even
though
you
have
like
an
option
of
a
pointer,
and
so
this
seems
like
it's
a
little
bit
more
heavyweight
than
just
having
a
pointer
that
might
be
nullable,
the
compiler
will
optimize
that
to
the
same
thing.
Okay,
so
if
you
know
that
a
pointer
will
never
be
0,
which
you
do
or
sorry
the
compiler
knows,
then
it
will
optimize
the
the
option,
representation
in
memory,
so
that
it's
just
a
pointer
and
the
non
case
is
represented
by
the
null
pointer.
B
B
The
result
type
is
very
similar
to
the
option
type.
It's
just
another
generic
enum,
the
difference
being
that,
whereas
with
option
you
either
have
like
something
or
you
have
like
nothing
with
the
result,
with
the
result
type,
you
either
have
something,
or
you
have
an
explanation
of
why
you
have
nothing
okay,
so
you
have
like
the
the
value
type,
which
is
kind
of
like
the
success
value,
and
you
have
like
an
error
type
in
case
the
an
error
happened.
B
B
B
B
So
the
question
is:
is
there
any
significance
to
the
exclamation
mark?
Yes,
so
an
exclamation
mark
means
that
this
is
a
macro
usage
rather
than
a
function.
Call
so
you
so
print
line
is
a
macro
not
a
function,
and
whenever
you
use
a
macro,
you
have
to
use
an
exclamation
mark.
The
reason
for
that
is
that
there
are
things
that
a
macro
can
do
that
a
function
call
can't
do.
B
Excellent,
okay,
so
the
result
type
is
absolutely
central
to
rust
error
handling.
Essentially,
it
is
rust,
error,
handling
story,
we're
going
to
go
into
a
little
bit
of
detail
right
now
about
how
you
can
use
it
ergonomically
and
then
we're
going
to
see
a
bit
later
in
the
talk
about
kind
of
like
designing
error
handling.
But
its
result,
that's
really
important.
Okay
and
so
what
you
often
see
a
function,
signature
which
looks
like
this,
like
it
returns
a
result
of
T
in
and
arrow
type
and
the
kind
of
way
the
way
to
read.
B
B
If
you're
kind
of
like
a
die-hard
C
program
out,
then
you're
probably
used
to
kind
of
like
return
codes
and
result
basically
works
like
that,
except
that
you're
forced
to
check
it
in
the
same
way
that
you're
forced
to
check
for
null
pointers.
So
you
can
imagine
you
know
the
these.
Are
the
error
codes
like
in
when
you
get
like
your
arrow
type,
but,
like
the
you
know,
if
you
have
success,
then
you
get
the
the
success
value
passed
back
at
the
same
time.
B
B
So
I
want
to
introduce
a
few
bits
of
control
flomax
that
make
it
easier
to
use
types
like
result.
So
it's
pretty
common
to
see
idioms
like
this,
with
the
match
statement,
where
we
call
some
function
or
we
do
some
work
and
if
it's,
if
there's
success,
then
we
do
something
with
the
value
that
was
that
we
got
back
and
otherwise
we're
just
gonna
do
nothing.
Actually,
this
is
probably
more
common
with
option
than
with
result.
You
probably
want
to
handle
your
error
and
not
just
do
nothing.
Although
that's
a
strategy.
B
But
this
is
this
is
common
nevertheless,
and
so
we
have
a
special
construct
which
does
essentially
kind
of
non-exhaustive
pattern
matching,
which
is
a
flat.
So
if
let
matches
just
a
single
pattern,
so
here
like
the
we've
got
like
a
result
type
and
so
we're
gonna
match
like
the
okay
pattern,
and
so
if
you've
got
kind
of
okay,
we're
gonna
do
something
with
the
value
we
got
and
it
binds
the
the
variable
I
in
the
same
way
as
match
does,
and
if
it's
not
that,
then
we're
just
going
to
carry
on.
B
Here's
another
somewhat
common
idiom
in
rust,
which
is
actually
more
common
with
result,
type
we're
going
to
call
a
function
again
like
we
had
H
before
and
if
it's
okay,
we're
gonna,
do
something
with
the
variable
I
and
if
there's
an
error,
we're
not
going
to
try
and
handle
it,
we're
just
gonna,
throw
it
again
and
assume
that
I
caller
can
handle
it
in
some
way.
I'm
assuming
the
return
type
of
the
function
here
is
is
result.
Otherwise
this
wouldn't
work
this
one
or
this
one.
Okay,.
B
Okay,
so
like
the,
if
flat
is
kind
of
a
single
keyword
and
then
okay
I
as
a
pattern
and
then
equals
just
as
an
equals,
and
then
we've
got
an
expression
which
will
be
executed
and
then
we
try
and
match
the
result
of
that
expression
against
the
pattern
and
if
it
matches,
then
we
do
the
block.
So
it's
it
has
exactly
the
same
semantics
as
this.
B
Okay,
so
here's
here's
this
other
idiom
where
we
we
are.
We
the
take
the
success
or
we
throw
the
error
and
actually
it's
more
common
to
write
this
like
like,
like
this
and
rust,
where
we're
using
the
kind
of
like
expression
or
inside
version
of
the
match
statement,
and
we
either
binding
into
a
local
variable
if
we
had
success
or
we're
throwing
the
error
to
be
dealt
with
elsewhere,
and
this
is
such
a
common
idiom
in
rust
that
we
have
some
extremely
sweet
syntax
to
deal
with
it,
which
is
this.
B
So
when
you
see
like
this
postfix
question
mark
operator,
that's
basically
doing
exactly
that
match
right.
If
we
it
was
successful,
then
we
keep
the
we
keep,
that
variable
bind
it
into
I
and
then
we
can
do
something
with
it
and
if
there
was
an
error,
we
throw
that
for
our
caller
to
deal
with
okay.
So
this
question
mark.
C
D
B
Okay,
so
repeat
the
question:
what
happens
if
the
return
types
are
different,
so
it
doesn't
matter
what
it
will
do.
Type
adjustment,
yes,
is
the
short
answer:
it
will.
Can
it
doesn't
matter
what
the
tears
and
actually
the
ease
can
be
different
as
well
as
long
as
the
compiler
can
find
a
way
to
convert
one
into
the
other,
and
it's
kind
of
beyond
this
tour
to
talk
about
how
we
do
that,
but
it
can
be
done.
D
E
B
B
We're
not
so
the
unwrapping
kind
of
happens
at
the
patent
level,
so
it's
the
the
unwrapping
is
not
part
of
the
the
whole
match
statement.
The
unwrapping
is
like
because
we're
matching
the
okay
pattern,
then
we're
unlike
by
by
matching
it
we're
kind
of
doing
the
unwrapping
and
we're
left
with
the
I
was
on
the
earth
case.
So
I
probably
should
have
used
the
better.
That's
that's
a
local
variable
called,
not
capital,
e
of
which
is
the
name
of
the
variant,
and
so
there's
no
unwrapping
happening
on
that
case.
B
So
the
question
is
this:
looks
a
little
bit
like
a
macro
shouldn't
there
be
like
an
exclamation
right,
so
the
the
history
of
this
is
it
used
to
be
a
macro.
It
used
to
be
called
tri
exclamation
mark
and
was
was
a
macro
and
we're
on
earth
question
mark
for
reasons
I'll
discuss
kind
of
on
the
next
slide,
and
basically
it
like
it's,
not
a
macro,
and
so
it
doesn't
need
it
and
if
you're
looking
for,
like
all
the
places
a
function
can
return.
B
F
B
Okay,
so
this
is
the
simple
kind
of
syntax
for
question
mark
and
you
often
see
it
in
chains
of
method
calls
or
field
lookups
like
this,
where
you
know,
if
you
did
the
matching
explicitly,
this
would
be
like
I,
don't
know
ten
lines
of
code
and
it'd
be
really
hard
to
follow,
what's
actually
happening
here,
but
in
this
case
you
can
actually
see
quite
clearly.
What's
the
you
know,
what's
the
kind
of
control
flow
what's
happening
here?
It's
just
a
chain
of
method
calls.
B
B
Don't
have
anywhere
near
enough
time
to
cover
them
all
here,
but
you
should
look
at
the
documentation,
I,
think
kind
of
like
mastering
these
things
is
a
really
important
step
to
kind
of,
like
writing
kind
of
clean,
elegant
code
and
rust,
I'm
gonna
that
there's
kind
of
like
a
symmetry
between
the
option
and
result
types
so
I'm
only
going
to
cover
option
but
pretty
much.
Everything
I
cover
here
exist
for
results
as
well,
either
exactly
the
same
or
in
some
variation.
B
So
here's
kind
of
a
common
thing
that
you
often
want
to
do
so.
Sorry,
look
at
the
second
function,
this
kind
of
maybe
add
four,
so
we're
gonna
pass
in
either
an
integer
or
not
an
integer
like
nothing
at
all,
and
if
we
get
the
integer,
then
we
want
to
add
4
to
it
and
then
return
that
and
if
there's
nothing
there,
we're
just
gonna
return,
nothing!
Okay,
so
this
is
kind
of
like
a
really
common
way.
B
E
G
H
B
So
the
question
is
given
that
you
have
liked
this
map
function.
Why
have
the
question
mark
operator
as
well?
It
just
leads
to
like
better
control
flow
like
when
you,
when
you
have
this
really
common
case
of
like
the
chains
like
this
with
the
question
mark.
It's
really
easy
to
read
like
what's
going
on
here,
like
a
set
of
kind
of
like
nested
map
calls
is
just
not
as
clear.
B
No
it's
a
short
answer.
We
don't
have
high
kind
of
tight,
so
the
question
was:
is
there
like
some
kind
of
syntax
for
doing
this
in
general?
I
guess
like
do
syntax
in
Haskell,
and
the
answer
is
no.
We
don't
have
higher
kind
of
types
and
rust.
We
can't
really
express,
like
the
the
concepts
of
kind
of
like
do
in
the
more
general
case.
So
we
have
stuff,
like
the
question
mark
operator
and
functions
as
a
replacement.
B
B
B
We
see
that
we
take
a
function
and
if
you
look
at
the,
where
clause
you
see
the
type
of
that
function,
don't
worry
about
the
details,
but
like
the
the
essential
bit
is
we're
mapping
T
to
you
where
T
is
the
type
parameter
for
the
receiver,
and
you
is
the
type
parameter
of
the
option
that
we
return
so
in
the
example
here
T
and
u
are
the
same
they're,
both
I-32,
but
there's
no
reason
they
have
to
be
the
same.
In
general,.
B
Okay,
so
I
want
to
look
at
some
other
methods
and
I'm
going
to
go
over
there's
a
bit
more
quickly
and
I'm
just
going
to
show
you
the
type
signatures,
so
one
kind
of
intuitive
way
you
can
think
of
optional
result.
Types
is
like
a
like
a
boolean
where,
if
you've
got
saw
more
okay,
it's
true
and
if
you've
got
nothing
or
error,
then
it's
false
with
that
interpretation.
Then
it
makes
sense
to
want
to
and
or
all
these
things
together,
and
indeed
we
have.
B
B
I
should
before
getting
to
this
I
should
introduce
that
they're
like
the
and
and
the
or
are
kind
of,
eager
versions
of
and
and
or,
and
that
there
are
also
kind
of
like
lazy
versions
of
and
and
or
so
and
then,
or
else
you
can
think
of
the
boolean
operations
and
and
all
but
the
short-circuiting
kind
so
and
then
takes
function.
And
if
the
the
receiver
is
none,
we
never
execute
that
function.
But
if
the
receiver
is
some,
then
we
unwrap
the
receiver
pass
it
to
this
function.
B
And
if
that
function
gives
you
some,
then
that's
the
results
of
the
hole
and
then
function
similarly
like
or
else
takes
a
function,
and
if
the
receiver
is
something,
then
it
never
executes
s--.
Whereas
if
it's
nothing,
then
we
ask
you
the
function
and
then
you
can
think
like
and
then
is
exactly
like
mapping,
but
where
the
function
that
we're
mapping
can
actually
return
a
nun
right,
rather
than
always
succeeding
where
we
would
wrap
it
back
up
in
the
map
case
and
then
lets
you
execute
a
function
that
might
return
something.
B
I
might
return
nothing
but
handles,
like
the
nun
case.
To
start
with,
similarly,
or
else
you
can
think
oh
well
or
as
well,
you
can
think
of
being
like
about
having
a
default
value.
So
it's
saying
if,
if
this
is
something,
then
great
I'll,
just
you
keep
using
it.
If
it's,
if
there's
nothing,
there,
then
I'm
going
to
execute
this
function
or
use
this
value
and
and
that's
kind
of
like
the
default
I'm
going
to
going
to
use.
B
So
these
are
both
like
really
common,
really
useful
functions
for
on
the
option
and
result
types
and
there's
this
pattern
that
often
you
have
they're
kind
of
like
eager
and
lazy
versions
where
the
eager
version
takes
of
value
and
the
lazy
version
takes
the
function
that'll
be
executed
if
necessary:
okay,
okay,
before
I
it.
So
this
is
probably
another
good
point
to
ask.
If
people
have
questions
on
on
these
methods,.
B
B
Okay,
cool,
so
another
couple
of
methods,
so
I
said
before
option
and
results
are
fairly
similar
and
it's
often
extremely
common
that
you
will
want
to
convert
between
them,
and
so
there
are
methods
to
convert
from
an
option
to
a
result
and
vice
versa,
so
okay
or
turns
an
option
into
a
result
and
you
the
the
all
bit
is
because
you
have
to
supply
like
the
error
case.
If
it
was,
if
there
was
nothing
there
and
there's
a
there's
like
a
lazy
version.
B
B
Basically,
here
are
two
functions.
These
are
written
kind
of
badly,
so
write
them
really
well.
Is
the
exercise
there's
a
link
in
the
top
right
corner
for
the
documentation?
You
might
find
it
handy
to
look
up
the
the
docs
for
for
option.
In
order
to
do
this,
we
can
figure
figure
this
out
I'm
just
going
to
give
you
a
couple
of
minutes
to
do,
and
if
you
have
any
questions
that
you
along
just
stick
up
your
hand.
B
But
I'm
gonna
interrupt
because
I'm
already
slightly
over
time.
Sorry,
but
I
want
to
go
through
what
we're
what
we've
talked
about
so
I'm
just
going
to
go
through
the
first
function.
First,
so
this,
if
input
it's
none,
returned
none
and
then
unwrap
the
input.
Well,
we
can
do
this
much
quicker
using
a
try
operator.
Sorry,
the
question
mark
operator,
so
that
this
is
exactly
what's
happened
in
this
version.
B
But
if
we
keep
reading
a
little
bit
further
down,
then
we
see
that
like
in
we're,
then
doing
like
an
if
test
and
we're
gonna
return,
none
and
otherwise
we're
gonna
wrap
it
all
back
up
in
a
sum.
So
that
suggests
that
we
can
do
even
better.
We
can
use
the
and
then
function
that
I
talked
about
before,
rather
than
like
the
the
try
operator.
B
So
this
is
doing
like
an
implicit
check
and
whether
it's
some
or
none
and
then
we're
returning
none
if
we're
we're
less
than
zero
and
actually,
if
you're,
using
nightly
rust,
you
can
do
even
better
than
that,
because
there's
a
function
that
hasn't
been
stabilized
in
the
standard
library
yet
called
filter,
which
does
what
and
then
was
doing
like
with
some
or
none
but
then
applies
a
predicate
to
the
value.
If
there
was
something
there
and
effectively
kind
of
like
those
and
then
returns
like
some.
B
Okay,
so
the
second
function
is
a
bit
simpler.
It
just
has
a
match
statement
where
and
it
calls
the
previous
function,
which
returns
an
option
and
it
gives
you
an
okay
result
or
it
gives
you
an
error,
and
this
can
quite
easily
be
mapped
onto
the
okay
or
function
that
we
talked
about
earlier.
This
is
just
converting
from
the
option
type
into
the
result.
Type.
So
does
anyone
have
any
questions
about
the
exercise
before
we
move
on.
B
Okay,
great
so
on
to
iteration
and
iterators,
so
I
want
to
start
again
with
an
example.
In
C
we've
got
a
ping
all
function.
This
is
going
to
take
an
array
of
some
type
foo.
It
also
needs
to
take
the
length
of
that
array.
It's
gonna
iterate
over
that
arrays
and
standard
C
for
loop,
and
then
it's
gonna
index
into
that
array
and
call
some
ping
function
on
every
element
of
the
array.
B
B
B
Hopefully,
they'd
get
caught
in
code
of
view,
but
who
knows,
and
certainly
once
you
start
having
like
nested
iteration
or
you're
iterating
over
multiple
arrays
or
you're,
going
backwards
rather
than
forwards
or
you're
stepping
over
multiple
elements.
At
a
time
it
gets
much
much
easier
to
make
this
kind
of
logic
error.
B
Here's
the
version
in
rust,
so,
hopefully
the
type
looks
kind
of
similar.
Unlike
see
the
type
includes
the
length,
and
so
we
don't
need
to
separately
pass
the
length.
So
that's
one
thing
that
can't
go
wrong:
iterating
over.
It
is
like
a
much
simpler
expression.
It's
a
for-loop,
but
it's
not
like
a
c4
loop,
we're
just
gonna.
This
is
going
to
bind
the
variable
F
to
each
elements
in
Fu's
in
sequence
and
then
we're
gonna
call
this
ping
function
on
it.
B
So
this
is
already
like
much
better.
Hopefully
you
all
agree,
but
actually
it's
kind
of
uncommon
to
even
see
like
four
loops
for
this
kind
of
single
simple
case,
because
there's
a
whole
bunch
of
functions
on
iterators,
just
like
there's
a
whole
bunch
of
functions
on
option
and
result
that
let
you
write
kind
of
like
much
more
succinct
code.
So
here
we
explicitly
have
to
ask
for
an
iterate
over
the
array
using
the
inter
function
and
then
there's
a
for
each
function,
which
just
executes
the
function
for
each
element.
B
B
B
But
what
the
important
thing
is
that
like
iterator,
is
kind
of
like
an
interface
of
which
there
are
many
many
concrete
implementations.
You
may
even
write
your
own,
it's
common
to
write
your
own
in
rust
code
and
that,
for
various
reasons,
that
means
that
actually
looking
at
the
signatures,
these
functions
is
not
very
useful.
So
I'm
going
to
do
this,
all
by
example,
rather
than
by
showing
you
the
signature.
B
Okay,
it's
so
a
vac
and
rust
is
just
a
resizable
array.
So
here
we're
just
going
to
create
our
back
we're
going
to
call
it
iran,
it's
got
an
iterator
and
then
we're
going
to
use
some
functions
so
map
just
like
map
on
option
applies
this
function
to
every
elements
of
the
it's
razor
and
then
gives
you
a
new
iterator
filter
applies
the
predicate
and
if
it's
true,
it
keeps
it
and
if
it's
false
dumps
it.
B
B
Okay,
another
couple
of
functions
this
time
we're
going
to
use
a
for
loop
as
well,
so
it's
actually
pretty
common
to
kind
of
like
gas,
an
iterator
and
manipulate
the
iterator
in
some
way
and
then
use
a
for
loop
to
iterate
over
the
iterator.
If
you
like,
so
we're
going
to
use
the
chain
function,
so
chain
takes
two
iterators
and
change
them
together.
B
So
you
got
a
new
iterator
that
iterates
over
all
the
first
element,
all
the
elements
in
the
first
iterator
and
then
all
the
elements
in
the
second
iterator
enumerate
well
sometimes
I
mean
so
in
the
for
loop.
We
saw
earlier
there's
no
counter
variable.
Sometimes
you
want
a
counter
variable
right.
It's
useful,
so
enumerate
gives
you
a
way
to
give
that
back
so
enumerate,
takes
an
iterator
and
then
gives
you
back
an
iterator
which
is
an
iterator
over
pairs
of
the
counter
variable
and
the
value
from
the
original
iterator.
B
E
B
B
So
we're
going
to
get
a
map
from
the
counter
variables
to
the
values
and
the
fact
that
these
are
two
quite
different.
Things
gives
you
a
hint
that
collect
is
quite
a
smart
little
function
and
exactly
how
it
behaves
depends
on
the
the
type
that
you're
expecting
and
that's
why
we
need
to
put
some
explicit
types
on
the
variable
declarations,
even
though,
usually
in
rust,
we
can
just
infer
these
and
the
the
output
is
going
to
be
like
a
vector
and
the
hash
map
with
these
values.
B
B
So
we
have
this
back
right
and
we've
seen
two
ways
we
can
iterate
over
it
and
I
think
intuitively.
These
are
very
similar.
You
can
see
why
these
might
correspond,
but
it's
kind
of
odd
that
these
are
maybe
not
as
close
as
you
might
be,
expecting
right.
Like
the
in
the
first
case,
we
have
to
explicitly
get
an
iterator
and
in
the
second
case
we
done,
but
we
do
have
an
extra
ampersand
in
there.
B
B
Okay,
so,
let's
start
at
the
beginning,
like
this,
this
vak
macro
this
creating
a
vector
for
us.
The
type
of
that
is
capital
v
vac.
This
is
not
kind
of
an
iterator,
which
is
why,
in
the
first
expression,
you
have
to
call
it,
sir,
to
actually
get
an
iterator,
but
the
vac
type
does
implement
into
iterator,
which
is
a
trait
and
we'll
see
what
that
gives
you
in
a
second.
B
But
actually
there
are
multiple
implementations,
so
there's
actually
an
implementation
for
just
vac,
which
gives
you
an
iterator
over
the
values,
in
fact,
and
as
an
iterator
for
a
reference
to
vac
which
an
iterator
over
a
reference
to
each
value
in
the
vac
and
seeing
us
in
our
for
loop.
We,
we
don't
want
to
kind
of
use
up
that
vac,
we
won't
have
access
to
it
afterwards.
B
It's
it's
pretty
common
that
you
want
to
get
the
the
references
and
so
that
ampersand
before
the
vac
ensures
that
we
get
the
the
implementation
of
into
iterator,
which
is
going
to
give
an
iterator
over
the
references
rather
than
values
and
what
is
into
iterator.
Do
into
iterator
house
like
a
single
function,
which
just
turns
the
receiver
I
forgot
the
South
bit.
Sorry
that
should
be
in
to
iterate
sort
of
intuitive
self,
and
so
it
turns
that
receiver
into
an
iterator
and
then
the
iterator
trait
it
has
a
lot
of
functions.
B
I've
been
talking
about
some
of
them
there's
an
awful
lot
more,
but
the
one
that
you
actually
the
really
kind
of
like
key
function
is
this
next
function
and
it
returns
an
option.
We've
seen
option
already
and
what
happens
is
if
the
iterator
has
been
used
up.
We
return
none
because
there's
nothing
left
to
give.
B
So
this
is
essentially
what
the
for
code
for
loop
boils
down
to.
We
run
into
it
so
to
get
ourselves
an
iterator,
and
then
we
repeatedly
call
it
a
dot
next
and
whilst
that
returns
a
some
variant,
we
execute
the
body
of
the
the
loop
and
if
it
returns
none,
then
we
stop,
but
that's
not
the
end
of
the
story
as
we
before
with
flats.
Then
you
can
rewrite
that
with
match.
B
So
similarly,
like
with
violet,
we
can
reduce
this
to
even
more
primitive
constructs,
but
you
need
to
know
that
their
exists
loop,
which
takes
no
arguments
and
just
loops
forever.
It's
an
infinite
loop
and
also
the
rust,
has
a
break
statement
and
so
I'm
going
to
get
you
all
to
do
this
as
an
exercise
which
is.
Can
you
write
the
this
while
lat
loop
that
we
had
before
to
do
iteration
using
these
more
basic
constructs?
So
just
give
you
a
couple
of
minutes
to
do
that.
B
B
B
So
a
for
loop
works
over
an
iterator,
it
takes
any
any
iterator
and
then
by
using
kind
of
wild
lap,
I've
shown
you
how
explicitly
we're
kind
of
getting
that
iterator
and
then
iterating
over
it
and
then
shown
how
like,
while
that
itself
is,
can
be
thought
of
in
even
lower
level
terms.
The
second
part
of
it
is
probably
not
too
useful,
but
it
is
often
useful
in
your
Rusco
to
be
able
to
use
while
lat
for
kind
of
various
complex
kinds
of
iterations.
So
that's
really
nice
things
kind
of
having
you
in
your
toolbox.
B
B
B
So
my
my
my
first
and
most
important
point
I,
think,
is
that
you
should
think
of
error
handling
as
an
architectural
concern
in
your
program
from
earlier.
That
means
you
have
to
think
about
it
really
early
in
the
design
process.
So
when
you're
thinking
you
know,
should
this
app
run
on
a
server
or
should
it
have
a
GUI,
or
should
it
have
like
a
restful
api
like
when
you're
making
that
level
of
architectural
decisions
you
also
want
to
be
thinking
about.
B
B
The
first
option
is
that
you're
able
to
recover
somehow
so
often
a
way
to
recover
is
like
you
can
pick
an
appropriate
default
value.
So
you
know
that
if
this
thing
succeeded,
you've
got
a
value,
and
if
it
didn't
succeed,
then
there's
a
default
value.
I
can
use
there's
if
you
were
paying
attention
earlier.
You
could
write
this
more
succinctly
using
like
an
okay
or
function,
sorry
unwrap
or
function.
B
You'd,
like
it
might
at
some
points
in
your
program,
be
appropriate
to
alert
the
the
user
that
there
has
been
an
error,
and
maybe
the
error,
the
user
can
give
you
some
input
to
help
recover
from
that.
The
mistake
is,
and
presumably
what
is
going
on
here
is
that,
like
your
actual
arrow
types
are
internal
for
the
to
the
program
it
you
should
almost
never
actually
show
your
internal
arrow
types
to
the
user.
This
is
almost
certainly
going
to
give
a
bad
user
experience.
B
B
Okay,
it's
option.
Number
two
is
to
just
wreath
row.
So
we've
seen
this
before
we've
seen.
This
is
what
the
question
mark
operator
is
for.
This
is
like
in
I
mean
this
particular
function
and
I.
Don't
know
how
to
recover
from
this
era,
so
I'm
going
to
just
throw
it
up
the
stack
and
hope
that
my
caller
or
their
caller
and
so
on
will
be
able
to
handle
it.
Oh
yeah,
that's
the
yeah
question
mark
operator.
The
third
option
is
that
you
can
panic.
B
So
a
panic
is
a
controlled
crash
in
in
rust,
so
it
crashes
the
current
threat,
but
it
does
so
by
it
does
so
kind
of
like
cleanly
by
unwinding
the
stack,
so
destructors
will
get
called,
and
this
isn't
a
seg
fault.
It's
not
exploitable
and
you
can
actually
catch
this
panic
or
you
can
catch
it
at
thread
boundaries.
It's
you,
you
don't
net.
B
So
these
are
your
three
options,
so
the
first
two
options
are
like
actual
error
handling,
and
the
third
option
is
not
error
handling.
Basically-
and
it's
acceptable
to
do
that-
sometimes
like
if
you're
writing
like
a
very
experimental
bit
of
code-
then
maybe
it's
okay,
but
really
we
should
be
doing
one
of
the
first
two
and
so
the
obvious
question
it
becomes
like
which
of
those
two
should
I
do
so.
B
An
intuition
I
want
to
try
and
get
across
is
about
kind
of
the
modularity
of
error,
handling
and
so
I
want
it,
like
think
of
think
of
your
code
in
terms
of
kind
of
error
modules.
Now
these
are
not
like.
This
is
not
a
rust
concept.
This
is
not
like
something
that's
actually
explicit
in
your
code
and
an
error.
Module
could
be
smaller
than
a
rust
module,
but
more
commonly
it
would
be
bigger
than
a
rusts
module.
B
B
So
to
give
you
a
little
example
of
this,
like
imagine
that
you're
doing
some
network
I/o,
okay,
so
within
your
error
module,
then
this
might
be
as
small
as
a
single
function
right
like
you're
gonna,
try
to
use
this
connection
and
maybe
you'll
get
like
a
woodblock
error
back
from
your
system
call
or
maybe
you've
got
a.
You
know,
connection
busy
kind
of
error.
Well,
you
can
kind
of
like
recover
from
that
in
a
very
context-sensitive
way.
B
You
can
just
sleep
and
then
try
again
right,
but
if
none
of
this,
if
this
doesn't
work,
then
at
some
point,
you've
got
to
kind
of
tell
your
caller
that,
like
you,
failed
to
do
this
I/o
and
for
them
like
whether
you
got
like
you
know,
couldn't
get
the
connection
or
whether
you
got
like
a
wood
block
kind
of
error.
This
is
useless
right,
but
they
might
want
to
know.
Well,
there
was
an
I/o
error
trying
to
connect
to
this
particular
IP
address.
B
Okay,
so
that's
kind
of
a
difference
between
like
a
kind
of
internal
kind
of
error
in
an
external
error
and
where
you
want
to
convert
from
one
to
the
other,
is
kind
of
like
the
boundary
of
your
error,
module
and
generally
like
within
an
error
module
you
or
a
common
pattern
for
error
handling.
Is
that
you
always
throw
re,
throw
your
error
when
you're
inside
the
error
module
and
then
you
have
in
US
and
the
kind
of
boundary
of
this
module.
B
You
have
like
a
single
place
where
you
try
and
do
recovery,
okay,
and
if
that
recovery
fails,
then
you're
going
to
convert
the
internal
error
into
a
kind
of
public
facing
error.
And
so
that's
kind
of
like
the
the
intuition
that
I
kind
of
pushes
to
knowing,
when
you
should
kind
of
like
throttle
versus
recover,
is
kind
of
getting
this
intuition
of
kind
of,
like
modular
error,
stuff.
B
So
the
question
is:
how
do
you
deal
with
out-of-bounds
accesses
in
arrays
and
so
I?
So
bounds
checking
is
done
at
runtime
and
rust
and
it
depends
like
you
can
index
into
an
array
in
different
rays.
The
pen
which
depend
will
give
you
different
ways
of
getting
the
different
ways
of
handling
the
out-of-bounds
error.
So
if
you
just
use
like
the
square
bracket
operators
and
you're
out
of
bounds,
then
that's
going
to
panic,
which
you
don't
want
to
happen.
B
So
if
you
think
that
you
might
possibly
access
out
of
bounds,
then
you
should
not
be
using
those
indexing
operations
and
you
should
use
an
explicit
gap
which
returns
an
option.
I
think
either
an
option
or
result
bshorts
an
option,
and
then
you
can
like
explicitly
check
or
you
can
use
the
various
functions
we
talked
about
on
the
first
half
to
say:
if
this
is
a.
If
there
was
something
there
then
do
something,
and
if
it
was
none
than
recover
in
some
way,
so
that
yeah
and
then
how
you
do
it
is
up
to
you.
B
Okay,
so
if
you
remember
the
result,
type
has
two
type
parameters:
it
has
the
value
type
that
we
haven't
had
success
and
how's
the
arrow
type,
hopefully
what
value
type
you
know
that
I
don't
need
to
talk
about
that.
It's
obviously
just
what
you're
doing
and
your
function
that's
going
to
take
the
value
type.
What
should
you
use
for
your
arrow
type?
This
is
kind
of
a
big
question,
but
first
of
all
result
type.
I
mentioned
earlier:
it's
not
magic.
B
It's
not
built
into
the
language,
it's
just
part
of
the
standard
library
and
it's
actually
totally
possible
to
use
your
own
result
type,
but
don't
do
that.
There's
like
there's
very
rarely
any
reason
you
would
want
to
do
that
unless
you
are
reimplemented
some
really
kind
of
like
fundamental
library,
stuff
I
can't
imagine
a
scenario
where
it
makes
sense
to
implement
your
own
result.
Type.
On
the
other
hand,
aliasing
the
result
type
is
almost
always
a
good
idea.
B
No,
you
can
think
of
like
the
an
alias
like
this
being
resolved.
Oh
sorry,
the
question
was:
does
this
prevent
kind
of
implicit
coercion
between
your
results?
I
found,
thus
general
results.
I've
announcer
is
no,
and
you
probably
don't
want
that,
like
you
want
to
be,
you
want
to
just
be
using
the
result.
Type
you
want
to
be
able
to
in
gonna
interact
with
the
rest
of
the
ecosystem
by
doing
that.
B
You
you
can,
oh
sorry,
so
the
question
is,
there
is
an
option
for
not
allowing
the
coercion.
So
I
should
clarify
that.
There's
it's
not
a
coercion
like
the
aliasing
is
happens
or
the
D
aliasing
I
guess
happens
very
early
in
compilation.
So
as
far
as
the
compiler
is
concerned,
these
are
the
same
types.
It's
not
that
it's
being
coerced
from
one
type
to
another.
B
It's
the
one
option.
Is
you
use
something
really
simple
as
your
arrow
type,
so
you
could
not
use
anything
at
all
if
you're,
if
this
is
really
early
days
code,
maybe
you
just
want
you
know
it's
it's
nice
to
be
able
to
throw
errors,
but
there's
maybe
no
relevant
information
that
you
can
get
in
there,
and
so
you
can
actually
just
use
the
void
type,
which
is
just
the
the
empty
parens
and
there's
no
information
at
all.
B
You
could
use
error
codes
like
you
know,
one
two,
three
or
error
codes:
that's
not
very
user-friendly,
but
it's
fine
for
experimental
programming.
It's
pretty
common,
see
people
use
strings
like
a
Gaines.
It's
not
something
I
recommend
in
kind
of
production
code,
but
it's
great
when
you're
experimenting
it's
very
lightweight
and
it
lets
you
debug.
It.
B
So,
if
you're
using
a
single
one,
it's
quite
often
to
you
common
to
use
an
enum.
So
here
we're
just
using
the
single
enum
type
as
our
arrow
type
and
every
possible
kind
of
error
gets
a
different
variant
and
you
know
any
data
you
want
is
carried
along
with
that.
So
here
we've
got
like
a
server
error,
user
error,
connection
error,
whatever
else.
Alternatively,
you
can
use
multiple
different
arrow
types,
so
different
functions
would
return
different,
throw
different
kinds
of
errors.
B
So
here
we've
got
like
a
struct
for
a
server
error,
and
that
has
like
quite
different
data
from
all
the
other
kind
of
errors
that
we
might
have
you
in
the
end.
You're
gonna
have
to
deal
with
multiple
error
types
anyway,
because
the
standard
library
is
full
of
different
ones
with
its
own
kind.
So
you're
gonna
have
to
accommodate
that.
B
This
is
a
library
for
error
handling
and
it
is
on
the
road
to
being
part
of
the
standard
library,
and
hopefully
it's
gonna
be
widely
used
in
the
ecosystems.
So
it's
it
gives
your
your
librarian
advantage.
So
it
lets
you
handle
kind
of
lots
of
different
kinds
of
arrow
types.
Very
clearly
it
lets
you
change
a
rose
together
so
often
you'll
have
an
arrow
that
has
like
an
underlying
calls
and
it
lets
you
deal
with
that
kind
of
like
chain
of
causes
and
it'll.
B
Allow
you
to
have
like
back
traces
when
you,
when
these
kind
of
errors
get
surfaced
and
it
lets
you
interoperate
very
cleanly
with
the
rest
of
the
rust
ecosystem.
Oh
and
it's
extremely
easy
to
use
okay
like
if
you
have
like.
If
this
is
your
error
in
Unum,
then
you
can
opt
into
using
failure.
Just
with
this
very
small
derive
fail,
attribute
question.
B
Question
was,
it
seems,
there's
no
era
hierarchy.
Is
there
a
reason
and
we
get
I
mean
we
generally
don't
have
hierarchies
and
rust
life,
there's
no
inheritance
between
data
types.
So
there's
no
kind
of
obvious
weights
that
even
have
such
a
thing
yeah
is
the
is
the
short
answer
it
just
doesn't
kind
of
like
fit
with
the
rust
philosophy
of
the
way
we
do
things
to
do.
That.
B
Okay,
so
what
should
I
do
like
you're
your
programmer
like
what
should
I
do
like
what
kind
of
approach
does
have
error
handling?
So
the
first
question
is:
are
you
writing
a
library
or
are
you
writing
an
application
if
you're
running
a
library?
Basically
you
have
to
do
everything
properly.
If
you
want
other
people
to
use
your
library
they're
going
to
expect
it
to
have
proper
error
handling,
so
you
need
to
use
your
own
arrow
type,
don't
try
and
use
like
a
string
or
an
error
code,
or
something
like
a
Paik
like
that.
B
You
need
to
think
you
need
to
like
consider
like
the
arrow
boundaries
that
I
was
talking
about
earlier,
and
you
should
probably
use
the
failure
library
if
you're,
using
an
application.
If
you're
producing
an
application,
then
you
want
to
think
about
what
kind
of
application
that
is,
if
you're,
writing
a
script
that
you're
only
going
to
use
once
and
throw
away.
B
B
If
you're
running
like
very
experimental
prototype
software,
then
you
probably
want
to
have
some
quite
lightweight
error
handling.
So
you
know
something
like
using
a
string
as
an
error
message.
It's
quite
a
good
idea
and
if
you're
putting
something
in
production,
then
you
need
to
do
like
with
a
library.
You
need
to
have
like
a
really
kind
of
like
full
error.
Handling
thing.
B
B
Yes,
sorry,
the
question
was:
can
you
write
a
trait
which
relies
on
things
having
other
traits?
The
answer
is
yes
and
but
stick
around,
and
we
can
talk
about
it
rather
than
going
into
it
right
now.
Cool,
okay,
so
I
have
vastly
underestimated
how
long
this
talk
would
take
and
I
only
have
seven
more
minutes,
which
is
probably
not
enough
time
to
cover
even
a
half
of
one
of
the
two
sections
that
I
have
left
so
I'm
happy
to
kind
of
stick
around,
but
I
think
they
need
to
stop
video
recording
at
some
point.
G
B
A
E
B
Thanks
so
I
wrecked,
so
I
have
two
sections
remaining.
One
is
on
ownership
and
using
that
for
as
a
kind
of
principle
of
designing
your
us
programs
and
a
second
section
is
on
traits
as
an
abstraction
mechanism
in
rust,
I
figure
even
going
into
the
coffee
break
that
we
only
have
time
for
one
of
those.
So
does
anybody
have
a
preference
so
raise
your
hands?
B
If
you'd
rather
hear
about
ownership,
it's
a
few
and
raise
your
hands
if
you'd
rather
hear
about
traits
I
think
the
traits
have
it
sorry,
ownership,
folk,
I'm,
happy
so
I
think
we'll
be
done.
Hopefully
early
in
the
coffee
break
and
I'm
happy,
it's
gonna
stick
around
and
talk
about
ownership.
If
anyone
wants
to
hear
about
that.
B
So
that
was
everything
you
missed.
Okay,
so
traits
traits
are
the
primary
abstraction
mechanism
in
rust.
So
if
you're
coming
from
kind
of
like
any
other
well
many
other
languages,
there's
a
quite
kind
of
novel
abstraction
mechanism,
so
rust
is
in
the
large
at
least
is
a
very
object-oriented
language.
B
But
it's
certainly
not
a
class
or
incited
language,
and
the
way
that
you
use
traits
is
very
different
from
the
way
that
you
would
use
classes
and
even
if
you
think,
of
they're
more
like
interfaces
than
classes
which
they
are,
that
I
think
designing
with
traits
is
very
different.
So
the
basic
syntax
for
using
traits
is
pretty
simple.
You
declare
a
trait
using
the
trait
keyword
you
in
the
ellipses,
where
I've
alighted
the
code.
B
So
I'll
do
a
kind
of
little
comparison
between
classes
and
traits,
so
classes
are
a
way
to
share
both
behavior
and
data
okay.
So
when
you
inherit
from
a
class,
you
inherit
the
data,
that's
in
the
super
class
and
you
inherit
the
the
behavior,
the
methods
that
are
there
as
well,
whereas
traits
are
only
about
sharing
behavior.
You
cannot
like
share
data
in
a
trait.
That's
part
of
the
concrete
data
types
that
russa
provides.
B
Classes
are
mostly
hierarchical.
They
got
a
question
earlier
about
kind
of
like
why
arrows
on
hierarchical
in
rust,
and
we
don't
really
have
like
the
kind
of
hierarchies
that
you
get
all
over
the
place.
You
know
in
most
other
languages,
so
just
like
it's
actually
possible
in
classes
that
you
can
have
multiple
inheritance
and
therefore
you
have
like
a
dag
of
inheritance
rather
than
a
tree.
It
is
possible
that
you
have
some
kind
of
inheritance
between
between
traits
and
rust,
but
it's
the
exception
rather
than
the
rule,
and
in
general
you
compose
behavior
without
inheritance.
B
B
Traits
are
also
really
important
in
rust,
because
they're
the
way
that
user-defined
types
can
interact
with
the
language
itself.
Okay,
so
we
saw
earlier
this
iterates
a
trait,
and
we
saw
the
for
loop,
which
is
part
of
the
language
and
by
implementing
the
iterator
trait.
You
allow
your
own,
like
user
types,
to
be
iterated
over
using
the
for
loop.
B
Similarly,
there
is
a
D
ref
trait,
which
allows
your
user
defined
types
to
act
like
pointers
and
to
to
take
part
in
kind
of
dereferencing
that
happens
with
the
dot
operator
and
elsewhere,
and
then
there's
the
index
trait,
which
allows
your
user
defined
types
to
act
like
an
array
and
be
able
to
be
indexed
into
with
the
square
bracket
operators
and
traits
also
essential
to
the
safety
guarantees
and
rust.
A
really
good
example
of
this
is
the
send
and
sync
traits,
and
these
actually
don't
have
any
methods
in
them
at
all.
B
B
Are
you
restricted
in
way
you
can
implement
a
trait
for
a
concrete
data
type.
So
the
answer
is
yes,
so
sir
rust
is
structured
into
crates,
which
are
kind
of
like
the
compilation
unit
and
similar
to
a
like.
It's
basically
a
conflict,
a
library
so
either
the
traits
or
the
concrete
type
must
be
defined
in
a
crate
within
with
the
implementation.
B
So
you
can
input
a
few
define
the
trade,
so
you
can
input
a
few,
define
the
concrete
data
or
both,
of
course,
but
you
can't
in
pull,
if
you
don't
know
either
and
then
there's
also
a
really
sorry
I
should
say,
really
complex,
there's
a
somewhat
complex
set
of
rules
around
coherence
which
dictate
like
what
kind
of
implementations
you
can
have
certain
data
types
but
yeah.
We
we
prevent
and
I'll
do
it.
The
orphan
problem.
B
E
B
B
It's
tenting
I
mean
you
can
write
Russ
code
without
any
traits
and
especially
if
you
come
for
so
you
can
write
methods
in
what
we
call
an
inherent
imple,
which
is
an
impulse
rate
at
all.
So
these
are
just
methods
that
are
available
on
the
data
type
without
without
naming
a
trait
and
if
you're
used
to
kind
of
like
the
LOA
way
of
coding.
This
connect,
you
can
feel
quite
a
natural
way.
B
It
means
you
define
all
your
methods
on
the
concrete
data
type,
so
it's
just
combining
the
the
data
and
the
behavior,
but
you
should
probably
avoid
doing
that.
You
should
use
more
traits,
so
by
doing
so,
like
you
enable
like
much
better
testing
if
you're,
if
you
take
a
trait
rather
than
a
concrete
type,
it's
really
easy
to
mock
out
the
the
concrete
type
and
have
like
mock.
You
have
like
a
mock
object
for
testing.
It
makes
your
code
much
more
extensible.
B
This
is
especially
important
if
you're
writing
a
library,
if
you're
always
expecting
a
concrete
type.
Your
code
is
not
very
flexible,
whereas
if
you
have
generic
code,
that'll
accept
any
type
that
implements
a
trait
that's
much
more
flexible
and
much
more
extensible
and
that's
encouraging.
Like
reuse
of
your
code,
it
also
tends
to
lead
to
a
cleaner
design,
like
you
can
think
of
the
traits
as
kind
of
document
self-documenting
code.
It
tells
you
what
what
methods
are
closely
associated
with
each
other.
B
It
tells
you
like
what
what
the
kind
of
like
effect
of
having
all
these
methods
is
and
and
and
so
on
and
so
forth.
So
it
leads
to
just
generally
kind
of
like
by
using
many
using
more
traits
you
kind
of
end
up
with
a
cleaner,
more
elegant
design,
usually
but
there's
always
a
limit
as
with
any
abstraction
mechanism.
B
It's
really
easy
to
kind
of
go
overboard
and
you
know
have
the
equivalents
of
a
kind
of
you
know:
enterprise
javabean
type
situations,
so
you
know
I
appreciate
the
the
trade-offs
around
abstraction
and
it's
pretty
easy
to
kind
of
factor
out,
trait
sort
of
split
traits
up
and
so
forth,
so
keep
revisiting
refactoring
your
code
to
to
make
more
traits.
So
what
makes
a
good
trait
it
should
be
small
some
traits,
as
I
said,
have
no
methods
at
all.
B
It's
really
common
for
the
traits
only
have
a
single
method
for
traits
with
more
complex
functionality
like
three
four
methods
super
common,
it's
really
rare
to
have
like
a
lot
of
methods.
If
you
have
like
you
know,
pages
full
of
methods,
you
probably
want
to
refactor
that's
kind
of
you,
you
having
more
of
a
kind
of
class
design
mindset
there
and
they
should
be
independent,
so
don't
make
them
too
small
if
every
time
you're
using
one
trait
you're,
also
using
another
one,
they're,
probably
too
tightly
coupled
and
you
want
to
either
merge
them
or
otherwise.
B
So
if
you've
got
like
a
gasser
or
set
of
function,
that's
probably
better
off
as
a
inherent
in
on
a
is
an
inherent
method.
If
you've
got
something
very
closely
tied
to
the
implementation,
the
same,
if
you've
got
behavior,
that's
could
be
specified
generically
or
that
constitutes
an
interface.
Then
that's
something
that
you
should
factor
out
into
a
trait,
so
hopefully
I
have
enough.
So
this
is
an
example
that
I
would
have
introduced
in
the
ownership
section.
B
I,
probably
don't
even
have
the
time
to
introduce
it
properly
here
right
now,
but
on
the
right
hand,
side,
here's
a
set
of
methods
that
I
might
want
on
this
kind
of
abstract
ship.
So
chunk
is
an
abstraction
of
some
memory
being
managed.
So
we've
got
empty
to
create
a
new
empty
chunk.
We've
got
two
string
which
gives
a
string
representation
of
a
chunk.
We've
got
a
debug
string
which
does
the
same
thing,
but
for
debugging
for
a
developer
rather
than
a
user.
B
We've
got
get
buffer
to
get
like
the
underlying
memory
as
a
as
a
as
an
array
of
bytes
and
the
size
of
that
buffer
and
the
potential
capacity
that
we
have
that
this
would
be
not
a
great
way
to
design
this
code.
It
would
be
better
to
make
this
some
trait.
So
first
of
all,
we're
going
to
use
some
traits
from
the
standard
library
default
is
a
trait
that
says.
B
I
can
create
a
default
object,
and
in
this
case
that
would
be
like
an
empty
chunk
display
and
debugger
ways
to
convert
an
object
into
a
string
representation
aimed
for
being
a
user
facing
string
and
a
developer
facing
string,
and
then
we're
gonna
create
our
own
trait
buffer,
which
is
the
kind
of
collection
of
methods
that
we
might
want
for
any
kind
of
buffer
provider.
And
then
that
would
let
us,
for
example,
have
a
mock
buffer
for
testing.
That's
always
going
to
return
zero
or
something
like
that.
B
Okay,
so
I've
really
just
skimmed
the
surface
of
traits.
It's
a
really
big
topic
and
rust.
There
is
like
a
huge
number
of
like
little
features
around
traits
in
the
language
that
that
let
you
do
various
things.
It's
a
good,
really
good
idea
to
kind
of
like
read
up
on
this
stuff,
and
you
know
it's
a
great
way.
It's
kind
of
like
improve
your
design
and
make
you
a
better
programmer
and
I
think
like
the
best
way
to
do.
That
is
to
look
at
some
examples.
B
B
And
the
the
the
traits
often
correspond
to
something
that,
like
a
web
developer,
would
know
about,
whereas,
like
the
concrete
data
is
kind
of
the
internal
structures,
chalk
is
an
implementation
of
the
trait
system,
but
this
uses
a
traits
for
everything
and
it's
great
to
see
like
how
that
kind
of
like
really
almost
an
overuse
of
traits
actually
leads
to
a
really
great
design
and
Tokyo
is
an
async
IO
library
for
rust
and
is
great.
If
you
really
want
to
like
blow
your
mind
about
traits
I
mean
we
told
stop
his
summary.