►
Description
PDXRust
More on http://www.meetup.com/PDXRust/events/232597522/
Help us caption & translate this video!
http://amara.org/v/2Fi1/
A
A
A
Okay,
so
to
those
of
you
who
are
already
rust,
programmers
which
here
I
think
will
be
most
of
you
probably
I-
think
that
design
pans
a
great
way
about
communicating
kind
of
the
tribal
knowledge
that's
in
the
rust
community.
So
we
have,
we
have
a
think,
really
great
documentation
for
people
wanting
to
learn
rust
for
for
rust
beginners.
We
also
have
some
really
great
kind
of
in-depth
kind
of
documentation,
like
blog
posts,
about
really
specific
language
features,
going
really
deep
into
the
mechanics
of
this,
but
there's
kind
of
reference
material.
A
A
So
I
started
a
repository.
I'll
give
you
the
URL
at
the
end
of
the
talk,
and
that
was
meant
to
become
like
a
catalog
of
design
patterns
and
rust
and
I'm
going
to
go
over
a
few
of
those
today.
But
there's
there's
more
online
and
I
hope
that
people
will
help
me
fill
that
out
even
more
and
make
it
like
a
better
resource
going
to
start
something
really
simple,
which
is
the
the
constructor
idiom
which
very
basic
we've
got
want
to
construct.
A
Some
data
who's
got
a
struct
foo
and
you
want
to
create
a
new
one
and,
of
course,
you've
got
struck.
Literal
syntax,
but
a
little
bit
boilerplate
is
so
you
can
make
it
a
little
bit
simpler
by
using
a
constructor
function
and
we
have
this
convention,
but
you
call
that
new
and
you
make
that
an
associated
function
or
static
method
on
the
the
datatype
foo.
You
can
imagine
how
you
would
call
this
in
this
case.
It's
not
really
doing
much
use
that's
very
useful,
but
in
real
life
you
can
initialize
private
variables.
A
A
But
that's
not
the
interesting
bit
the
interesting
bit
is
that
once
we've
got
our
plain,
boring
food
builder,
we
can
call
a
series
of
methods
on
that
object
to
set
up
the
what
will
eventually
turn
into
our
food,
and
we
call
the
finalize
method
to
turn
the
food
builder
into
a
foo.
And
here
this
is
just
very
simple
example:
right:
we've
we've
just
got
methods
that
look
like
the
field
and
we've
initialized
into
some
values.
This
is
not
a
great
use
to
be
honest
right.
A
You
could
do
this
manually
much
better,
but
there's
no
limit
to
what
you
can
do.
You
can
do
some
computation.
You
can
make
sure
like
orthogonal
features,
work
together
in
the
correct
way
and
all
all
kinds
of
stuff,
and
the
nice
thing
is
that
you
avoid
the
combinatorial
explosion
of
having
constructor
functions
before
I
go
on
that's
kind
of
like
the
the
basics
of
the
talk.
If
any
questions
suffer.
B
A
I,
you
only
need
one
builder,
but
the
Builder
can
have
you
know
and
our
methods
on
it
and
you
get
kind
of
two
to
the
end
or
what
and
to
chat
like
to
even
think
about
math.
So
you're
not
I
mean
you
get
like
all
the
possibilities,
with
only
the
certain
number
of
functions
rather
than
having
to
have
like
a
factorial
or
whatever.
It
is
number
of
functions.
A
That
you
can
call
so,
rather
than
so,
you
can
imagine
for
this.
We
just
have
two
functions:
F
and
G.
What,
if
wanted
to
have
possibilities
way?
You
take
the
default
of
app
and
supplier
G.
You
take
two
defaults,
you
take
it
to
both
genes
by
the
app
and
you
take
field
versions
of
F
and
G.
You
need
for
constructors,
so
you
get
away
with
two
functions
rather
than
four
and
we
have
three.
A
Is
where
you've
got
a
collection?
This
example
going
to
use
a
hash
map
and
it's
pretty
common
that
you
want
to
kind
of
accumulate
a
bunch
of
data
into
your
hash
map,
so
you're,
just
like
counting
the
number
of
occurrences
of
some
key,
so
we're
going
to
iterate
over
a
whole
bunch
of
keys
and
if
it's
in
the
hash
map
we're
going
to
increment
the
value,
listen
hash
map.
If
it's
not
we're
going
to
insert
one
because
our
first
time,
we've
we've
called
it
now.
A
This
is
kind
of
ugly
code
right,
it's
ugly,
because
it's
five
lines
to
do
a
really
simple,
repetitive
operation
and
it's
ugly,
because
it's
inefficient,
like
you,
have
to
actually
look
up
in
the
hash
map
twice
for
either
branch
right.
You
have
to
first
check
whether
the
key
is
in
there.
Then
you
branch
on
that
and
then
you
like,
have
to
look
up
again
to
find
the
place
in
the
hash
map
for
insert
or
you
find
the
mutable
reference
in
the
hash
map,
so
either.
A
A
Calm
down,
we
have
a
much
better
solution,
so
it's
called
the
entry
pattern.
So
here
you
get
a
single
function
on
hash
map
called
entry.
We
provide
the
cat
key,
which
is
K
and
it
returns
an
entry
and
an
entry
is
simply
an
enum
and
it
tells
you
you
know.
Is
you
know
this,
this
hypothetical
slot
in
the
hash
map?
Is
it.
A
It
vacant
and
then
just
like
any
other
enum,
we
can
match
that
and
if
it's
occupied
we
can
get
the
value,
that's
there.
We
can
add
one
to
it
and
if
it's
not,
we
can
insert
one.
So
this
is
doing
just
what
we
did
at
the
beginning,
except
this
time
it's
efficient
because
we're
only
doing
one
lookup,
not
two
right.
We
go.
Do
one
look
up
with
the
entry.
The
entry
saves,
the
points
are
into
the
hashmap
and
and
then
we
can
just
use
that
pointer
again
without
having
to
look
it
up
the
game.
A
C
B
A
Is
there
is
a
method
that
we
implement
on
the
entry
called
an
or
insert,
and
if
there's
something
that-
and
it
just
gives
you
back
a
reference
to
it-
immutable
rankings
to
it
and
we
can
add
one
and
if
there's
not
something
bad
and
it
initializes
it
with
the
value
will
be
provided
in
this
case
zero
again
round
one.
We
end
up
with
what
we
had
before
so
now.
We've
got
a
nice
solution
right.
This
is
efficient
with
still
only
doing
one
lookup
and
it's
short,
it's
one
expression
right.
So
you
know
this
is
I.
A
Think
just
pure
wind
we've
got
this
this
pattern
and
if
you're
a
C
programmer
you're
like
well,
this
is
beautiful,
but
I'm,
also
shaking
in
fear
because
you've
what
you've
given
me
as
you've,
given
me
a
reference
into
the
hashmap
right,
like
what
happens
if
the
hashmap
disappears
and
you're
left,
with
a
reference
into
where
the
hashmap
used
to
be,
and
then
you
try
and
insert
that
right.
This
would
be
a
disaster
now,
luckily,
like
rust,
won't
let
you
do
this
right
and
the
way
it
doesn't.
A
Let
you
do
this
it
because
of
the
ownership
system.
We
use
some
lifetime
jiggery-pokery
yeah,
so
the
entry
that
I
showed
you
for
was
not
quite
what
the
ante
really
looks
like
it's
still
modify,
but
there
if
you
look
site
but
yeah,
so
it
takes
a
lifetime
for
ammeter
and
when
you
get
an
entry
out
of
the
hashmap.
This
is
there's
a
little
bit
of
sugar
here.
A
What's
really
going
on,
is
this
right
and
Russ
lets
you
bolide
the
the
generic
lifetimes,
but
under
the
colors
the
compiler
is
tracking
them
and
you
get
an
explicit
lifetime
on
self,
which
is
the
hash
map
and
that
lifetime
is
propagated
into
the
entry
and
then
the
compiler
ensures
that
the
hash
map
out
lives
to
the
entry.
So
if
you
still
have
a
reference
to
that
entry,
the
compiler
guarantees
that
the
hash
map
still
exists.
Okay
and
so
like
here,
we
this
pattern,
I
said-
is
one
of
my
favorites,
because
it
written
straight
on
rust.
A
A
D
A
B
B
A
So
this
is
very
convenient
and
we
we
use
this
pattern.
The
wall
in
rust,
as
well
accepted
rust,
can
be
a
bit
safer
as
I'm
about
to
show
you
and
we
can
kind
of
extend
using
this
insert
using
it
for
all
kinds
of
guarding
operations.
So
the
example
I
want
to
show
you
is
the
rust
mutex.
This
is
a
slightly
simplified
version
of
how
the
standard
library
mutex
works.
So
you
first
of
all,
you've
got
the
musics
itself
guarding
some
bit
of
data
type
T,
and
then
we
thought
the
lock
method.
A
So
when
you
want
to
use
a
map
of
the
days
of
guarded
brother
musics,
you
have
to
lock
it
and
unlock,
gives
you
access
to
the
data
itself
and
when
you're
done
using
the
data
you
unlock
the
mutex.
Usually
this
is
a
manual
operation,
but
in
rust
we
use
the
RAI
and
patterns
unlock
the
mutex
when
you're
done
with
them
and
the
mutex
guard
is
the
RAI
object
right.
It
has
the
destructor,
that's
the
drop
function
and
when
the
mutex
guard
is
going
to
go
out
of
scope,
the
destruct
gets
called
on
monster.
New
sax.
B
A
A
A
pointer
and
when
that
gets
dereferenced
you
can,
you
know,
programmatically,
to
specify
the
behavior.
That's
going
to
happen
that
so
in
this
case
the
dierent
we're
going
to
treat
mutex
guard
a
bit
like
a
pointer
and
when
we
do
reference
that
we
get
the
the
data
that
the
mutex
is
guarding
so
to
see
how
this
works
I
mean.
That
is
a
lot
of
a
lot
of
objects
and
kind
of
slightly
exotic
trades.
But
the
the
end
of
fact
is
it's
pretty
simple
right.
You've
got
an
insight.
A
Here's
an
example
of
that
we've
got
a
mutex,
the
gardener's
string.
We
call
a
lock
on
the
means
ax,
and
then
we
just
pretend
like
we've
got
the
string,
okay,
so
the
mutex
guard,
but
that
goes
out
of
scope.
It's
going
to
handle
the
unlocking
and
the
the
direct
rate.
Will
that
allows
us
to
treat
the
mutex
guard
a
bit
like
the
just
a
plain
reference
to
the
string
right,
like
you
even
see
when
you
call
this
print
function,
that
we
treated
exactly
like
the
wrappings
to
a
string,
so
open,
Onix,
good.
A
A
B
A
B
A
Again,
rust,
won't
let
you
do
it
and
they
I
think
it's
interesting
to
see
how
it
does
that
and
again
it's
the
lifetimes
of
savers
so
and
the
game
I
live
slide
you
with
my
initial
the
code
example.
So
the
mutex
guards
a
little
bit
more
complicated.
We've
got
this
lifetime.
Take
a,
and
so
the
Munich's
guard
is
saving
a
pointer
into
the
mutex
itself
with
this
lifetime
ticking,
and
so
when
we
block
the
music's
again,
we
propagate
the
lifetime
from
the
mutex
to
the
mutex
guard,
and
this
means
that
the
we
can't.
B
C
A
A
Has
some
lifetimes
floating
around
and
we
this
time
in
propagating
the
the
lifetime
reference
from
the
music's
guard
to
the
reference
we're
getting
to
the
data,
and
this
means
that
the
reference
we
get
in
this
implicit
d
wrath
of
the
mutex
guard
cannot
outlive
the
mutex
guard.
Ok,
the
type
system
ensures
that
so,
let's
see
how
that
works
like
in
our
example.
A
We've
got
this
lifetime
ck
and
I'm
making
all
the
lifetimes
a
bit
more
explicit
than
you're,
usually
right
here,
so
this
tick,
a
that
we
see
is
basically
that's
going
to
last
as
long
as
the
the
function
foo,
and
so
when
we
pass
that
to
print
we're
going
to
instantiate
this
generic
lifetime.
Tick
B
with
this
lifetime,
that's
food,
and
when
into
this
assignment,
the
compiler
is
going
to
check
like
this
key
invariant,
which
is
that
when
you
reference
something,
if
cut
the
thing,
you're
referencing
has
to
live
longer
than
the
reference
itself.
A
B
A
Versions,
but
you
can't
guarantee
that
for
every
version
of
tick
B,
and
so
this
is
going
to
fail
with
type-checking
okay,
so
where
this
will
fail
is
exactly
on
that
assignment.
It's
not
going
to
work,
and
so
that's
how
you
prevent
kind
of
the
reference
into
the
mutex
kind
of
escaping
into
the
wider
world
and
allowing
this
race
conditions.
A
Of
complicated
all
the
lifetimes,
you
should
be
reassured,
but
like
99th
century
this
happens
behind
the
scenes.
You
don't
need
to
deal
with
it
like
when
you're
doing
Rus
programming.
Most
of
the
time
like
if
you're
writing
libraries,
you
have
to
think
about
it,
most
users
done
the
compile,
takes
care
of
it.
For
you,
you
got
your
safety
and
it's
not
too
bad
to
work
with.
A
D
A
A
This
is
a
little
bit
tricky
to
explain,
because
you
can't
write
all
the
lifetimes
in
the
same
way
that
you
would
like
with
type
parameters
say.
But
if
you
imagine
this
is
just
like
a
generic
method
with
tight
parameters,
then
when
you
call
it
here,
you
would
specify,
like
the
type
parameter,
that
you
are
instantiated.
D
D
A
A
Complicated
than
usual,
because
you've
got
the
implicit
Dirac
happening,
so
this
ends
with
a
mutex
guard
value
and
then
what's
happening
here
is
that
we
implicitly
D
wrap
that
into
the
by
itself
and
then
read
more
L.
Essentially
what
comes
out
of
the
D
wrap,
and
so
there's
a
borrow
here
that
compiler
knows
is
going
to
be
in
this
case
kind
of
with
sculpt
by
this
expression
itself,
and
so
it's
flat
lifetime.
You
know:
that's
essentially
this
bit
of
this
expression.
A
C
D
D
B
A
Are
ghazals
that
would
allow
you
to
do
that
and
then
other
hypothetical
proposals,
but
it
allows
that,
like
explicitly
put
it
there,
it
may
be
useful
for
debugging
aborto
errors
and
stuff,
which
is
why
we're
considering
doing
that,
but
right
now
and
rust.
Yet
you
just
have
to
trust
the
compiler
to
the
end.
Grunts
play
okay.
C
About
there's
a
trick
that
I
found
very
helpful
in
in
reasoning
through
questions
like
this,
and
that
is
to
keep
in
mind
that
the
compiler
always
thinks
about
each
function.
One
at
a
time
when
it's
doing
lifetime
analysis,
it
does
not
track
anything
through
one
function
and
follow
through
that
one
and
then
return
to
the
next
one
go
add
to
its
caller.
Basically,
it
analyzes
each
function
separately,
knowing
only
the
signatures
of
the
other
function,
it
calls
and
so
basically
food
when
it
checks.
Food
has
no
idea
what
print
actually
does.
A
A
B
A
Like
the
polymorphism
that
you're
used
to
or
maybe
used
to
in
our
class
based
object-oriented
languages,
so
here's
the
example
something
you
might
kind
of
expect
to
do
in
Java.
This
is
really
obvious.
Like
you've
got
a
class
foo
you've
got
a
class
bar
which
inherits
from
food
and
part
of
that
inheritance.
B
A
Know
some
people
miss
it
and
occasionally
it's
a
useful
pattern,
see
try
and
recreate
it.
So
let's
try
and
do
that.
The
danger
of
this
is
very
simple.
We
can
emulate
the
the
data
story
quite
easily
in
rust,
right
we
have
some
classes
foo
and
bar
well,
let's
have
some
struts
foo
and
bar
we've
got
a
function
foo
on
foo,
so
let's
just
implement
that
function
foo
on
food
and
we
can
kind
of.
A
We
don't
have
inheritance,
but
let's
get
as
close
to
that
as
we
can
ways
in
composition
and
we're
going
to
put
like
a
field
of
type
foo
inside
our
struct
bar
okay.
So
far
so
good,
like
thousand
fields
and
food,
they
would
be
inherited
into
bar
which
need
a
you
know,
an
extra
stack
to
get
to
them.
But
what
can
we
do
about
this
method?
B
A
C
B
C
A
Know
it's
got
that
going
for
it,
but
you
shouldn't
do
this?
Okay,
so
there's
a
lot
of
reasons
we
shouldn't
do
it
one
like
it
only
works
like
with
when
you've
got
the
thing
by
reference.
It
won't
work
by
values.
Would
you
have
a
lot
of
the
time
to
it?
Doesn't
work
with
generics
if
I
have
a
generic
function
that
expects
a
foo
that
I
can't
give
it
a
three
there's
no
subtyping
like
you
would
get
in
Java
or
C++.
A
So
if
I
have
a
function
that
takes
a
foo
and
I
pass
a
bar
to
it
that
one
type
check
either
four
is
just
surprising
right
like
this
is
not
how
its
intended
so
programmer
comes
along
the
right.
Okay,
let's
find
bar
and
where's
foo.
No
there's
no
method
on
bar
called
foo.
What's
going
on
here,
and
you
surprised
somebody
who's
grading,
your
code
like
we
don't
like
surprising
people
and
then
there's
a
whole
lot
of
subtleties
right,
like
you're,
trying
to
angle
a
job
and
you've
got
pretty
close
right.
A
You
can
call
this
function
foo,
but
you've
missed
up
a
lot
as
well.
You
don't
have
like
class-based
privacy.
There
are
no
interfaces
if
you're
trying
to
get
like
C++,
you
only
have
single
inheritance
and
the
behavior
itself
is
slightly
different
as
well.
If
this
would
jarba
and
I
looked
inside
the
food.
D
B
B
A
A
A
A
B
A
Yeah,
that's
that's
pretty
much
everything,
there's
no
real
conclusion
here.
Just
I
hope
these
are
useful
and
I
hope
it
inspires
you
to
document
more
patents,
and
if
you
do,
then
please
contribution
repository
and
if
you're
interested
in
what
I
talked
about
they're.
All
everything
I
talked
about
today
is
kind
of
also
in
the
repo
and
much
more
detail
so
check
it
out
and
help
me
out
with
more
patterns
if
you're
interested
in
that
kind
of
thing-
and
that's
all
thank
you.