►
Description
Project Update: Lang Team by Niko Matsakis
2021 has been a very exciting year for Rust. In addition to the upcoming release of Rust 2021, we saw the formation of the Rust foundation along with the creation of a number of teams dedicated to Rust development. Rust is even being considered for the linux kernel! Nicholas will talk about what all this means for Rust, and what we can expect to see as Rust moves ever closer to its goal of “empowering everyone to build reliable and efficient software.”
A
So
hello,
my
name
is
nicolas
matsakis
and
I
am
the
co-lead
of
the
language
design
team,
along
with
josh
triplett,
I'm
also
a
member
of
the
rest
compiler
team
working
on
rust.
For
for
a
little
while,
I
started
at
mozilla
research,
but
I
recently
joined
aws
in
january
of
this
year
and
I'm
gonna
be
telling
you
about
where
I
think
rust
is
and
where
I
think
we
should
be
going.
So,
let's
get
started
so
2021
was
quite
a
year.
A
So
it's
not
bad,
but
if
that's
not
enough,
many
of
those
companies
have
formed
teams
employing
people
to
work
on
rust,
the
language
right,
pretty
cool.
So
we've
got
a
lot
more
people
being
paid
to
work
on
rust
this
year
than
ever
before,
and
including
myself
and
one
of
those
teams,
and
if
that
is
not
enough
to
convince
you,
the
2021
is
some
kind
of
landmark
year
for
rust.
What
about
this
rust
is
under
consideration
for
inclusion
in
the
linux
kernel,
so
that's
pretty
cool
I
mean
given.
A
All
of
that,
I
have
to
ask
you:
is
this:
it
did
we
like
make
it.
Is
that
what
happened
here?
Well,
that's
an
interesting
question.
I
think
to
answer
it.
We
have
to
go
back
a
little
bit
and
say
what
was
the
ergol.
You
know
what
was
the
purpose
of
rust
when
we
started
out
it
wasn't
just
to
get
in
the
linux
kernel,
although
I'm
not
sure
I
thought
that
would
ever
happen,
but
it
was
something
different.
A
It
was
to
take
the
power
of
c
and
c,
plus
plus
right
and
put
it
in
a
package
that
has
that
great
feeling
of
javascript,
ruby
and
python
the
easy
to
use
feeling
and
and
get
the
best
of
both
worlds.
You
know
have
our
cake
and
eat
it
too.
I
used
to
say
all
the
time
and
you
can
kind
of
put
that
in
this
like
graph
form
right.
A
That's
I
see
these
kind
of
graphs
a
lot
I
think
they're
good,
so
you
got
c
plus
plus
on
the
on
the
one
side,
really
strong
performance,
but
not
always
so
easy
to
use,
and
then
you've
got
on
the
other
side,
javascript,
ruby
and
python,
which
are
really
easy
to
use.
You
can
ramp
up
really
quickly
and
get
people
started
and
there's
lots
of
people
who've
been
hired
to
work
on
your
project,
but
the
performance
while
sometimes
great
other
times,
especially
in
like
critical
code.
A
That's
isn't
what
you
need
right,
so
the
premise
of
rust
is
kind
of
bam
there.
We
are
top
right
corner
all
the
performance,
all
the
ease
of
use,
all
the
power
all
the
time
and
when
things
are
going
well,
you
know
there
are
times.
I
think
we
actually
do
achieve
that
which
is
really
cool.
So
I
recently
saw
a
blog
post.
A
A
A
Well,
at
least
they
remember
to
use
cargo
run
release.
They
say
that
other
times
they
might
complain
and
then
find
out
that
indeed
it
does
run
fast
or
they
might
say
if
that
after
they've
been
working
in
rust
for
a
while
they've
kind
of
found.
This
curious
thing
that
they've
noticed
that
once
they
get
it
took
a
while,
sometimes
to
get
things
to
compile,
but
once
they
do,
they
tend
to
work.
A
A
A
A
You're
on
the
right
path
like
in
that
terrible
blog
post,
but
using
rest,
especially
early
on
still
means
spending
a
lot
of
time,
fighting
the
borrow
checker
and
learning
the
tricks
of
the
trade
kind
of
how
to
work
around
what
that
error
message
means
and
how
error
messages
can
be
really
great,
but
sometimes
they're
really
confusing,
or
what
the
right
solution
is
to
that
particular
situation,
and
I
think
you
just
can't
claim
that
on
the
whole
rust
is
as
easy
to
use
as
javascript,
ruby
or
python.
It's
just
not
true.
A
A
I
don't
have
ready
access
to
a
chart
from
2020
the
most
recent
survey,
but
I'm
sure
the
results
are
comparable,
and
so
we
asked
people
how
long
it
took
until
they
felt
productive
using
rust,
which
is
kind
of
related
to
ease
of
use
right,
how
long
till
they
felt
productive.
You
can
see
in
this
chart
that
there's
a
good
chunk
of
people
who
get
productive
pretty
quickly.
A
This
is
sort
of
the
tenantable
case
less
than
a
month,
that's
great,
and
that
the
only
reason
that's
even
possible
trust
me
is
all
the
hard
work
that
we've
put
into
the
design
of
the
language,
of
course,
but
also
all
the
stuff
around
it.
The
error
messages
the
documentation
cargo
crates
like
without
all
that
work.
A
This
number
would
be
a
lot
a
lot
smaller,
the
number
of
people
who
get
productive
this
quickly.
Unfortunately,
you
can
see
that
for
a
lot
of
people,
getting
productive
and
rest
is
measured
not
in
weeks,
but
in
months
and
there's
a
pretty
decent
chunk
of
people
over
here
on
the
left
that
say,
they've
never
felt
productive
at
all.
Now,
when
I
read
that
I
thought
well,
I
bet
they're
all
beginners
right.
I
bet
they're
just
using
rust
for
for
a
week
or
two
wrong.
That's
not
quite
right!
A
They
might
just
mean,
like
the
libraries
they
need
are
not
there
or
the
ide
tooling,
isn't
up
to
what
they
expect.
That's
what
one
person
told
me-
and
that
might
be
true,
but
at
the
same
time
I
think
these
these
numbers
give
pause
right
room
for
concern.
If
we
want
people
to
feel
as
productive
and
rest
as
they
do
in
python,
and
I
do
we've
got
to
do
better,
the
fact
is:
russ
really
rocks
well
once
you
learn
it,
but
getting
that
done
can
be
pretty
difficult.
A
So
I
recently
heard
this
best
phrase
ever
which
describes
the
situation.
Rust
is
the
language
where
you
get
the
hangover
first,
it's
perfect
in
so
many
levels.
I
mean
first,
the
obvious
one
getting
used
to
rust.
It
takes
time
right
and
once
you're
past
that
hangover
that
you
get
up
front
and
you
get
kind
of
the
drinking
period
that
normally
comes
first,
you
get
that
then,
like
you
have
a
new
pair
of
wings
right,
you
can
build
and
maintain
ambitious
projects,
and
you
start
using
it
not
just
for
ambitious
ones.
A
I
hear
a
lot
of
people
saying
at
first,
I
used
russ
to
write
this.
You
know
powerful
thing
of
doing
the
work,
but
then
I
had
this
old
script
that
I
wrote
and
I
needed
to
modify
it
and
it
was
kind
of
annoying
and
I
wanted
a
library,
so
I
decided
to
just
rewrite
it
in
rust.
Then
I
could
use
cargo
the
code's
about
the
same
length,
but
now
it
runs
faster
than
it
did
before,
and
I'm
able
to
come
back
and
modify
it
again
and
again
without
having
to
be
afraid.
A
So
this
is
exactly
why
that
metaphor
is
awesome,
because
it
goes
the
other
way
right,
many
other
languages
or
you
know
in
practice.
What
often
happens
right
is.
It
feels
really
great
at
first
you're
writing
a
lot
of
code,
the
code's
running
really
easily,
but
then
the
hangover
comes
when
you
realize
that
there's
these
subtle
bugs
that
don't
show
up
until
after
it's
in
production
or
you
have
to
go
back
and
rework
it,
and
you
can't
find
all
the
places
you
have
to
make
a
change.
A
A
So
I
think
this
whole
setup,
you
know,
is
exactly
why
rust
keeps
winning
that
most
loved
question
on
stack.
Overflow
is
because
what
that
question
asks
is
if
you're
using
rust.
Do
you
want
to
keep
using
it
people
who
are
using
rust
once
they've
kind
of
gotten
past
that
hangover
and
they're
into
it
they're
in
that
sweet
period?
That
comes
later,
so
they
do
want
to
keep
using
rest.
A
But
you
know
that's
a
really
cool
number
we
love
to
cite,
but
if
you
look
at
the
most
popular
one,
what
languages
you
use
the
most
plus
doesn't
do
nearly
as
well
now
granted
we
come
into
five
percent
of
respondents
number
19,
which
is
way
better
than
I
ever
thought
we
were
going
to
do
when
we
started
working
on
this
project
right,
but
still,
I
think
west
deserves
to
be
a
lot
higher
in
that
list.
I
think
there's
a
whole
lot
of
projects
that
would
benefit
the
people
with
from
from
being
written
in
rust.
A
They
would
go
faster,
they
would
use
less
resources
and
they'd
be
easier
to
maintain
and
people
would
like
it,
but
they're
not
doing
that
today.
So
that
comes
back
to
my
question.
Are
we
there
yet
no
we're
not
there
yet,
but
we
have
come
a
long
way
right,
2015!
That's
when
we
did
our
1.0
release.
That
was
basically
the
hey.
We
showed
rust
cam
work.
What
had
seemed
like
a
pie
in
the
sky
research
effort
was
being
used
to
ship
production
systems.
A
A
How
do
we
get
resting
to
widespread
usage?
Well,
you
do
the
rust
evangelism
strike
force,
because
that
works
great.
No,
I
think
you
know
going
out
and
hectoring
people
into
using
rust
isn't
probably
going
to
do
the
trick.
I
think
we
need
a
different
approach.
So
what
about
this?
What
if
we
said
a
goal
for
ourselves
instead
of
taking
six
months,
which
is
a
common
number
right
here
for
people
to
feel
productive
and
rest?
What
if
we
could
make
it
so
that
they
felt
productive
in
six
weeks
or
even
less?
A
A
I
think
it
would
be
transformative
and
I
think
we
can
do
it,
but
we
have
to
really
up
our
game
right.
We
have
to
approach
it
very
deliberately
and
there's
gonna
be
a
couple
of
things
we
have
to
do
so.
One
of
them
is
two
that
listed
here
to
start
so
we're
gonna
have
to
be
focused
and
we're
gonna
have
to
be
really
creative.
A
So
when
I
say
focused
what
I
mean
is
we've
gotta
keep
our
eye
on
the
ball
on
the
goal
of
making
rest
easier
to
use
shorter
time
to
productivity,
without
sacrificing
all
the
things
that
make
russ
great
right.
If
we
just
end
up
turning
rust
into
another
language
that
that
no
nobody
wins,
so
I
think
the
way
we
should
approach
this
is
we
need
to
identify
the
ways
that
we
want
rust
to
feel
I've
given
three
here
there
are
some.
A
A
Then
I
think
we're
gonna
find
we're
doing
better
and
if
we're
it's,
not
that's
where
the
creativity
part
comes
in
right,
we're
trying
to
get
a
delicate
balance
of
exposing
a
lot
of
complexity
in
a
really
simple
way,
and
it's
really
hard
and
we
have
to
think
hard
and
we
have
to
try
a
lot
of
different
approaches
before
we
actually
are
able
to
do
it.
So
you
know
we
need
to
both
be
focused
on
what
we
need
to
do
and
be
creative
in
the
ways
we
go
about
doing
it,
okay.
A
So
what
else?
Well,
we
need
to
think
broadly,
by
which
I
mean
we
have
to
look
at
the
experience
of
using
west
holistically.
Look
at
all
the
things
users
are
trying
to
do
and
figure
out
how
to
make
sure
that
all
the
pieces
they
need
to
do
those
things
are
there,
even
though
a
lot
of
those
things
aren't
going
to
be
under
our
direct
control,
not
the
language
proper
or
the
standard
library
right.
So
actually
we
can
give
a
good
example.
A
If
we
go
back
to
that
blog
post,
I
started
out
with
the
one
from
tenable
where
they
reduce
their
resource
usage.
If
you
look
at
their
blog
you're
going
to
find
that
before
that
post
came
another
post,
one
where
they
were
evaluating
rust
and
deciding
whether
to
use
it,
it's
a
nice
read,
it's
called
building
a
microservice
with
rust
and
one
of
the
things
that
I
liked
about
it
was
they
went
through
what
are
all
the
pieces
of
the
puzzle.
A
They
need
to
build
a
typical
microservice
right,
so
here
they
have
a
clear
goal:
they're
going
to
build
this
service
and
they
need
an
http
api
code
to
work
with
the
database
code
to
read
messages
from
the
queue,
a
docker
file
and
so
on,
and
you
can
see
how
they
found
most
of
those
pieces
and
some
of
them
they
had
to
kind
of
cobble
together
with
some
scripts
and
other
stuff.
And
that
gives
you
a
clue.
Well,
maybe
that's
a
missing
piece
right.
A
That's
something
that
if
you
didn't
know
what
to
do,
you
might
get
stuff,
and
if
we
want
to
push
productivity
down
to
a
few
weeks,
we
need
to
make
sure
that
all
those
pieces
actually
are
there
and
are
documented,
and
that
includes
like
kind
of
glue
code
like
or
libraries
like
I
just
talked
about,
but
also
things
like
documentation,
ide
integration
and
debugging
support,
so
learning
ownership
and
borrowing.
Now
that's
always
going
to
take
some
time,
but
the
rest
of
that
stuff
we
can
definitely
solve.
A
A
So
if
you
want
new
results-
and
I
do
you've
got
to
do
new
things
right-
here's
a
list
of
things-
we've
never
done
mostly
for
good
reasons.
I
will
say-
and
I
think,
though,
we're
going
to
have
to
revisit
and
take
a
careful
look
at
our
hard
lines
and
our
fixed
assumptions
of
things
that
we
know
are
a
bad
idea
and
try
to
try
to
reevaluate
them
in
terms
of
those
experiences.
Are
we
really?
A
A
A
The
idea
of
an
addition
is
simple:
every
crate
declares
what
rust
edition
it's
going
to
use
so
in
west
2015,
that's
kind
of
the
1.0
release,
rush,
2018
and
soon
to
be
rush,
2021
and
no
matter
which
edition
you're,
using
your
crate
interoperates
with
all
the
other
editions
and
all
the
other
crates
right.
Additions
are
an
internal
implementation
decision.
They
don't
affect
your
avi
or
your.
They
know
they
don't
affect
your
api.
They
also
don't
affect
your
api
right
and
even
better.
A
A
This
is
just
get
access
to
newer
and
better
rust
and
what
we
use
additions
for
is
to
make
targeted
improvements
that
make
rust
easier
to
use,
and
it's
often
the
kind
of
stuff
that
you
probably
wouldn't
even
realize
it
changed
it's
just
that
there
were
corner
cases
that
made
it
impossible
for
us
to
to
improve
rust
in
a
way
we
wanted
to,
unless
we
were
willing
to
tweak
the
rules.
So
here's
an
example
of
something
like
that
today
in
rust,
when
you
have
closures,
they
always
capture
an
entire
local
variable.
A
I
know
those
little
workarounds
won't
be
necessary,
but
making
this
change
did
require
us
to
use
an
addition
because
it
can
affect
when
destructors
run
when
memory
gets
free,
other
subtle
things.
So
I
want
to
just
give
a
big
shout
out
to
the
rsc2229
project
group
for
their
hard
work
on
this.
They
were
really
persistent
and
they
saw
it
through
and
it's
going
to
be
awesome
now.
Here's
another
example.
A
This
is
not
a
subtle
change
that
you'd
never
notice,
but
it's
a
pretty
cool
feature
that
doesn't
really
break
much
stuff
and
mostly
just
works,
except
for
the
occasional
corner
case,
which
is
that
we
used
to
allow
or
we
now
we
used
to
require
you
to
put
variables
outside
of
the
placeholder
like
this,
when
printing
and
soon
not
yet,
but
we
will
allow
you
to
just
put
them
in
line.
This
is
actually
going
to
work
on
all
the
additions.
A
The
problem
that
we
had
to
use,
in
addition
for,
is
that,
when,
in
certain
places
of
like
panicking
accepted
straight
cert,
certain
rather
dubious
things
used
to
be
accepted
in
work
around
panicking
and
we
had
to
to
change
those
semantics
a
little
in
additions.
Let
us
do
that,
so
that's
really
great
and
shout
out
tomorrow
for
making
that
happen.
Use
it
epic
effort-
and
I
don't
have
time
to
go
through
all
this
stuff
in
the
edition.
But
let
me
just
call
out
a
bunch
of
people
who
contributed.
A
What
do
we
do
happens
that
this
very
question
was
facing
us
earlier
this
year
earlier
this
year,
as
we
thought
about
how
to
approach
async
rest,
so
you
may
recall
that
in
2019
we
shipped
the
async
await
mvp,
invest.
This
was
a
huge
achievement.
The
design
was
really
cool
and
the
implementation
had
gotten
done
and
we
were
ready.
It
had
taken
many
years,
but
we
were
ready
to
see
it
come
into
practice
and
in
the
time
since
I
think
we've
been
validated
for
all
the
effort
we
put
into
it.
A
There's
more
and
more
uses
of
async
west
and
we've
had
a
lot
of
time
to
gain
up
quite
a
lot
of
experience,
and
we
now
you
know
it's
time
to
look
past
that
mvp
and
see
what
do
we
really
want
asyncrust
to
be?
What
are
the?
What
is
the?
How
can
we
make
asynchronous
team
reliable,
efficient
performance?
What
does
the
full
feature
look
like
and
the
problem
is
there's
such
a
huge
range
of
possibilities
right
and
so
many
variations
to
explore
so
many
ways
it
could
be.
A
So
I
raised
this
question
with
shane
miller,
who
works
on
the
aws
rust
team
and
she
shared
with
me
some
of
the
approaches
she'd
used
to
do
similar
drives
within
amazon
and
elsewhere
in
the
past,
and
I
thought
it
was
pretty
cool.
So
the
idea
was
basically,
you
start
out
with
an
in-depth
examination
of
the
status
quo.
A
What's
it
like
to
use
async
quest
today
and
get
detailed,
and
you
find
out
what
problems
people
want
to
solve
today,
what
problems
they
are
solving
and
the
challenges
that
they
face
in
doing
so,
and
these
challenges
are
often
not
in
the
area,
as
you
think.
It's
a
really
simple
example.
When
I
discuss
asymptotes
with
working
programmers
oftentimes.
The
first
thing
that
they
talk
about
is
what
ide
should
I
use
or
how
well
does
the
debugger
work
or
not
work
right?
A
How
much
raw
assembly
do
I
have
to
deal
with
when
I'm
debugging,
that
stuff
is
totally
independent
from
async
rest,
but
it's
still
a
blocker
to
adoption
right,
it's
what
stops
them
from
feeling
productive.
So
it's
totally
relevant
anyway,
once
you
get
a
good
handle
on
the
status
quo,
you
start
to
think
about
the
shiny
future.
The
idea
is
to
go
back
through
those
status
quo
stories
of
what
people
were
trying
to
do
and
what
problems
they
hint
and
reimagine.
A
How
could
it
be
right,
and
that
brings
you
to
first,
you
start
out
with
what
you
want
it
to
be
like
and
you
go
backward
and
think
what
are
the
steps
if
I
had
a
feature
that
did
something
like
this,
I
could
have
that
happen.
How
could
I
get
a
feature
that
goes
somewhere
like
that?
Let
me
go
backwards
further.
Until
you
have
a
path
right,
maybe
a
shaky
and
unreliable
path,
but
a
path.
A
That's
going
to
take
you
into
a
really
awesome
experience,
so
we
did
this
for
async
rust
and
we
just
we
were
trying
to
figure
out.
How
can
we
approach
this
in
an
open
source
way
right
so
tyler
mandy
and
I
led
the
async
foundations
working
group
and
what
we
did
was
we.
We
did
this
collaborative
effort,
so
it
wasn't
just
just
one
person
drafting
it,
but
rather
we
went
out
and
we
consulted
sorry
keep
my
slide
there.
A
We
consulted
the
community
sort
of
pretty
broadly
for
ideas
about
the
status
quo
about
the
shiny
future.
When
we
ran
sessions
where
we
had
people
come
in
and
like
join
us
with
a
hack,
md,
a
shared
hackmd,
and
we
would
write
stories
together
that
worked
in
all
the
experiences
of
the
people
in
the
call.
Sometimes
we
went
and
talked
to
companies
or
in
private
conversations
to
get
a
feeling
for
how
they
were
using
it,
the
things
that
they
made.
A
You
know
in
building
their
own
software
so
and
out
of
all
that
we
kind
of
developed
this
picture
of
what
the
shiny
future
and
status
quo
look
like
right,
and
I
want
to
talk
to
you
a
little
bit
about
that.
So
we
we
started
out
with
some
of
the
basic
experiences
right
in
terms
of
thinking
about
the
shiny
future
of
how
asyncrust
should
feel
in
a
year
or
two
and
one
thing
is:
it
should
be
consistent
right.
You
should
be
able
to.
A
Basically,
if
you
know
synchronous,
rest
learning
asynchronous
should
be
as
simple
as
adding
some
async
awaits
and
taking
advantage
of
a
bunch
of
new
capabilities,
the
smaller
we
can
keep
the
gap
between
them,
the
easier
it
will
be
to
move
from
one
to
the
other.
Now
in
practice,
what
we
found
is
that's
not
always
true
right,
so
we've
there
has
been
a
lot
of
effort
to
keep
them
analogous,
but
some
things
are
more
different
than
it
seems
like
they
should
be
so
take,
for
example.
This
is
this
is
an
iterator
trait.
This
is
not
async.
A
It's
standard,
rust,
synchronous,
rust.
It
requests
the
next
item
and
takes
ownership
of
it.
And
if
you
look
at
the
async
version,
that's
currently
in
nightly,
you
see
it
looks
pretty
different.
It's
got
a
different
name,
it's
called
stream
and
its
method
doesn't
isn't
called
next.
It's
called
poll
next
and
it
uses
this
thing
called
a
pin
and
what
it
does
is
it
basically
asks.
Is
the
next
item
ready
and
if
so,
gets
it
and
otherwise
says
no,
it's
not
ready
right,
which
is
the
underlying
mechanism
that
you
use
to
implement
futures.
A
So
it's
kind
of
exposing
this
this
abstraction
up.
If
you
want
to
implement
this
trait,
you
have
to
understand
futures
all
the
way
down
now
what
we'd
like
to
get
to-
and
we
think
we
will
get
to-
is
this
async
iterator
trait,
which
looks
pretty
much
exactly
like
the
synchronous,
iterator
trait,
except
it
has
the
keyword
async
right
well
that
fulfills
our
experience
that
we're
looking
for
and
getting
there
is
going
to
require
implementing
a
bunch
of
interesting
stuff,
much
of
which
is
already
underway
and
has
long
been
desired.
A
Like
type
laa's
impetus,
generic
associated
types,
but
the
end
result
is
going
to
be
this
really
simple
experience,
which
is
great
and
here's
another
example.
This
one
has
to
do
with
looking
beyond
the
boundaries
of
the
language
at
all
the
things
that
people
need
for
the
full
life
cycle
of
what
they're
trying
to
do.
A
So
you
can
use
kind
of
c
based
tooling,
which
has
its
flaws,
but
you
know
things
like
perf
and
so
on
to
analyze
performance
and
it
works
pretty
well,
but
with
asyncrust
the
user
space
scheduler
has
a
whole
lot
of
concepts
like
tasks
and
channels
that
aren't
understood
by
the
runtime
and
it's
really
hard
to
visualize
them,
and
that
makes
it
hard
to
debug
problems.
It
also
makes
it
hard
to
do
things
like
gain.
Get
live,
metrics
of
your
services
that
are
in
production,
which
a
lot
of
people
like
to
do
so.
A
Fortunately,
there's
a
lot
of
effort
within
the
ecosystem
itself
to
address
this
need
right,
so
tokyo,
for
example,
eliza
wiseman
is
building
this
really
cool
thing.
Called
tokyo
console
it's
kind
of
giving
you
a
top-like
view
of
all
your
asynchronous
tasks
and
it's
going
to
get
extended
in
various
ways.
A
Well,
I'll
get
to
that
interesting
thing
in
a
second,
so
there's
some
more
things
in
the
vision,
doc
that
I
don't
have
time
to
go
into.
You
should
definitely
check
it
out
if
you'd
like
to
read
it
so
we've
got,
for
example,
apis
to
go
across
runtimes
and
spawning
tasks,
and
so
on
it's
going
to
be
pretty
cool
future,
so
that
that
other
thing
I
wanted
to
mention,
I
it's
kind
of
a
general
point.
A
If
we
fail
you
know,
then
we
haven't
hit
that
upper
right
corner
that
we're
shooting
for
and
but
what
I
found
in
practice
is
that
this
tension
between
easy
to
use
and
exposing
power-
it's
very
real,
but
it's
also
very
surmountable,
and
when
you
do
it,
you
get
a
kind
of
better
for
everyone
feeling
and
work
on
that
goes
to
benefit.
One
group
usually
winds
up
benefiting
all
the
groups.
A
If
you
do
it
right,
but
the
console
project
is
actually
an
interesting
example
of
this,
because
it
started
out
as
an
effort
to
help
people
who
already
had
services
kind
of
going
into
production
or
who
are
debugging
their
really
complex
asynchronous.
So
they
already
know
asyncrest
and
they
need
help
debugging
it
right.
A
It's
like
a
late
stage
feature,
but
what
we
found
when
we
well,
I
didn't
do
these
demos
didn't
say
we,
but
what
I've
heard
from
people
who
were
doing
demos
is
that
just
seeing
the
set
of
of
tasks
help
people
to
understand
the
model
better,
so
it
becomes
also
a
teaching
tool
right.
It
was
targeting
late
stage,
but
it's
useful
for
early
stage
and
definitely
I
think
anyone
who
enjoys
the
ease
of
use
that
russ
already
offers
knows
that
focusing
on
early
stage
also
benefits
late
stage.
A
A
So,
instead
of
being
the
go-to
language
for
critical
systems,
rust
is
going
to
be
the
go-to
language
for
anything
running
in
the
cloud
embedded
devices
and
all
kinds
of
things,
things
where
reliability
counts
right
and
if
we
do
that,
what
would
that
be?
Like
it'd,
be
pretty
great,
but
we've
always
found
we're
going
to
have
more
people.