►
From YouTube: RustConf 2020 - Bending the Curve: A Personal Tutor at Your Fingertips by Esteban Kuber
Description
Bending the Curve: A Personal Tutor at Your Fingertips by Esteban Kuber
Rust is a language known for speed and security kept behind a hard learning curve, caused by one of its unyielding goals of being a flexible systems language. By taking teachings from other domains and understanding the design constraints of the language semantics are not the entirety of the UX of a compiler, it manages to also empower everyone to build reliable and efficient software without compromises. Lets have a conversation with rustc.
A
Hi,
I'm
stephen
cuber
a
software
engineer
at
premier
and
a
member
of
the
ras
compiler
team.
I
will
be
talking
about
what
rust
can
do
to
improve
its
learnability
beyond
changing
the
language
itself,
but
first
I
want
to
address
the
name
of
the
talk.
I
chose
it
late
last
year
before
our
current
situation
and
because
I'm
a
bit
slow,
I
didn't
realize
how
topical
it
has
become
until
after
it
has
been
accepted
and
published.
A
Secondly,
while
I
was
expanding
the
outline
of
this
talk
into
draft,
I
realized
that
the
topics
I
was
talking
about
were
way
more
general
than
just
rust
because
of
these
two
things.
If
I
were
to
change
the
title
of
this
talk,
it
would
be
closer
to
so
you
want
to
make
a
programming
language
that
people
use.
A
A
You
will
rely
on
one
of
broadly
speaking,
three
tools
and
strategies.
First,
you
will
have
access
to
a
map
which
is
a
simplified
graphical
representation
of
a
physical
space.
It
lets
you
get
your
bearings
find
where
important
places
are
and
help
you
get
there
with
it.
You
can
know
that
the
firefighter
station
is
450
meters
away
from
your
house
as
the
crow
flies,
but
it
won't
tell
you
that
the
sidewalk
in
front
of
it
is
broken,
so
you
have
to
watch
your
step
around
there.
A
A
It's
two
blocks
down
the
street
next
to
the
red
house
and,
finally,
you
may
check
out
a
travel
guide
or
talk
to
a
neighbor
or
friend.
That
already
knows
the
city
they
may
let
you
know
about
things
that
would
otherwise
take
you
a
long
time
to
find
out
about
like
telling
you
if
you
go
three
blocks
the
other
way.
There
is
a
pizza
place
that
is
more
expensive,
but
it's
the
best
pizza
in
town
or
they
will
let
you
know
about
things
in
advance.
That
would
be
annoying
or
inconvenient
to
find
out
yourself
like.
A
What
they
are
doing
is
using
their
lived
experience,
extrapolate
what
they
know
about
you
and
your
lived
experience
and
cut
to
the
chase
to
discuss
the
areas
that
are
different
from
what
you
may
be
used
to.
Instead
of
starting
from
scratch
and
explaining
what
the
street
is,
the
experience
of
learning
a
programming
language
can
be
very
similar.
A
Other
people
are
more
hands-on,
particularly
people
that
have
read
that
already
know.
One
or
more
other
languages
are
ready.
They
may
need
a
brief
introduction
and
then
start
trying
things
out
through
this
trial
and
error.
They
will
be
building
a
mental
map
of
the
language
identifying
where
their
previous
knowledge
applies
and
where
it
diverges
in
the
new
language
when
moving
from
a
language
to
another.
That
follows
the
same
particular
programming
paradigm.
A
A
Finally,
some
people
will
seek
out
help.
This
can
be
in
the
shape
of
a
book
targeted
at
people
learning
the
language
in
some
cases
aimed
at
people
from
very
specific
backgrounds
or
through
the
reliance
on
online
communities,
or
even
hiring
a
teacher
to
teach
you
the
language
when
doing
this,
regardless
of
medium.
The
people
on
the
other
side
will
try
to
identify
what
your
current
level
of
familiarity
with
the
subject
is
what
you
already
know
in
order
to
minimize
the
time
needed
to
get
you
up
to
speed
and
productive.
A
A
You
may
want
to
prioritize
runtime
and
design
flexibility,
but
this
priority
will
almost
assuredly
restrict
how
performance
your
language
could
be.
You
could
decide
to
prioritize
final
execution
speed,
but
that
may
require
you
to
sacrifice
compilation,
speed
or
restrict
how
dynamic
your
software
can
easily
be
made
at
runtime.
A
A
A
A
Very
rarely
someone
goes
out
of
their
way
to
make
their
product
harder
to
use
beyond
the
objectives
of
the
language.
There
are
different
parts
of
what
makes
a
language
first
and
most
visibly.
You
have
the
chosen
syntax
and
grammar
of
the
language,
which
is
what
you
can
write.
What
the
code
looks
like
a
lot
of
conversations
go
on
at
length
about
syntax,
as
if
it
were
the
most
important
part
of
any
language.
A
Cue
async
await
syntax
conversation
in
the
comments
I
consider
parsing
and
syntax
to
be
the
least
interesting
part
of
any
language,
as
it
is
mostly
a
solved
problem
that
requires
little
effort
in
both
design
and
implementation
model
of
things
like
malformed
code
recovery,
particularly
when
put
in
contrast
with
the
rest
of
the
compilers
functions
and
the
language
design
space
using
square
brackets
instead
of
less
than
more
than
for
generics.
To
give
an
example,
has
little
impact
on
the
experience
of
writing
the
language,
although
it
can
have
huge
implications
on
the
compiler's
implementation
and
error
recovery.
A
A
A
If
you
have
used
rust,
you
have
already
noticed
that
this
is.
This
is
very
much
part
of
its
design,
from
the
plural
checker
through
the
non-representability
of
null
to
immutability
by
default,
when
it
comes
down
to
it,
features
are
sometimes
foundational
stuff
common
to
all
or
most
languages
like
being
able
to
bind
a
local
variable
or
while
loops
or
formalizing
existing
patterns
into
the
language
like
message
passing
or
first
class
functions,
regardless
anyone
learning
your
new
language
and,
in
our
case
rust,
will
have
to
internalize
rules
from
those
three
buckets.
A
If
they
come
tabula
rasa,
you
can
ignore
prior
art
and
do
anything
you
think
will
be
best
for
them,
but
in
reality
a
lot
of
people
will
be
coming
from
other
already
existing
languages,
and
there
are
so
many
languages
out
there
that
you
can
learn
a
lot
from
or
still
if
you
prefer,
with
the
benefit
of
hindsight,
for
all
the
complaints
about
the
breakneck
change
in
rust.
I
believe
it
is
a
boring
language.
A
A
A
Somebody
who
speaks
spanish,
for
example,
will
have
a
relatively
easy
time.
Learning
portuguese.
There
is
no
one-to-one
mapping
for
every
grammatical
construct
and
rule,
but
due
to
their
shared
heritage,
applying
rules
from
spanish
to
portuguese
will
be
correct.
More
often
than
not
picture
instead,
if
a
japanese
person
wanted
to
learn
norwegian
as
beautiful
as
norwegian
may
be
due
to
those
two
languages
sharing
no
common
root,
this
person
will
be
having
to
start
from
scratch,
which
can
be
a
much
more
frustrating
experience.
A
Quick
aside,
I
have
the
unsubstantiated
theory
that
experienced
developers
have
a
harder
time
than
less
experienced
developers
when
learning
rust.
They
need
to
forget
a
lot
of
constructs
that
work
well
enough
in
the
languages
they
already
know
because
they
introduce
things
that
go
against
the
single
owner
enforcement.
That
rastas,
whereas
somebody
with
less
experience
will
simultaneously
accept
restrictions
as
just
the
way
it
is
and
not
seek
out
other
more
performant
constructs
that
can
be
much
harder
to
understand
or
implement.
A
Breast
has
a
curse.
It
has
many,
but
this
one
is
critical.
Inefficient
code
is
generally
visible,
experienced
developers
hate
to
notice
that
their
code
is
inefficient.
They
will
recall
at
seeing
arc
of
ref
cell
of
t,
but
they
won't
bite
an
eye
at
using
python.
I
know
because
I
have
the
same
instinct.
A
A
A
A
A
The
available
libraries
documentation,
tooling
platform
support
and
the
surrounding
community
all
affect
how
easy
it
is
to
learn
a
language
and,
as
importantly,
how
likely
people
are
to
stick
around
going
back
to
my
original
analogy.
Moving
to
a
new
place
is
not
a
single
decision
in
time.
In
fact,
every
day
you
reaffirmed
your
decision
to
stay,
even
if
possibly,
if
you
had
infinite
resources,
you
could
improve
the
learnability
of
your
language
change
the
slope
of
its
learning
curve
by
providing
every
single
newcomer
with
a
personalized
tutor.
A
A
It
was
positive
that
you
could
take
a
handful
of
really
experienced
people,
pick
their
brains
and
encode
their
thinking,
mental
model
and
decision
making
process
and
use
that
as
the
basis
of
software
used
by
other
less
experienced
people.
This
way
you
could
get
the
benefits
of
an
expert
at
a
fraction
of
the
cost
to
train
one.
A
If
you
look
at
most
ecosystems,
ideas
are
not
as
an
optional
separate
tool
from
the
compiler
in
javaland.
You
have
a
plethora
of
options
to
choose
from
from
google,
to
pretty
amazing
in
the
microsoft.net
ecosystem.
Talking
about
the
ide
visual
studio
and
the
compiler
as
separate
entities
is
making
a
distinction
without
the
difference.
A
The
compiler
is
so
deeply
embedded
in
the
ide
that
they
are
one
and
the
same.
But,
as
I
said
earlier,
ides
are
focused
on
productivity,
not
learnability.
We
could
create
a
new
tool
to
act
as
a
tutor
apply.
The
idea
of
expert
systems
to
the
teaching
of
a
language,
but
when
you
introduce
a
new
tool,
you
have
the
problem
of
discoverability
the
people
that
may
need
it
most
will
never
find
out
about
it.
A
A
A
A
Efficiency
of
generated
code
is
important,
but
it
is
a
well
explored
space
with
decades
of
research
and
applied
techniques.
At
the
same
time,
emitting
good
diagnostics
is
hard
because
it
requires
a
lot
of
foresight
and
effort.
Diagnostic
errors
touch
upon
every
single
part
of
the
language.
From
how
easy
it
is
to
write
typos
that
look
like
word
from,
but
nonsensical
code
to
parsing
errors
that
are
carried
forward
to
later
stages
of
the
compiler
compounding
as
they
go
along.
A
Unless
you
make
it
a
priority,
the
developer
experience
will
always
be
subpar,
communicating
with
a
user
to
get
them
to
that
generated.
Binary
is
at
least
as
important,
and
in
my
eyes
it
is
more
important
than
any
other
task.
The
compiler
is
asked
to
do
and
when
we're
emitting
diagnostic
errors
is
the
perfect
place
and
moment
to
teach
people,
they
have
made
a
mistake
and
we
can
explain
to
them
why
they've
made
it
think
about
what
I'm
talking
about
what
the
possibilities
with
the
possibilities
we
have
here
consider
the
kind
of
errors
that
people
see.
A
A
There
is
quite
a
bit
of
research
on
how
to
detect
these
errors
automatically
and
identify
what
the
user's
original
intent
was.
But
if
you
have
enough
users
reporting
bugs
and
enough
developers,
you
can
get
quite
far
with
simply
identifying
common
and
problematic
errors
and
handling
them
proactively.
In
the
parser
we
can
detect
small
incorrect
usages
an
example
I
always
come
back
to
is
type
ascription.
A
Other
more
pervasive
errors
are
what
I
call
negative
space
boundary
errors.
I've
taken
to
interpreting
the
negative
space
of
a
language
as
the
area
outside
of
a
language,
valid
grammar,
consider
a
cartesian
area.
Everything
inside
of
that
boundary
is
valid.
Rust.
Everything
outside
of
that
boundary
is
all
possible
implementations
of
text.
A
That's
how
the
rust
grammar
sees
the
world,
but
we
aren't
like
that
with
healing
shades
of
grey.
There
is
code
that
lies
right
on
the
wrong
side
of
that
boundary.
That
would
look
to
a
human
as
correct.
It
could
be
code
that
breast
explicitly
doesn't
support
for
some
specific
reason.
A
reasonable
person
may
be
extrapolating
from
rules.
They
have
already
internalized,
if
not
fully
learned
or
relying
on
rules
from
other
languages
that
don't
apply
to
rust
and
lander.
A
But
the
interesting
thing
is
that
we
can
proactively
search
for
these
cases
or
at
least
watch
people
land
in
those
places.
This
is
not
an
original
idea.
Other
types
of
software
products
conduct
user
research
all
the
time.
Looking
at
how
people
fail
to
use
their
products
and
once
they
have
identified
things
reasonable
people
may
do,
we
can
make
the
compiler
handle
them
even
when
they
are
features
that
can't
be
included
in
language,
because
we
can
make
the
compiler
infer
intent.
A
One
problem
you
may
envision
with
that
approach
is
that
a
tutor
needs
to
have
some
knowledge
of
their
duty
to
give
them
short
relevant
explanations,
as
you
can
imagine,
writing
a
compiler
with
that
level
of
knowledge
of
the
user
would
be
difficult
for
a
non-google
entity
and
even
then,
but
the
compiler
has
context
of
what
the
error
was
for
problems
off
the
beaten
path,
but
with
a
high
degree
of
intent.
We
can
assume
that
the
user
knows
what
they
are
trying
to
accomplish.
They
just
don't
know
how
to
do
it
in
rest.
A
You
need
to
have
a
lot
of
confidence
when
guiding
the
user,
though,
because
misleading
users
can
have
dire
consequences.
For
example,
people
with
less
experience
may
treat
the
compiler
as
an
all-knowing
oracle.
When
the
oracle
is
wrong,
they
get
very
confused
for
common
problems
like
typos.
We
don't
need
to
give
too
much
of
an
explanation.
A
A
We
have
to
explain
the
ownership
mode,
auto
referencing,
the
distinction
between
the
hip
and
the
stack
unicode
code
points,
and
we
haven't
even
mentioned
null
terminated
strings
os
string
path
back
of
u8
back
of
char
utf-8,
utf-16
utf-32,
seismic
or
lifetime.
Yet,
if
you
knew
where
the
user
is
coming
from,
we
could
explain
to
a
c
developer
that
the
string
is
like
a
non-null
terminated
string
in
their
binary
to
a
c
plus
plus
developer.
A
We
provide
a
strong
description
of
the
problem
that
gives
you
just
enough
information
to
tell
you.
There
is
a
reason
for
the
supplied
code
not
to
be
accepted
in
other
code.
In
other
cases,
we
would
even
weave
a
bunch
of
shargan
in
the
description
on
purpose
to
feed
you
words
that
you
can
search
for
this
way.
People
are
slowly
learning
some
of
the
rules,
sometimes
sometimes
by
inference
and
sometimes
being
outright
told
about
them.
A
An
example
of
teaching
one
relevant
can
be
when
wanting
to
return
something
that
implements
a
trade
without
caring
about
the
actual
underlying
type.
A
last
newcomer's
first
instinct
could
be
to
directly
return
it
and
just
set
the
return
type
to
the
to
trade
currently
inundate
doing
so
currently
inundates
the
output
with
a
bunch
of
different
errors.
A
A
We
introduce
people
to
a
potentially
new
feature
for
them
and
even
include
a
link
to
the
documentation
they
can
read
up
on
the
compiler,
actually
checks
that
the
suggestion
would
actually
work.
It
checks
that
the
involved
types
could
work
with
a
new
return
type
with
slightly
different
output.
Where
infiltrate
wouldn't
work
directly,
we
still
give
a
bunch
of
unnecessary
errors,
but
we
also
explain
why
infiltrate
won't
work
and
provide
the
user
a
bunch
of
alternatives
in
this
case
using
a
box
trade
object
or
an
enum,
along
with
some
example
code
that
they
can
directly
use.
A
All
of
this
lets
us
get
around
the
lack
of
support
in
the
language
for
unsized
return
types,
while
unblocking
the
user,
without
forcing
them
to
visit
a
forum
to
ask
for
help,
of
course,
someone
that
already
knows
they
can't
return
and
box
trades
directly.
May
trade
may
try
to
avoid
the
heap
allocation
cost
and
try
to
return
a
borrow,
but
not
know
or
forget
that
the
lifetime
has
to
be
related
somewhere.
A
I
showed
that
my
co-workers
asked
me
for
help
for
a
given
problem
once
and
then
I
ran
and
code
the
explanation
in
the
compiler
if
the
compiler
has
been
helpful
to
you
in
the
past,
feel
free
to
ask
to
thank
my
co-workers,
but
once
you
have
gone
this
direction
of
providing
suggestions,
you
can
go
wild.
I
mean
if
you're
already
parsing
a
meta
language,
let's
call
it
plus
plus
plus.
A
A
A
There
is
no
need
for
advanced
behavior
in
the
compiler
that
decides
whether
to
use
static
or
dynamic
dispatch
on
a
method
call
depending
on
some
internal
heuristics.
The
behavior
is
laid
bare
in
the
code
and
its
performance
characteristics
will
not
change
from
from
under
you
due
to
some
unrelated
code
changes
crossing
some
threshold.
A
I
also
believe
strongly
that
dedicating
manpower
to
improving
the
user
experience
of
developer
tools
is
of
paramount
importance.
It
is
quite
amazing
to
me
what
we
have
come
to
expect
from
our
tools.
User
experience,
it
seems,
like
our
entire
industry,
has
had
stockholm
syndrome
for
so
long
that
we
don't
even
notice
anymore.