►
From YouTube: RustCon Asia 2019 - Nick Cameron: Making Rust Delightful
Description
Rust strives to be an ergonomic language: easy to read, easy to write, and easy to maintain. We want it to be a language which delights! But what does that mean? How do the language and library designers decide what makes a feature ergonomic? And how do we consider the trade-offs between ergonomics and other design pressures such as safety and performance?
I’ll cover Rust’s design philosophy, some case studies on ergonomics from the language, libraries, and tools, and talk about how design decisions are made by the language team and others. I’ll talk about issues such as ‘explicit vs implicit’, syntactic sugar, and consistency.
Find slides here: https://github.com/nrc/talks/blob/master/rustcon-asia-19/making-rust-delightful.pdf
Follow us on Twitter: https://twitter.com/RustConAsia
C
C
C
Look
forward
to
programming
and
rust
I
get
up
in
the
morning
and
I
go
to
work
and
I.
Think
yeah
I
get
to
use
rust
today,
it's
a
good
day
and
I.
Don't
think
like
that
about
every
programming,
language
and
apparently
I'm,
not
the
only
one,
because
for
the
fourth
year
in
the
row
the
stack
overflow
developer
survey
has
picked
rust
as
the
most
loved
language.
C
C
The
I
think
one
of
the
really
great
one
of
the
main
reasons
that
rust
is
a
delightful
language
to
use
is
because
the
the
Russ
community
has
always
tried
to
make
it
a
delightful
language
to
use-
and
this
sounds
kind
of
obvious,
but
it's
very
easy
to
get
caught
up
in.
What's
the
most
elegant
solution
or
what's
the
most
technically
pleasing
solution
to
a
problem
and
not
what
will
make
it
the
the
user,
the
happiest
ever
since
kind
of
the
very
first
days
of
rust,
there's
been
this
emphasis
on
making
it
a
practical
language
it.
C
There
was
like
a
huge
effort
to
actually
get
something
released.
There
was
like
we
needed
kind
of
like
get
all
these
kind
of
moving
parts
in
the
language
and
and
the
library
is
all
working
together,
and
but
there
was
also
this
sense
that,
like
once
your
once,
you
have
the
1.0
release
you,
you
can't
go
back,
we've
got
this
backwards,
compatibility
guarantee
and
it's
not
good
enough
to
make
just
a
language
which
exists.
C
C
C
If
you
want
to
have
data
that
can
represent
multiple
variants,
then
you
can
even
write
this
using
kind
of
classes
and
inheritance
and
it
and
it
works,
but
in
rust
we
give
you
in
ins
and
enums
and
variants
much
more
closely
match
that
mental
model,
and-
and
so
this
is
reducing,
friction
and
making
your
program
easier.
It's
a
reason
about,
but
I
said
at
the
beginning
that
one
of
the
reasons
we've
ended
up
with
a
language
which
is
I
think
quite
pleasant
use
is
because
we've
we
focused
on
that.
C
C
It's
it's
full
of
gray
areas
and
fuzzy
questions
and
there's
no
like
hard
answers.
It's
it's
just
all
kind
of
trade-offs
and
there's
a
lot
of
context.
What
works
well
for
one
library
might
not
work
in
another
library.
What
works
for
one
programming
language
might
not
work
in
another
one.
So
just
because
something's
ergonomic
and
say
Python
doesn't
mean
that
it's
ergonomic
in
rust
and
there's
all
sorts
of
cross-cutting
concerns
and
intersections.
C
For
example,
if
your
user
is
using
an
IDE,
as
opposed
to
say
vim,
then
you're
going
to
have
a
very
different
experience
of
what's
economic
in
the
language
and,
what's
not
so,
if
it's
so
difficult.
How
do
we
actually
make
decisions
about
this
in
an
ideal
world
would
be
very
scientific,
would
conduct
user
studies.
C
We
would
come
up
with
you
know,
evidence
and
data
and
so
forth,
but
this
is
actually
really
difficult.
It's
a
set
of
skills
that
have
have
not
really
existed
in
the
Ross
community
and,
more
importantly,
we
just
don't
have
the
resources
to
to
do
this
kind
of
work,
and
even
if
we
did,
even
if
you
have
some
nice
crisp
scientific
answers.
Well,
you
still
have
you
know
which
users
do
you
study
which
questions?
Do
you
ask
and
so
forth?.
C
Thinking
about
use
cases
can
help,
but
there
is
a
risk
fair
that
you
over
specialize
that
you
like
language,
designed
by
kind
of
addressing
use
cases.
January
doesn't
work
out
so
well,
but
we
can.
We
can
also
explicitly
ask
users,
and
even
when
we
don't
ask,
we
get
plenty
of
feedback
through
the
RFC
process
and
other
channels
and
there's
a
lot
of
rust
code
that
already
exists.
C
C
Important
things
should
be
explicit
and
there's
a
corollary
to
that,
which
is
that
things
that
are
not
important
should
be
implicit.
You
shouldn't
have
to
write
lots
of
boilerplate
we'll
go
through
lots
of
ceremony
to
get
your
work
done
again.
This
begs
the
question
what's
important
and
this
is
a
really
hard
question,
because
it
gets
back
to
every
user
being
different.
What's
important,
for
one
user
might
not
be
important
for
another
and
well
so
one
thing
that
just
a
pic
kind
of
something
concrete
that
is
often
important
in
rust.
C
One
of
the
core
principles
in
developing
the
the
rust
tool
ecosystem
has
been
to
to
put
the
user
first
and
again.
This
sounds
really
obvious
thing,
but
there
are
lots
of
other
kind
of
design
constraints.
Do
you
want
to
make
your
tool
fast?
Do
you
want
to
make
your
tool
scriptable?
Should
the
output
be
machine
readable?
These
are
all
important
goals,
but
I
believe
they
should
be
secondary.
What's
really
important,
is
the
user
interacting
with
the
tool,
should
have
a
good
experience,
a.
C
Principle
that
we
come
back
to
again
and
again
is
consistency,
I,
four
tools.
That
means,
if
you,
if
at
all,
can
do
multiple
different
things,
then
it
should
do
them
in
a
similar
way
and
between
tools.
We
should
try
and
stick
to
the
same
kind
of
user
experience,
and
this
is
this,
makes
the
tools
ergonomic,
because
you
spend
less
time
looking
up
how
it
all
works
and
you
can
apply
the
usage
patterns.
You've
you've
got
from
using
other
tools.
So
when
you
come
to
a
new
tool,
it
should
just
work
you
should.
C
It
should
be
intuitive
to
you
another
principle
that
we
usually
stick
to
is
convention
over
configuration.
Where
we're
not
extreme
about
this.
We
like
to
offer
you
ways
to
configure
your
tools,
because
that's
important,
every
user
is
different,
every
users
trying
to
do
different
things,
but
the
idea
is
that,
if
you're
doing
something
common,
then
the
tool
should
just
work.
You
should
not
have
to
create
a
configuration
file
if
you're,
using
a
at
all
in
the
normal
kind
of
way.
C
So
I
want
to
go
through
an
example
to
show
how
these
principles
apply
in
practice.
Let's
say
you
want
to
format
some
code.
Well,
you
can
use
the
russ
format
tool
to
do
this,
and
in
order
to
make
it,
you
have
to
install
this
tool
on
your
computer
and
in
order
to
make
this
whole
flow
as
easy
as
possible.
We
provide
a
tool
for
installing
these
tools.
C
Okay,
so
you
run
rust
up,
and
this
is
the
same
thing
you
would
run
rust
up
to
install
other
tools
and
to
install
things
like
source
code
once
it's
installed,
and
hopefully
that
was
easy
to
install
it.
Running
rust
for
map
is
consistent
with
other
cargo
commands.
You
run
it
just
like
you
would
run
car,
go
build
your
own,
carry
out
format
and
sticking
to
the
convention
of
a
configuration
principle.
When
you
do
this,
it
should
do
the
right
thing.
C
If
you
have
a
regular
cargo
project,
it
will
reformat
the
whole
project
and
nothing
more
and
the
formatting
we
use
is
hopefully
something
that
you
will
approve
of
it's
a
sensible
formatting,
which
you
can
configure
if
you
really
want
to,
and
if
you
do
have
to
do
something
unusual.
If
you
do
need
to
pass
some
arguments
to
rust
format,
then
you
can
do
that
using
the
same
arguments
that
you
would
pass
to
cargo
build.
So
there's
consistency
between
these
different
tools,
a.
C
C
So
we
can
see
this
is
the
the
rust
error
message
from
a
few
years
back,
and
this
is
how
it
looks
today.
A
lot
of
people
will
have
put
a
lot
of
effort
into
making
our
error
messages
great
and
the
the
best
example
is
probably
borrow.
Checking
you
know,
borrow
checking
is
something
a
lot
of
people
struggle
with
in
rust,
especially
as
they're
learning
the
language.
C
It's
it's
a
pretty
unique
concept,
and
so
we
put
a
lot
of
effort
into
the
error
messages,
not
only
to
clearly
explain
the
error,
but
to
help
you
learn
from
your
mistake
to
not
that
make
that
mistake
again
to
better
understand.
What's
going
on
inside
the
compiler
and
it's
you
know,
it's
been
a
lot
of
work
to
do
that.
It's
not
just
about
writing
a
nice
message.
There's
fundamental
work
in
the
compiler
that
make
the
compiler
more
complex.
C
Again,
consistency
is
a
really
important
principle
here
and
for
libraries
this
means
consistency
of
naming.
It
means
consistency
of
usage
patterns.
So,
if
you're
used
to
using
a
vac,
then
when
you
start
using
a
hashmap
it'll
be
a
similar
experience
and
it
means
consistency
in
the
declaration
patterns
as
well.
So
when
you're
reading
the
documentation
or
the
source
code,
you
don't
have
too
much
friction
between
different
data
types
or
different
functionality.
C
Another
principle
is
to
minimize
duplication.
A
good
example
of
this
is
prior
to
1.0.
There
were
seven
different,
find
methods
on
a
on
hash
map,
seven
and
they
were
all
doing
essentially
the
same
thing.
They
were
just
doing
a
find,
but
with
you
know,
slightly
different
semantics
around
referencing
or
ownership,
or
something
and
that's
very
unorganized,.
C
Op
and
think
do
I
use
this
find
all
this
fine.
Well,
all
you
want
to
do
is
find
a
value
and
that's
unnecessary,
unnecessary
ceremony,
because
you're
focusing
on
what's
not
important.
Okay,
what's
important
is
finding
a
value
and
what's
not
important-
and
in
this
case
is
the
state
of
the
key
I
want
to
kind
of
like
dig
into
this
with
an
example.
So
here
we've
got
a
hash
map.
It's
a
mapping
from
strings
to
integers.
C
C
When
you
insert
something
with
it
into
the
hashmap,
you
don't
want
to
allow
our
reference
you
own,
you
want
to
to
only
have
the
own
type,
and
here
the
ownership
is
important,
and
so
you
do
have
to
think
about
it,
because
if
we
let
you
pass
references,
then
the
hashmap
would
have
to
clone
that
reference,
and
that
can
be
a
really
expensive
operation.
So
that's
something
that
is
possibly
important
for
for
users
to
know
about,
and
so
we
make
our
users
be
explicit.
C
So
how
do
we
kind
of
like
make
all
this
work?
Well,
so
let's
have
a
look
at
the
the
signature
for
for
hashmap.
This
is
kind
of
a
slightly
simplified
version
of
the
real
hash
map
by
the
way.
So
this
is
just
a
hash
map
from
keys
with
type
k2
values
with
type
V,
and
this
is
what
the
GAT
method
looks
like
and
what's
interesting
here
is,
you
might
expect,
get
to
take
a
reference
to
K,
but
it
doesn't.
C
We
have
this
new
type
Q
and
we
take
a
reference
to
Q
and
we
use
the
trait
called
borrow
to
relate
the
types
K
and
Q.
We
say
that
K
can
be
borrowed
as
Q,
and
there
are
implementations
for
stuff
like
string
and
stir
to
make
this
connection
and
that's
kind
of
complicated
I'll
go
back
a
second.
This
is
kind
of
complicated.
You
may
well
say
well,
this
is
not
very
ergonomic
and
you'd
be
right,
but
it
does
laughs.
C
This
example
work
and
I
think
that
this
usage
is
very
ergonomic
and
furthermore,
not
only
does
it
work
with
strings,
but
it
works
with
VAX
and
slices
and
it
works
with
all
your
other
reference
types
as
well.
So
there's
consistency
here
as
well
as
eliminating
duplication,
and
this
is
a
leads
to
another
heuristic,
which
is
that
if
you
have
to
trade
off
complexity
in
the
in
a
library
versus
complexity
in
a
client
put
the
complexity
in
the
library,
because
hopefully
many
more
people
will
use
your
library
than
write.
Your
library
right
and
usually
library.
C
Talk
about
language,
language
is
really
about
trade-offs,
a
kind
of
really
classic
and
a
shred
of
a
start
with
is
kind
of.
Do
you
want
to
make
a
general
solution
or
a
very
specific
solution,
general
might
give
you
kind
of
less
duplication,
but
specific
might
be
easier
to
understand.
So
error
handling
is
an
example
of
this.
In
Haskell
you
have
do
notation,
which
handles
any
monadic
type.
This
is
extremely
general
in
Java
and
JavaScript.
You
have
syntax
like
throw,
which
is
extremely
specific
to
exception
types
in
rust.
C
Another
trade-off
is:
do
you
want
a
simple
analysis,
so
the
compiler
is
doing
an
analysis
that
the
programmer
can
actually
understand.
Or
do
you
want
something
to
be
easy
to
use?
An
example
of
this
is
the
borrow
checker
prior
to
the
2080.
In
addition,
we
had
lexical
lifetimes,
which,
as
a
concept,
are
pretty
easy
to
explain.
C
It's
not
an
easy
concept
to
explain.
Sorry,
it's
rare
EEZ
since
the
2080.
In
addition,
we
have
non
lexical
lifetimes
nll,
which
is
much
harder
to
explain.
I
could
not
sit
down
and
explain
it
to
you,
but
it
does
make
the
your
programs
easier
to
use
it's
often
more
ergonomic
to
use
nll,
because
you
have
to
worry
less
about
some
borrowing
errors
and
then
the
the
biggest
trade-off
of
all
is
between
explicit
and
implicit,
an
example
of
this
and
Russ.
C
It's
the
ownership,
that's
important
in
rust,
and
so
that's
why
you
have
to
make
explicit
whether
something
is
owned
or
borrowed,
but
whether
it's
moved
or
copied,
we
think,
is
not
as
important
so
that
is
left
implicit,
I'm,
gonna,
try
and
put
all
this
together
with
another
example.
This
is
a
common
way
to
match
an
expression.
This
is
pre
2018
edition
code
and
what's
really
important
here.
C
C
What's
not
important,
well,
exactly
like
the
fact
that
X
is
going
to
end
up
borrowed
is
kind
of
important,
but
we
know
that
what's
not
important
is
exactly
how
that
borrowing
flows
from
the
outer
X
variable
insert
the
the
matched
variable
yeah.
This
is
just
kind
of
type
Tetris
you
you
just
have
to
play
until
you
got
it
right,
usually
and
so
with
the
28.
In
addition,
we've
eliminated
that
we
think
it's
not
important,
so
you
can
leave
it
implicit
and
concentrate
on
what's
important,
and
hopefully
this
is
easier
to
write.
C
C
C
That's
particularly
true
in
the
areas
of
of
ergonomics.
Unfortunately,
this
gets
more
difficult
as
you
get
more
and
more
users
and
those
users
have
relatively
more
and
more
experience.
There's
a
lot
of
kind
of
pushback
stop
energy
on
what
you
can
do,
because
people
know
how
to
do
stuff.
They've
got
used
to
it.
C
But
we
want
to
continue
making
positive
change.
We
want
to
continue
making
rusts
better,
so
a
few
things
that
we
might
do,
I'm
not
saying
that
we
will
I
talked
a
little
bit
about
error
handling
earlier
well.
I
still
think
that
it's
not
perfect
to
me
if
I've
got
a
function
that
looks
like
this
there's
a
lot
of
boilerplate
there.
C
Why
do
I
have
this
okay
and
all
these
parenthesis
of
the
bar
bottom,
like
if
I,
if
I,
if
I'm
not
doing
the
error,
handling
I,
don't
need
to
put
the
parenthesis
there
and
why
do
I
need
to
declare
result?
It's
like
if
we're
thinking
about
convention
of
a
configuration
99%
of
the
time
you
are
using
result.
Why
do
I
have
to
write
that
out?
C
So
maybe
we
can
do
something
about
that.
Here's
another
case
why
I
said
earlier
that
it's
often
important
that
you
know
whether
something
is
borrowed
or
owned,
but
if
it's
a
copy
type,
it
doesn't
really
matter.
So
why?
When
I
expect
a
reference,
do
I
have
to
explicitly
borrow
a
copy
type
when
it
makes
no
difference
to
the
caller.
C
This
is
another
kind
of
kind
of
useless
ceremony,
so
maybe
we
can
do
something
there
and
async/await
is
probably
the
most
exciting
thing
to
happen
to
rust
since
the
whompin
over
lease-
and
this
is
all
about
ergonomics-
you
can
write
using
futures
today
and
it
works.
It's
fine,
it's
very
fast,
it's
very
safe,
but
it's
not
very
ergonomic.
It's
it's
a
pain
to
write
all
your
futures
code
with
async/await.
We
we
make
things
much
more
pleasant
on
the
tool
size.
Our
areas
are
still
not
perfect.
I
would
not
think
this
is
a
useful
error.
C
C
You
need
to
keep
putting
the
effort
in
to
make
things
better
and
the
the
key
tool
you
have
to
make
things
better
is
empathy
and
you
need
to
relentlessly
focus
on
what
is
important
and
what
is
important
for
your
users,
not
what
is
important
for
you
or
you
and
your
friends
or
you
in
your
colleagues
or
something
okay.
That's
everything
quickly.
I
just
want
to
thank
Brian,
Anderson
and
Nika
Markus,
who
gave
some
really
valuable
input
to
this
talk
and
I
want
to.
Thank
you
all
for
sitting
through
it.
Thank
you.
D
Api
consistency
is
very
important
in
library,
but
some
consistency
is
ensured
by
the
design
of
the
library
directive.
L
of
her
no
such
as
the
flat
map
method
on
option
on
without
an
iterator
or
other
things.
Do
you
think
that
rust
should
import
some
high
order
traits
abstractions
such
as
such
as
functor
applicative
or
moneda
in
Haskell?
D
C
An
excellent
question
just
to
repeat
for
the
audience:
I
did
the
gist
of
the
question
is:
should
we
be
using
kind
of
more
sophisticated
type
system,
things
like
high
higher
kind
of
types
or
functors
and
so
forth
in
order
to
enforce
generality
across
the
the
libraries
and
I
think
this
gets
back
to
an
yet
another
trade-off,
which
is?
Do
you
want
to
make
your
your
code
as
reusable
as
possible?
Even
if
that
comes
at
the
expense
of
a
more
complex
type
system?
C
Or
do
you
want
a
really
simple
type
system
where
you
you
lose
some
safety
or
you
lose
some
reusability
and
like
with
a
lot
of
things,
rust
is
somewhere
in
the
middle,
where
you
know
we
do
have
very
expressive
generics,
but
we
don't
have
higher
kind
of
types,
and
at
the
moment
we
think
that
that
is
the
right
place
on
that
spectrum.
There
are
a
few
things
coming
up
like
generic
associated
types,
which
movers
a
little
bit
kind
of
to
further
towards
more
generality,
but
in
general,
I.
C
Think
the
things
like
higher
kind
of
types
are
not
a
good
fit
for
rust
and
and
again
it's
getting
back
to
kind
of
the
beginning
of
the
talk.
I
said
that
context
was
really
important.
What
works
really
well
in
Haskell?
What
is
really
economic
in
Haskell
is
not
necessarily
really
ergonomic
and
rust
and
I.
Think
yeah
things
like
you
know,
explicit,
monads
or
higher
kind
of
types
are
not
a
good
fit
for
rust.
B
Hello,
niche
I
enjoyed
your
talk.
Thank
you.
So
I
am
completely
new
to
arrest
her,
but
before
I
did
a
C+
password.
So
if
I
am
considering
switching
from
rust
to
rust,
so
what
kind
of
specific
other
ones
it
is
I
can
get
by
the
switching
and
maybe
probably
what
kind
of
peace
advantages.
What
kind
of
a
shortage
does
rust?
How
currently
so?
Thank
you.
B
C
Yeah
I
think
there's
kind
of
lots
and
I
wouldn't
even
know
where
to
start
I,
think
kind
of
on
the
sole
on
the
language
side.
Sometimes
kind
of
the
the
generics
in
C++
can
be
a
bit
more
expressive
than
they
are
in
rust,
and
hopefully
we
can
address
the
with
better
procedural
macros
and
generic
associated
types
error
handling
in
C++,
although
kind
of
exception,
I
think
most
kind
of
like
real
uses
of
C++
kind
of
always
turn
off
the
the
can
don't
use
exception
throwing,
but
this
is
sometimes
more
more
ergonomic
than
rust
is
I.
C
Think
obviously
kind
of
like
the
the
ecosystem
is
much
more
mature.
You
know
you
could
in
in
in
in
C++,
you
have
a
you
can
find
libraries
that
do
do
everything
I.
You
know
there's
a
lot
of
gaps
in
in
rust
support,
but
you
know
that's
getting
better
like
literally
every
day
and
on
the
tool
side
the
tools
are
kind
of
much
more
mature
and
more
closely
suited
to
C++.
It
would
be
great
to
have
you
know
better
IDE,
support
or
debuggers
the
better
understand,
Russ
natively.
B
C
C
Not
exactly
sure
how
to
procedural
macros
allow
you
to
kind
of
like
process
kind
of
like
input,
compile
time
as
as,
if
you
were
kind
of
like
changing
the
language,
I
guess
and
that's
kind
of
very
different
from
what
Const
functions.
Let
you
do
which
is
kind
of
much
more
limited,
compile
time
execution
so
yeah.
They
have
quite
different
scopes.
E
C
I
think
this
is
probably
again,
maybe
something
better
to
take
outside,
so
it's
quite
a
detailed
kind
of
thing
to
get
into,
but
at
the
end
it
like
I,
think
kind
of,
like
the
the
the
big
picture
is
that
procedural
macros
are
much
more
flexible
and
a
much
better
suited
for
kind
of
processing.
This
kind
of
input,
okay,.