►
From YouTube: Brian Pearce - Learning to Love the Unfamiliar
Description
Coming from Ruby, JS, Python or another language? Exploring new languages can be toilsome. Rust is no different. You’ll find new idioms and features that could be unfamiliar to navigate. You might even detest them at first; comparing it to how you’d prefer it in your favourite language.
We will learn to navigate your transition into the Rust landscape. Introduce practices that might not make sense at first. See comparisons of how you may have done things, and how we can improve those practices with Rust.
---
For more go to https://rustfest.eu or follow us on Twitter: https://twitter.com/rustfest
Help us caption & translate this video!
http://amara.org/v/2FiV/
A
A
But
if
anyone
has
a
recommendation
to
places
to
go,
I've
got
another
week
here,
so
catch
me
in
the
hallway
track
and
I'd
love
to
hear
what
you,
what
you
suggest,
I'm,
also
flying
out
through
Switzerland
Switzerland's,
has
a
lot
of
things
that
are
relevant
to
my
interest,
watches,
chocolate
and
I'm
pretty
sure.
It's
completely
undeniable,
that
their
flag
is
a
big
plus.
A
What
I
want
to
do
is
I
want
to
help
introduce
people
who
are
new
to
the
language
to
these
concepts,
so
that
way
when
they
hit
them
for
the
first
time,
it's
not
gonna,
be
as
big
of
a
hurdle
to
get
over
I
want
to
help
you
kind
of
ease
into
that
a
little
bit
nicer.
So
my
name
is
Brian,
fierce
thanks
for
being
here
with
me
this
morning
and
let's
learn
to
love
the
unfamiliar.
A
A
It's
estimated
that
it
takes
about
three
weeks
to
get
over
this
hump
three
weeks
to
kind
of
get
used
to
it
and
begin
becoming
productive
and
not
running
into
those
bumps.
So
much
so.
With
that
in
mind,
let's
talk
a
little
bit
about
frustration
within
that
first,
three
weeks,
there's
a
lot
of
things
that
can
be
barriers
to
entry
for
people,
things
like
poor
documentation
or
maybe
the
community
access
isn't
as
as
open
or
as
friendly
as
rusts
community
actually
is.
A
When
you
hit
some
of
these
bumps,
you
just
might
not
know
what
to
do
about
it.
Don't
know
where
to
go.
You
don't
know
where
to
turn
to
you're,
potentially
trying
to
achieve
something.
You
know
how
to
do
in
another
language,
and
you
just
can't
work
it
out
here
and
that
gets
incredibly
frustrating
when
you
first
decide
to
pick
up
a
new
language
generally,
you
have
something
in
mind:
I
want
to
build
this
or
I
want
to
I
want
to
do
this
thing
that
I
know
how
to
do
in
another
language.
A
You
have
a
single
purpose
that
you
want
to
accomplish
and
when
you
can't
accomplish
it,
it's
frustrating.
So,
let's
take
a
look
at
an
example
when
I
first
started
learning
Ross
I
wanted
to
simply
port
a
little
bit
of
code
that
I
had
somewhere
else
into
rust,
so
we're
gonna.
Look
at
a
little
bit
of
Python
code,
so
what
we
have
here
is
two
functions
that
simply
read
in
a
file
and
process
the
lines
of
that
file.
Send
it
to
a
process
function
check
to
see
if
the
line
contains
a
pun.
A
If
it
contains
a
pond,
you
should
tell
a
friend
I've
highlighted.
Hopefully
we
can
see
yep
I've
highlighted
the
the
key
points
in
these
two
functions.
The
first
highlighted
line
says
that
we're
going
to
open
the
file.
The
second
highlighted
line
iterates
over
the
lines
of
that
file,
sending
it
to
our
process
function.
The
process
function
checks
to
see
if
it's
a
pun,
if
it's
a
pun,
tell
a
friend
so
I
want
to
port
this
over
to
rust.
So
let's
look
at
what
that
looks
like.
A
So
it's
not
too
different
again,
the
key
areas
are
highlighted
and
the
key
areas
are
pretty
much
exactly
the
same.
You
have
a
file
open
call.
You
have
a
loop
to
iterate
over
the
lines
of
the
file
and
then
you
can
pass
it
to
the
process
function
check
to
see
if
it's
upon
and
again
tell
a
friend
looking
at
them
side
by
side.
Again
key
points
highlighted
it's
it's
very
similar.
A
So
it's
almost
what
you
might
expect
if
you
were
just
coming
from
another
language
and
trying
to
put
something
together
the
thing
that
I
began
to
notice
when
I
started,
writing
more
rust.
Were
these
the
unwrap
calls
the
more
code
that
I
wrote
the
more
on
wraps
that
I
saw
I
didn't
know
what
they
were
for.
I
just
knew
that
the
compiler
told
me
I
had
to
have
them
to
get
the
values
that
I
wanted
to
get
I
didn't
know
if
it
was
boilerplate.
A
I
just
didn't
know
what
was
going
on
and
it
was
littering
my
code
and
I'd
look
at
a
file
after
a
couple
hours
work
and
just
be
like
like
what
is
this
I
don't
understand
it?
It's
just
kind
of
like
it
looks
ugly
I
feel
like
my
code.
Would
look
a
lot
nicer
if
these
weren't
here
and
that
was
frustrating.
A
So
one
of
the
first
things
I
want
to
do
is
actually
take
a
bit
of
a
dive
into
why
that
unwrapped?
Is
there
what
it
does
and
and
why
we
end
up,
seeing
it
in
a
lot
of
places,
so
Russ
doesn't
claim
to
have
maybes,
but
Russ
does
have
maybe
types
and
maybe
is
a
pattern
and
rust
implemented
via
option
and
result.
A
So
we're
gonna
look
at
option
first
and
how
option
works?
Is
it's
an
enum
that
contains
some
or
none
it
contains
something
or
nothing,
and
when
I
first
read
that
that
didn't
seem
incredibly
helpful,
I'm
calling
a
function
I'm
getting
something
that
contains
some
or
nothing
I
thought
every
time.
I
call
the
function
I'm
either
going
to
get
something
like
is
our
value
that
I
expected
or
a
runtime
exception.
That's
still
something
in
a
way,
but
I
never
expected
to
get
nothing.
So
I.
Don't
really
understand
this
as
a
concept.
A
I
don't
want
to
try
and
just
explain
it.
So
we're
gonna
jump
into
an
example
of
where
this
can
actually
be
used
and
why
it's
important
so
we're
gonna
talk
about
Ruby.
So
on
the
screen.
I've
got
a
string,
the
string
contains
the
character
seven
and
when
we're
going
to
convert
it
to
an
integer
with
the
Ruby
method
to
I,
when
we
call
that
we
actually
get
a
seven,
it's
pretty
much.
A
A
A
A
We're
gonna
get
an
option.
We're
gonna
get
a
sum
of
seven.
If
we
do
it
with
an
emoji
called
two
digit
on
that.
What
do
you
were
gonna?
Get
here
perfect,
so
we're
gonna,
get
it
done
same
thing
with
credit
card
number,
get
a
whole
number
we're
gonna
sum
of
that
number,
and
if
we
did
it
with
a
malformed
credit
card
number,
we
would
get
none.
So
this
is
interesting.
A
It's
interesting
because
we're
getting
a
distinct
response
when
the
or
result
when
the
conversion
doesn't
work,
as
opposed
to
getting
kind
of
like
a
mangled
conversion
that
you
don't
necessarily
know
what
to
do
with
afterwards,
which
is
nice.
But
the
thing
is
this:
isn't
what
I
was
expecting
still
when
I
called
two
digit
on
a
seven
I
was
expecting
to
get
a
seven
and
what
I
have
is
a
sum
of
seven
and
that's
not
a
seven
I
can't
do
arithmetic
with
a
sum
of
seven,
depending
on
how
you
understand
that
sentence.
A
A
So
what
this
means
is
the
may
be
that
we
were
initially
getting
was
actually
there
to
protect
us
from
something
if
we
just
called
unwrap
on
every
value
that
we
end
up
getting
the
codes
not
gonna,
be
any
better
than
when
we
were
getting
values
that
we
just
like
weren't,
expecting
bad
conversions
and
stuff,
like
that,
the
unwrap
will
only
work
on
positive
response
from
the
function,
assuming
that
you
actually
got
a
value
out
of
it.
So
now,
I
can
kind
of
understand
a
little
bit
better.
A
A
So
we're
gonna
look
at
another
example:
just
to
kind
of
drive
it
home,
so
here
I've
got
a
Ruby
application.
It
asks
a
user
at
the
command
line
to
enter
a
number.
It
uses
the
two
integer
to
convert
the
string
into
a
number
checks
to
see
if
the
number
is
a
number
and
if
it
is,
we
just
print
great
number,
if
it's
not
we'll
say
that
that
wasn't
a
number
but
as
we've
seen
in
the
previous,
slides,
2i
and
Ruby
will
convert
everything
to
a
number
which
means
that
this
is
actually
dead
code.
A
Rust
I
would
have
originally
written
it
like
this
and
just
called
the
unwrap,
but
now
we
know
that's
bad
and
we
know
why
that's
bad
and
we
know
that
what
we
actually
get
is
a
maybe
what
we
call
two
digit.
So
I
can
begin
changing
this
to
something
that
looks
a
little
more
like
this,
so
I
can
take
the
maybe
and
now
having
that.
Maybe
I
can
check
to
see.
A
One
thing
I
do
want
to
point
out
here
is
that
these
this
kind
of
if-else
condition
isn't
really
idiomatic
rust.
In
a
case
like
this,
we
would
use
something
like
pattern
matching
so
I'm,
just
gonna
change
that
over
to
pattern
matching
really
fast
pattern.
Matching
in
Ross
is
exhaustive,
which
means
you
have
to
account
for
every
case
and
it's
incredibly
powerful
and
it's
used
in
a
lot
of
places
in
rust.
That's
as
much
as
I'm
gonna,
say
on
pattern.
A
Matching
I
just
wanted
to
kind
of
point
that
out
on
that
slide,
because
it
wasn't
the
prettiest
slide
before
that.
So
in
the
beginning,
when
I
first
started
writing
rust,
we
saw
all
those
unwraps
I
didn't
understand
what
they
were.
They
were
frustrating
because
I
had
to
put
them
there
and
I
didn't
understand.
Why,
now
that
I
can
see
why
and
see
what
they
bring
value
wise
to
me,
it's
not
so
frustrating
anymore.
A
So
we're
gonna
talk
a
little
bit
about
error
handling
in
other
languages.
There's
times
that
I
write
code,
that
I
just
expect
something
to
go
wrong.
I'm
gonna
go
call
a
function,
and
you
know
maybe
I'm
gonna
get
a
timeout
from
someone's
API
or
I'm
gonna
get
a
value
that
someone's
written
that
I,
just
like
wasn't
expecting
something's
gonna
go
wrong
and
did
a
lot
of
the
languages
that
I
normally
write.
A
I
would
use
something
like
like
a
rescue
trying
to
catch
begin
rescue,
we're
gonna,
look
at
those
real
quick,
so
this
is
Javas,
try
and
catch
if
you're
not
familiar
with
Java
how
it
works
is.
If
you
have
code
that
you
want
to
execute
that
you're
worried
about
throwing
exceptions,
you
put
it
between
the
try
in
the
catch.
If
the
code
throws
an
exception,
then
the
between
the
catch
and
the
bought
in
parentheses,
the
code
there
is
executed
in
Ruby,
we
have
begin
rescue
end.
A
It
works
very
similarly
code
to
put
between
B
begin
and
rescue
is
executed.
If
something
goes
wrong
between
rescue
and
end
is
executed,
pythons
very
similar,
so
the
next
person
was
well.
What
do
I
have
entrust
I'm
writing
some
code.
I
know
something
has
the
potential
to
go
wrong
here.
I
I
want
to
try
and
catch
an
exception,
so
I'm
gonna
hit
Google
and
gonna.
Look
at
Stack
Overflow.
What
am
I
gonna
find
I'm
gonna
find
the
Tri
macro.
Now
this
looks
kind
of
nice.
A
It's
small,
it's
simple,
but
it's
approximately
50%
of
what
every
other
language
had
where
do,
I
catch
the
errors
like
I,
don't
understand
what
to
do
with
this.
So
let's
talk
about
frustration
again.
I
know
what
I
need
to
achieve.
I
know
how
to
achieve
it
in
another
language.
I
do
a
quick,
google
search.
This
is
what
I
get
and
I
just
don't
I
don't
see
the
direct
comparison.
A
It
doesn't
immediately
make
sense
what
I
need
to
do
with
this
and
it
didn't
really
begin
to
make
sense
until
I
looked
at
combining
it
with
the
result,
maybe
which
was
the
other,
maybe
type
that
I
had
mentioned.
So,
let's
take
a
quick
look
at
result
before
we
come
back
to
how
to
use
try
so
much
like
the
option
which
returns
some
or
none
the
result,
returns.
Okay
or
err,
if
you
didn't
okay,
you
know
the
the
function
that
you
called
was
successful.
If
you
get
an
error,
something
went
wrong,
so
we're
gonna.
A
So
it's
our
same
read:
file
function,
but
now
I've,
given
it
that
try
and
except
block
I
know
something
can
potentially
go
wrong.
When
I
go
to
open
that
file
could
be
anything.
Maybe
the
file
doesn't
exist.
So
it's
just
gonna
raise
an
error.
I'm
gonna
catch
that,
in
the
exception
block.
So
if
I
want
to
do
this
in
rust,
I'm
gonna,
look
at
our
read
file
function
again
from
rust
and
there's
a
few
things
here
that
are
gonna
change,
so
I'm
gonna
give
myself
a
little
space.
A
I'm
gonna
highlight
the
two
places
that
I'm
going
to
change.
First,
the
first
one
is
going
to
be
the
method
signature.
The
second
one
is
going
to
be,
where
I'm
actually
calling
file
open,
so
I've
changed
the
method.
Future
method.
Signature
now
has
a
result
type
and
that
result
type
is
a
result
that
lets,
or
that
says
that
now
something
somewhere
in
this
function
could
potentially
go
wrong
and
I
am
going
to
return
this
result
type.
Maybe
so
now
we're
gonna.
A
Look
at
try
tries
the
second
thing
that
we've
highlighted
here:
we've
added
the
Tri
macro
around
our
file,
open
call,
and
what
tri
does
for
us
is.
It
will
execute
the
file
open
function
and
if
something
goes
wrong,
it
will
actually
capture
that
error,
put
it
into
an
error,
type
or
an
error,
result
type
and
then
return
it
out
of
your
function
immediately.
So
it's
going
to
capture
the
error,
put
it
in
the
proper
type
and
then
return
from
your
function.
Now.
A
A
The
next
nice
thing
you
can
do
is
you
can
begin
mapping
the
error,
so
you
can
chain
it
on
to
the
initial
call,
and
if
something
goes
wrong,
you
can
turn
it
into
something
else.
Instead
of
just
taking
the
panic
that
file-open
gave
you,
you
could
add
text
to
it,
you
could
turn
it
into
a
custom
type
and
then
try
will
still
map
it
into
an
error
and
then
return
it
out
of
your
function.
A
For
you,
the
last
thing
you
need
to
do
is
now
that
we
are
returning
a
result
and
then,
under
the
assumption
that
everything
actually
went
well,
you
need
to
return
it.
Okay
and
okay
is
the
other
type
in
the
result,
and
the
okay
says
that
everything
successfully
went
okay,
like
your
function
date
exactly
what
you
expected
it
to,
and
now
you
can
return
that.
A
Testing
in
rust,
for
me,
was
kind
of
like
a
bit
of
an
up
and
down
like
it
was
a
rollercoaster
coming
from
languages
that
have
a
lot
of
test
frameworks
and,
and
that
kind
of
thing
I
again
had
expectations.
I
had
how
I
knew
how
to
do
things
in
other
languages
and
then
I
wanted
to
just
like
drop
into
rust
and
then
do
exactly
those
same
things
and
expect
it
to
work.
And
unfortunately
it
didn't
quite
work
like
that.
A
So
some
of
the
things
that
were
me
were
as
opposed
to
Ruby
or
Python
or
JavaScript,
where
a
lot
of
people
write
their
tests
in
a
test
directory
rust,
actually
lets.
You
write
similar
tests
in
line,
so
you
can
define
the
function
in
rust
in
whatever
file
you're
writing
in
and
then,
if
you
want
it
immediately
under
it
use
the
test
macro,
that's
highlighted
here
and
then
define
the
test,
and
that
works
it's
again,
not
necessarily
idiomatic
rust.
A
A
lot
of
people
would
prefer
to
put
it
in
module
at
the
end
of
the
file
or
change
some
of
the
semantics
around
how
they
actually
organized
everything
in
that
file.
But
you
can
do
this
and
it's
kind
of
nice
actually,
once
I
got
over
the
fact
that
I'm
not
doing
it
like
I'm,
used
to
I
kind
of
like
this.
Now,
when
I'm
looking
for
the
tests
of
a
particular
function,
that's
I'm,
modifying
I,
just
know
it's
in
that
file,
as
opposed
to
happening
to
search
through
the
project
and
and
find
where
those
things
are.
A
Rust
being
one
of
the
first
compiled
languages
that
I
dealt
with
the
other
nice
thing
that
I
didn't
really
realize.
That
first
was
that
all
of
the
test
code
that
goes
in
the
files
in
my
source
files
is
not
going
to
be
compiled
in
the
end
it
just
the
compiler
strips
all
that
stuff
out,
so
you
don't
have
to
worry
about
it.
A
A
So,
if
you've
written
a
library,
what
you
want
to
do
is
include
your
library
into
that
crate.
Your
test
file
is
now
a
consumer
of
your
library,
so
it's
at
the
end.
It's
where
anyone
else
who's
going
to
pull
in
your
library
would
be
so
now
you
can
test
it.
From
that
point,
you
only
get
to
test.
What's
made
publicly
available,
which
is
nice,
it's
kind
of
like
a
better
true
black
box
integration
test,
but
it's
not
again.
It's
not
necessarily
what
I
expected
when
I
first
opened
some
of
the
other
nice
things
about.
A
Rus
testing
is
the
random
order
testing
by
default.
A
lot
of
languages
have
that
built
into
their
frameworks.
Now
that
didn't
initially
run
with
those
things
beforehand,
so
random
order
testing
basically
says
that
all
of
your
tests
instead
of
running
you
know,
linear
processes,
they're,
just
gonna
get
randomized
your
last
one
will
get
run
first
and
so
on
and
so
forth,
which
is
great,
it's
great,
that
this
is
default.
A
A
So
if
I've
got
some
code
in
Ruby
and
I'm,
gonna
explain
this.
That
top
function
does
a
little
bit
of
setup.
It
creates
a.
It
creates
a
directory
that
I'm
going
to
do
some
writing
to.
In
my
tests
the
teardown
clears
out
with
that
directory
completely
and
the
tests
themselves
actually
just
write
a
file
and
then
assert
to
see
whether
that
file
exists.
A
So
it's
not
doing
too
much,
but
there's
a
lot
of
io
writing
and
in
Ruby
these
tests
pass
every
single
time.
There's
nothing
wrong
here,
it's
perfectly
fine.
It
does
pretty
much
what
I
wanted
to
do.
So,
if
I
port
this
over
to
rust,
it
looks
a
little
different,
so
I'm
not
using
any
framework
or
anything
in
particular
with
this
rest
code.
So
the
setup
I
call
specifically
in
my
test,
but
that's
the
same
thing
make
sure
that
the
directory
exists.
A
If
I
have
10
tests
like
this
I'm
gonna
say
a
out
of
10
of
them
are
gonna,
fail
every
single
time
and
they're
gonna
fail
differently.
It's
not
going
to
be
consistent,
which
ones
will
fail,
but
they're
going
to
continue
failing
and
when
I
started.
Learning
rust,
I
legitimately
ran
into
this
problem.
This
exact
problem
and
more
hair
was
pulled
and
I
was
sitting
in
a
hotel
in
Portland
and
like
trying
to
blame
it
on
everything.
A
I
possibly
could
like
running
the
code
in
new
VMs
and
like
changing,
os's
and
stuff
like
this
can't
be
a
problem
with
the
code.
The
code
works.
Fine
in
Ruby,
like
it's
gonna
work.
Fine
here
and
the
problem
here
with
parallel
testing
is
that
in
a
case
where
you're
doing
a
lot
of
I/o
or
sharing
resources,
you're
gonna
run
into
problems
like
this.
So
the
problem
that
that
actually
occurred
is
your
first
test
has
started
to
run.
A
It's
made
sure
the
directory
exists,
written
its
file
done
it's
assertion
to
make
sure
if
the
file
exists
and
then
your
second
test
comes
along.
Make
sure
that
the
director
is
there
writes
its
file
and
then
before
it
goes
to
view
the
assertion.
The
first
test
goes:
ok,
I'm
done
here
like
let's
just
clear
this
directory
out.
We
don't
need
it
anymore
and
then
your
second
test
is
like
my
files,
not
here
anymore,
weird
it
we're
done
here
like
it's
failed
everything's,
failed,
everything's,
terrible
here,
and
if
you
don't
know,
that's
happening.
A
If
you've
come
from
a
language
where
things
don't
run
in
parallel
by
default,
then
it's
not
gonna.
Come
to
your
mind
at
first
to
just
be
like
oh
I,
you
know
things
are
running
in
a
parallel
execution.
It
took
me
a
long
time
to
realize
that
this
was
actually
happening,
but
now
that
I
know
what's
happening,
I
know
how
to
work
around
it.
I
know
how
to
write
better
tests
and
not
share
resources.
A
What
this
is
done
is
now
all
of
my
tests
that
are
right,
I'm,
going
to
think
about
this
kind
of
situation,
I'm
gonna,
think
about
where
my
code
is
going
to
run
like
I,
don't
know
if
my
codes
end
up
going
to
end
up
being
run
in
parallel.
If
I
just
like
give
it
to
someone,
they
could
run
that
in
parallel.
I
have
to
make
sure
that
there's
not
going
to
be
a
detriment
that
happening
and
I'm
gonna
write
better
tests.
A
So
we're
gonna
round
this
off
we're
going
to
talk
about
frustration
one
last
time
the
definition
of
frustrate
by
Webster
Merriam
I
believe
was
to
prevent
from
accomplishing
a
purpose
or
fulfilling
a
desire,
and
if
we
go
back
to
the
beginning
of
the
talk
when
I
said,
I
wanted
to
learn
a
new
language
and
I
want
to
do
just
like
one
thing.
That's
that
one
thing
I
have
one
purpose
that
I'm
trying
to
accomplish
and
I
can't
and
that's
frustrating
in
programming.
A
Frustration
can
frequently
mean
we're
learning
something
new.
Once
you
have
a
better
understanding
of
why
those
things
were
frustrating
and
you
can
see
them
clearly,
then
you
might
actually
find
yourself
applying
these
in
different
places.
You
can
learn
to
appreciate
those
things
that
were
frustrating
for
you
initially
so
now,
even
if
you're
writing
more
Ruby
code
and
your
Ruby
code
runs
linearly
you're
going
to
think
about
that
problem
that
you
ran
into
when
you
were.
A
Writing
rust,
like
I'm
gonna,
think
about
writing
a
better
test
here
to
make
sure
that
these
things
couldn't
possibly
go
wrong
in
the
event
that
they
was
running
in
parallel.
The
next
time.
I
write
a
function
in
Python,
I'm,
gonna,
think
more
about
what
are
the
possible
result?
Types
coming
out
of
here
like
what
things
can
go
wrong,
am
I
going
to
get
responses
that
I,
just
like
I'm,
not
expecting
as
the
conversion
going
to
come
out
properly.
Like
can
I
verify
that
before
I
work
with
that
data,
I.
A
Will
leave
you
with
a
quote
from
Henry
Ford
for
the
world
was
built
to
develop
character,
and
we
must
learn
that
the
setbacks
and
grieves
which
we
endure,
help
us
in
our
marching
onward.
That
said,
the
unfamiliar
can
be
challenging,
but
there
can
be
so
much
to
learn
and
love
well,
overcoming
it
and
once
you
have
you'll
come
out
a
better
programmer
than
when
you
win
it
in
I'm
brian
Pierce.
Thank
you
very
much
for
listening,
and
it's
been
a
pleasure
to
be
here
with
you
today.