►
From YouTube: 2021-06-21 Cross Team Collaboration Fun Times (CTCFT)
Description
Agenda:
Welcome
About the social hour -- yaahc
yaahc will present her plans for a social hour that follows the CTCFT (see below).
Turbowish and Tokio console -- pnkfelix and Eliza (hawkw)
Rust programs are known for being performant and correct -- but what about when that's not true? Unfortunately, the state of the art for Rust tooling today can often be a bit difficult. This is particularly true for Async Rust, where users need insights into the state of the async runtime so that they can resolve deadlocks and tune performance. This talk discuss what top-notch debugging and tooling for Rust might look like. One particularly exciting project in this area is tokio-console, which lets users visualize the state of projects build on the tokio library.
Rust Design Principles -- nikomatsakis
As Rust grows, we need to ensure that it retains a coherent design. Establishing a set of "design principles" is one mechanism for doing that. Each principle captures a goal that Rust aims to achieve, such as ensuring correctness, or efficiency. The principles give us a shared vocabulary to use when discussing designs, and they are ordered so as to give guidance in resolving tradeoffs. This talk will walk through a draft set of guiding principles for Rust that nikomatsakis has been working on, along with examples of how they those principles are enacted through Rust's language, library, and tooling.
A
So
welcome
to
the
second
ctcft
I
almost
said
second
annual,
but
that
would
be
wrong.
That's
just
the
phrase
that
comes
to
mind.
So
today
we
got
an
exciting
agenda.
We
have
so
I'm
gonna
talk
for
a
little
bit,
not
that
long
and
then
jane's
gonna
talk
about
how
the
social
hour
thing
is
gonna
work,
which
is
this
experiment,
we're
gonna,
try
and
then
felix
analyzer
I'll
talk
about
turbo
ish
and
the
tokyo
console
I'll
talk
about
this
work.
A
A
A
Okay,
so
here's
how
it
works.
First
of
all,
we're
all
being
recorded.
Keep
that
in
mind.
Secondly,
if
you
want
to
talk,
you
can
josh
is
monitoring
the
speaker
queue.
You
can
just
type
into
the
chat
like
a
little
wave
icon
or
whatever
and
I'll
put
your
name
on
the
list.
You
can
take
yourself
off,
try
to
keep
it
orderly.
A
I
think
it
often
works
well.
If
people
keep
their
video
off
unless
they're
expecting
to
speak
so
that
at
least
when
zoom
is
cooperating,
it
kind
of
floats
all
the
people
who
are
talking
up
to
the
top
and
you
can
just
see
them
but
stay
muted
when
you're
not
talking
and
please
don't
have
really
long
conversations
in
the
chat,
because
it's
really
confusing.
A
A
B
A
B
A
B
So
in
that
thread,
if
you're
interested
in
any
of
the
ideas
just
put
a
thumbs
up,
react
on
it
and
then
next
slide,
you
know,
that's
that's
pretty
much
all
of
it.
It's
not
very
complicated.
When
the
when
the
regular
meeting
is
finished,
I
will
create
the
breakout
rooms
and
then
we'll
hang
out
and
see
how
it
goes
so
next
slide
next
slide.
Oh
no,
sorry!
Pretty
soon,
I
did
not
realize
you
hit
next
for
some
reason.
B
Yes,
so
the
goal
of
the
social
hour
is
just
to
have
fun
not
really
until
I
can
do
work
stuff.
So
a
lot
of
the
ideas
are
kind
of
like
focused
on
rest
things,
the
suggestions,
but
that's
just
because
that's
what
we
came
up
with,
not
because
the
goal
is
to
do
any
sort
of
work,
so
it
can
be
as
structured
or
as
unstructured
as
you
want.
You
know
it's
just
a
place
to
chat
and
then
next
so
like
examples
that
we
put
in
is,
you
know
like.
B
I
want
to
break
out
room
talk
about
my
favorite
unstable
features
or
you
know,
talk
about
a
pool
crate,
I'm
working
on
or
you
can
just
you
know,
hang
out
so
and
then
next
slide,
which
I
think
is
the
last
one.
So
yeah
just
note
that
this
is
an
experiment,
we're
trying
to
figure
out
the
best
way
to
do
this.
So
if
you
have
any
issues
or
you
can
think
of
any
improvements,
please
like
let
us
know-
and
hopefully
it
goes
well.
A
D
D
A
D
D
All
right,
so
hopefully
this
is
going
to
work
yeah,
so
turbo
waste
dreams
are
formed,
swelling
so
here's
the
problem
that
we're
sort
of
worried
about
or
I'm
worried
about
so
people.
We
got
a
lot
of
people
very
enthusiastic
about
rust,
a
lot
of
hype
going
on
and
you
know
we
make
such
amazing
promises,
and
so
we
got
people
very
excited
they
dive
in
and
they
prototype.
D
But
you
know
the
experience
when
they
prototype
doesn't
always
live
up
to
the
hype
and
they
ask
what
what
now
that's,
essentially
the
heart
of
the
problem
that
I'm,
that
kind
of
worries
me
the
past
for
us
in
terms
of
like
the
long
term
of
the
project,
you
know
we
were
mainly
focused
on
trying
to,
and
I
mean
like
the
distant
past,
pre
1.0.
Our
goal
is
to
like
meet
the
needs
of
c
and
c
plus
plus
developers.
D
That
was
like
the
best
we
could
sort
of
hope
to
do
and
it
was
good
enough
and
then
the
other
big
customer
compiler
the
compiler
developers
themselves
for
rusty.
So
we
added
some,
you
know
things
to
do
profiling
internally,
but
that
was
it
so
now,
we've
that's,
what's
led
us
here
and
so
you
know
I
had
some
informal
discussions
with
various
rust
users
asking
is
rust
actually
delivering
on
its
promise
with
respect
to
performance,
and
I
got
three
classes
of
answers
number
three.
My
surprise.
D
No
number
three
will
surprise
you
I
don't
know
we'll
see
so
the
first
answer
was
rust
is
great.
Once
I
get
the
code
compiling
it
meets,
it
meets
all
my
performance
needs
and
the
code
actually
works.
That's
our
favorite
customer
right.
We
love
those
customers
because
usually
then
they
start
picking
at
you
know
the
details
and
giving
nitpicking
about
the
diagnostics
and
stuff,
and
then
we
love
that
feedback.
D
After
that
point,
then
there's
customer
b,
which
is
one
I
said
I
was
worried
about
the
one
saying
I
got
it
compiling
and
it's
not
going
as
fast
as
I
had
hoped
what
now?
So?
That's
the
one
I
sort
of
already
alluded
to,
but
here's
here's
customer
c
customer
c
says
you
know
I
was
struggling
here.
I
couldn't
figure
out
what
design
to
use
for
my
system.
D
I
struggled
to
get
it
compiling
the
first
place
and
you're
asking
now
what
I
think
about
the
performance,
but
I'm
still
debugging
all
the
deadlocks
I
see
so,
and
that
sort
of
led
me
to
worry
about
a
whole
new
thing,
which
is
that
our
past
goal
was
just
sort
of
you
know
being
compatible
with
status
quo
and
acting
like
the
existing
debugging
tools
that
are
out.
There
will
be
good
enough.
D
You
know
if
we
can
get
something
that
works
with
gdb
or
visual
code
or
whatever,
then
that'll
that'll
be
good
enough,
and
that
was
an
attitude
born
of
necessity.
For
the
most
part,
I
I
literally
you
know
had
a
conversation
and
I'll
admit
in
in
my
job
interview
where
someone
asked
me,
you
know
what
about
what
about
tooling
here?
What
about
debugging
tooling-
and
I
said
we're
not
trying
to
innovate
in
this
space,
but
rust
has
moved
on.
D
Rust
has
branched
off
from
c
and
c,
plus
plus
quite
a
ways,
and
that
means
we
should
be
broadening
our
scope.
We
should
be
thinking
about
innovating
with
our
development
tools,
as
well
as
our
language
and
the
other
sort
of
insight
here,
which
came
from
that
customer
b.
Customer
c
case
of
the
you
know
those
responses
that
I
showed
earlier.
Debugging
profiling
aren't
exactly
disjoint
activity.
They
are
disjoint
activities
in
some
viewpoints,
but
they
but
they're
both
in
service
of
program,
understanding,
program
behavior.
D
So
you
know,
should
we
be
actually
investing
in
tools
that
help
us
both
understand,
both
at
once
things
that
can
help
us
understand
profiles
and
debugging,
especially
when
you're
talking
about
io
type
stuff,
where
you
know
something,
that's
arguably,
a
performance
issue
is
actually
a
logic
problem
in
your
code.
You
know
we're
talking
about
dead
blocks
or
things
that
are
just
operating
kind
of
slowly.
There's
lots
of
cases
where
it's
it's
hard
to
know
what
the
line
is
between
a
debugging
problem
and
a
profiling
problem,
so
turbo
wish.
The
word
wish
is
important
there.
D
D
Impactful
leaders
inspire
others
to
action,
but
great
leaders
also
listen
and
we
have
up.
We
all
have
opportunities
to
demonstrate
leadership
on
both
these
fronts.
We
all
have
our
different
social
media
networks
that
we
we
like.
Some
of
us
are
hanging
on
discord.
Some
on
zulips,
I'm
on
twitter.
You
know,
there's
some
overlap
in
various
places.
All
of
us
should
be
striving
to
share
our
ideas
and
to
listen
to
those
ideas
of
our
peers
and
then,
after
digesting,
all
of
it
we
should
amplify
the
best
ones.
D
Obviously,
the
best
way
to
do
this
is
the
vision,
doc
process
that
nico
has
been
demonstrating,
but
I
want
to
you
know,
push
the
idea
that
you
know
unstructured
broadcast
has
value
too.
You
know
esteban
loves
to
use
twitter
and
getting
engagement
on
that
front
and
having
people
respond.
I
think
that's
awesome,
so
I
I
think
that
we
should
be
looking
at
all
possible
ways
to
get
publicist
public
publicity
this
way
and
broadcasting
ideas.
D
D
So
for
me
in
the
in
writing
these
documents,
I
want
to
spell
out
the
different
experiences
for
russ
newcomers
versus
rusty
developers
versus
experienced
web
service
developers
they're
all
in
the
blog
post.
As
an
example
of
this,
we
I
spelled
out
the
idea
of
this
of
a
console,
something
that
would
show
you
how
the
tasks
are
being
scheduled
in
an
async
runtime
and
identifying
how
they're
being
blocked
in
particular,
help.
You
understand
the
relationship
between
tasks
and
resources
and
in
particular,
then
there
was
a
user
experience
that
I
documented.
D
That
was
meant
to
sort
of
elaborate
on
this
talking
about
this
developer
abigail
and
she
has
a
chess
program
and
she's.
You
know
seeing
some
sort
of
deadlock,
and
so
I
want
a
tool
that
can
actually
let
you
click
something
and
see
a
directed
graph,
showing
you
the
tasks
and
the
resources
themselves.
Something
like
this,
something
where
you've
got
circles
for
your
processes
and
your
and
your
and
boxes
for
the
resources
in
this
case,
like
channels
that
are
sending
information
between
the
processes
between
the
tasks
and
then
you
have
a
cycle
in
that
situation.
D
That
can
mean
a
potential
deadlock.
I
want
something
that
can
give
me
that
immediacy
of
understanding-
and
then
you
know,
there's
some
other
stuff
in
there
in
terms
of
a
potential
design
for
a
system
for
this
turbo
which,
for
the
console
itself
here,
which
I
see
as
part
of
a
suite
of
tools
that
turbo
wish
could
have,
because
there's
so
many
different
experiences,
I'm
trying
to
describe
that.
It's
not
clear
whether
you
could
actually
fill
it
all
in
one
tool
or
not.
So
the
right
way
to
go
anyway
is
to
deliver
something
immediately.
D
D
You
know
another
great
way
to
inspire
people,
though,
that
carl
alerse
pointed
out
to
me
mock-ups,
showing
the
actual
experience
that
someone's
going
to
have,
and
this
was
the
one
that
carl
provided
and
I'll
tell
you
carl
basically
spent
some
time
putting
this
together
and
then,
after
carl
did
it.
It
was
immediate
where
people
were
both
the
customs,
the
customers,
the
users
who
were
talking,
saw
this
and
said:
oh,
my
god.
When
can
I
get
it?
I
want
it
now.
D
You
know
everything
else
that
I
showed
them
the
numbers
of
like
text
and
pictures
not
so
much.
This
got
people
excited
and
it
you
know
directly
led
to
you
know
the
work
that
we'll
see,
and
so
the
point
here
is
that
I'd
love
to
claim
that
these
posts
that
I'm
talking
about
you
know
caused
the
work
that
eliza
is
going
to
show
you
in
a
moment,
but
the
reality
is
the
tokyo
team
has
been
long
concerned
about
these
problems.
Well,
before
I
start
even
paying
attention
to
it.
They
care
about
profile.
D
They
care
about
debugging
and
they've.
Been
championing
at
the
bit
to
address
these
problems
so
we're
gonna
have
a
double
tokyo
console,
but
because
of
the
timing
here
and
having
this
whole
screen
sharing
thing,
I
sort
of
anticipated,
I
might
need,
to
you,
know
hand
off
control,
so
we'll
do
it
at
the
end.
The
links
will
also
be
at
the
end,
but
basically
there's
a
there's.
There's
source
code
for
this
thing,
you're
gonna,
see
and
there's
a
discord
chat
space
for
it.
D
The
console
is
only
one
tool,
though,
that
I
have
in
my
dream
utility
belt
in
my
mind,
there's
a
whole
bunch
of
other
spaces
that
we
could
be
innovating
in
using
the
rus
language
ownership
model
to
do
heap
profiling,
I
think,
is
a
great
potential
use
case
and
it's
spelled
out
in
my
one
of
the
user
stories.
Another
area
that
I'm
very,
very
passionate
about
is
record
replay
tracing,
as
some
of
you
may
know,
from
presentations.
D
I've
been
recently
about
rr,
so
anyway,
we
can
get
some
of
these
tools
by
improving
on
existing
integrations
and
that's
the
so-called
easy
path
right.
Just
you
know
making
the
thing
integrates
well
like
debug
info,
but
actually
it's
hard,
because
it
requires
specialized
knowledge
of
like
the
compiler
and
the
debug
info
format,
et
cetera,
or
instead
of
you
know,
improving
existing
integrations.
Maybe
you
need
entirely
new
integrations
to
work
with
an
existing
tool
and
yet
other
things
are
going
to
require
new
tools
entirely,
and
that
sounds
like
the
hard
path.
D
But
the
funny
thing
is
that
entirely
new
tools
can
actually
attract
enthusiastic
newcomers
because
it's
working
from
the
ground
up
and
that
can
be
very
exciting
for
some
people
to
get
in
on
the
ground
up
on
a
new
code
base
where
everything's
still
small
and
shiny,
and
they
can
have
an
impact.
So
that's
everything
I
wanted
to
say
the
crucial
points
I
want
to
try
to
get
to
is
that
you
know
we
can
all
inspire.
D
We
can
all
listen
it's
important
to
do
both
of
these
things
and
you
should
all
be
publicizing
your
dreams,
those
dreams.
You
have
and
be
evangelizing
our
shiny
futures
and
then
check
out
the
console
which
we're
going
to
see
a
demo
of
from
eliza
in
a
moment,
and
you
can
find
me
on
discord
or
on
zulip.
Okay,
let's
hand
off
controller
eliza
yeah.
D
G
G
D
D
So
it's
a
question
of
what
level
of
snapshot
you're
talking
about,
though,
like
I'm
actually
tracing
the
heap
and
having
a
snapshot
of
the
state
of
your
whole
object,
graph
or
you're
talking
about
just
knowing
the
state
of
the
events.
You
know
at
our
instrument,
not
necessarily
the
binaries
themselves
right.
So
there's
question
marks
there
about
the
level
of
detail
you
want
to
grab,
but
I
think
the
right
answer
here
is
certainly
an
explicit,
explicit,
snapshotting
option
or
even
a
check.
D
I
think
a
checkpoint
operation
to
be
able
to
check
with
the
state
of
the
program
and
res
and
restart
it
from
there
could
be
a
potentially
awesome
thing
to
put
in
just
push
just
put
in
the
standard
library.
It's
something
that,
like
a
lot
of
systems,
a
lot
of
os's
support,
pretty
cheap,
cheap
checkboarding
at
this
point,
like
I've
known
of
other
tools
like
rr
that
are
built
on
linux,
cheap
checkpointing.
E
D
D
Well,
we
don't
have
that
much
time
is
the
part
of
the
problem,
so
the
easiest
thing
would
either.
If,
if
sean
is
here,
I
would
hand
it
to
him,
because
he
actually,
I
think,
would
be
the
most
ready
to
do
it.
But
if
not,
we
can
just
say
you
know
what
we've
got
to
move
on,
because
we
don't
have
we're
already
at
the
24
minute
mark.
C
D
E
D
E
But
we
want
to
fix
that
and
niko
talked
specifically
about.
He
wants
to
try
to
rayon,
for
example,
and
I
think
it
should
be
pretty
easy
to
do,
and
so
what
we've
got
if
sean
wants
to,
can
you
share
your
screen
and
show
the
example
app?
I
was
going
to
like
show
the
code
for
it
first
and
because
it's
like
quite
simple,
and
it
shows
how
we're
like
not
actually
doing
like
anything
in
the
application.
E
E
E
So
what
we've
done
here
is
we've
written
on
a
tracing
subscriber
light
layer
that
you
can
add
to
a
tracing
subscriber
that
you're
using
and
then
we've
got
a
pretty
simple
wire
protocol.
If
you
check
out
the
latest
version
of
main
you'll
actually
see
a
lot
less
code,
but
I
guess
sean's
checkout
is
slightly
behind.
E
So
we
haven't
really
done
a
whole
lot
to
change
this
example
app.
It's
not
really
doing
anything
special,
it's
just
in
its
main
function.
It
calls
this
init
function
and
then
it
just
like
spawns
a
couple
of
tasks
and
those
tasks
have
a
big
loop
where
they
like
wait
on
a
timer
and
then
they
spawn
some
more
tasks
and
those
tasks
all
wait
and
then
eventually
those
tasks
finish.
E
So
what
I
would
do
is,
can
you
do
cargo
run
example
app
and
then
I
would
pipe
its
output
to
devnow,
but
it
doesn't
like
super
matter.
That's
just
the
demo
that
I
like
scripted
for
myself
and
it's
gonna
take
a
minute
to
compile,
because
I
was
expecting
to
do
the
demo
and
I
had
like
already
compiled
everything,
but
that's
fine.
So
what
we've
got
here
is
then
we
have
like
a
wire
protocol
and
the
tracing
subscriber
uses.
E
This
wire
protocol,
which
is
implemented
using
grpc
and
the
console
application
that
runs
on
the
command
line,
connects
to
the
app
it
has
like
a
port
that
it
listens
on
and
then
the
app
starts
streaming.
Events
to
the
console
and
if
you
want
to
maybe
in
another
window,
go
ahead
and
try
to
compile
like
just
do
like.
Oh,
it's
running,
okay,
so
you
do
cargo
run
and
it
has
a
default
port
that
it
connects
to
on
localhost.
E
It
also
takes
like
a
couple
command
line
arguments,
so
you
can
say
like
okay,
I
want
to
connect
to
this
port
or
like
on
this
like
ip,
if
it's
like
on
a
remote
host,
but
assuming
this
on
local
hosted,
just
cargo
run
with
the
default
connects
to
the
default
port
and
eventually
it's
going
to
build,
and
this
is
essentially
what
we've
got
here.
Is
it's
going
to
look
a
lot
like
top?
E
We
see
the
like
total
amount
of
time
that
that
task
has
been
running
a
busy
time,
which
is
like
how
long
the
task
has
been
actively
being
pulled
and
then
idle
time,
which
is
like
the
amount
of
the
tasks
run
time
that
it
was
not
actively
being
pulled.
We
have
a
counter
of
the
number
of
times
the
task
has
been
pulled,
and
then
we
have
some
fields
associated
with
it,
and
that
includes
whether
it's
a
attac,
a
regular
async
task,
a
blocking
task
or
something.
D
E
And
the
file
and
line
and
number
where
the
task
was
spawned
from
and
sean
can
use
the
left
and
right
arrow
keys
to
sort
of
select
a
column,
and
if
you
select
a
column,
it
resorts
the
task
list
by
that
and
then
what
you
might
see
is
that
some
of
these
have
kinds
that
are
bangs
and
some
bang.
That
means
that
that
task
is
terminated
and
it
lingers
in
the
task
list
for
a
little
bit
so
that
you
can
still
see
information
associated
with
it.
E
They
will
they
would
be
grayed
out,
but
it
looks
like
sean's
terminal.
Doesn't
support
that
sorry.
There
would
also
be
some
tasteful
use
of
bold
in
this,
which
you
also
can't
see,
because
sean's
terminal
doesn't
support
bold,
which
is
fine,
and
then,
if
you
use
the
arrow
keys,
you
can
the
up
and
down
arrow
keys.
You
can
scroll
through
the
task
list.
So
if
you
want
to
select
one
of
these
tasks
and
whack
the
enter
key,
we
actually
have
a
screen
here.
That
shows
some
more
details
associated
with
this
task.
E
We've
got
the
task
id
total
time
busy
and
idle
time,
just
like
on
the
other
screen
and
again
we
see.
Oh,
this
task
was
actually
spawned
by
hyper.
That
seems
appropriate.
This
is
probably
from
the
grpc
server.
That's
actually
serving
this
data,
and
then
here
on
the
other
side,
we
have
some
information
about
this
task's
waker.
So
we
see
that
there
are
currently
two
wakers
for
this
task,
and
then
we
see
a
count
of
the
number
of
times
the
wakers
have
been
cloned
or
dropped.
E
So
by
capturing
the
context
in
which
a
waker
clone
event
happened,
we
can
actually
look
at
like
what
resource
like.
Was
it
a
channel?
Was
it
some
io
resource,
or
was
it
like
a
futures,
unordered
or
something
or
a
timer,
that
you
are
like
signaling,
the
intent
to
wait
for
and
then,
when
you're
woken
back
up,
we
can
track
where
the
waker
was
woken
from,
and
so
we
can
see
like
okay.
So
this
task
was
waiting
on
any
of
these
resources
and
it
was
broken
by
this
one.
E
E
Like
it's
task
saturation
time
between
polls
queue
depths
so
on
and
when
that's
ready,
we'll
also
be
able
to
consume
that
from
the
console
and
when
we
integrate
with
like
other
executors
such
as
rayon,
we
want
it
to
be
able
to
expose
its
own
statistics.
That
might
not
be
the
same
statistics
as
tokyo.
Obviously
they
don't
all
make
sense.
Since
tokyo
is
an
async
executor.
Rayon
is
like
for
data
parallelism.
E
E
That
shows
some
work
he's
been
doing
about
instrumenting
the
tokyo
timer,
so
he
actually
has
a
branch
that
I
think
is
not
quite
ready
for
prime
time
that's
showing
a
list
of
all
of
the
timers
and
which
tasks
are
waiting
for
those
timers,
but
that's
still
sort
of
a
work
in
progress,
and
I
wasn't
going
to
do
a
live
demo
with
it,
because
I
think
that
that
branch
only
exists
on
his
computer
anyway.
That's
sort
of
what
we've
got.
F
So
I
was
curious
how
easily
you
mentioned
the
busy
time
and
idle
time
and
what
those
meant.
I
wondered
how
easy
it
would
be
to
detect
things
like
cpu-bound
tasks,
where
cpu-bound
tasks
shouldn't
be,
and,
for
instance,
you've
done
a
lot
of
heavy
cpu
processing
on
something
that
isn't
in
your
blocking
executor.
F
E
Already
have
the
stats
to
do
basically,
all
of
that.
Oh
here's,
the
demo
great
awesome.
This
is
just
like
very
cool
and
it's
like
not
quite
ready
for
prime
time,
but,
as
you
see,
we
also
have
here
he's
got
a
list
of
all
of
the
timers
that
are
running
on
the
runtime.
What
kind
of
timer
they
are,
what
they
did
recently
and
so
on,
but
that's
still
sort
of
a
work
in
progress
anyway.
D
E
E
An
individual
task
has
with
the
rest
of
the
program
like
how
many
standard
deviations
above
the
norm.
Is
it,
and
so
the
problem
there
is
that
we
would
have
to
have
some
heuristics
that
are
like
generally
correct
before
we
can
start
making
like
suggestions
that
people
might
want
to
view
as
actionable
suggestions
in
the
interface,
but
you
can
definitely
do
that
kind
of
analysis
right
now,
with
the
tools
that
we
have,
you
can
think
about
it
and
you
can
sort
the
list.
E
It
would
be
really
nice
to
make
it
very,
very
easy
for
people
who
are
maybe
less
familiar
with
these
kind
of
issues
to
identify
them,
but
that
requires
like
okay
where's
the
line
for
like
this
is
maybe
a
problem,
and
that
is
sort
of
it's
a
little
bit
individual
to
the
program.
It's
a
little
bit
hard
to
find
that
reliably,
but
it's
definitely
something
we
could
do
in
the
future.
I
it
would
be
interesting
work.
D
A
A
We've
also
had
a
lot
of
really
long
threads.
I
think
everyone
can
remember
some
of
these
who
at
least
who's
participated.
These
were
the
most
commented
rfcs.
I
love
that.
Allow
non-ascii
identifiers
is
number
one
by.
I
think
a
lot,
but
you
know
question
mark
okay
and
of
course
the
legendary
await
syntax
debate.
482
comments.
A
A
This
started
out
as
a
set
of
design
tenants
in
the
async
vision
dock.
So
these
are
still
there
they're.
Like
really
out
of
date,
when
we
were
starting
with
the
vision
dock,
I
started
drafting
what
do
I
think
the
the
sort
of
design
principles
of
async
are
and
then
we
were
iterating
on
them
and,
as
I
iterated
on
them,
it
seemed
like
they
weren't
really
about
async.
They
were
actually
just
becoming
about
rust
itself,
the
whole
rust
language
or
even
more,
like
rust,
library
and
tooling.
A
I
think
there's
a
kind
of
coherent
set
of
principles
that
the
whole
system
abides
with.
So
these
are
the
six
principles
that
I
have
in
the
current
draft
and
I'm
going
to
kind
of
walk
through
them
and
give
some
examples
and
explain
what
they
mean
and
they're
all
each
one
is
short.
Each
one
has
a
paragraph.
The
hope
is
that
you
can
kind
of
use
that
to.
A
A
We
empower
everyone
to
build
systems
where
resource
usage,
security
and
correctness
and
long-term
maintenance
are
our
top
considerations
and
we
do
it
with
pizzazz.
That's
the
current
draft
of
what
we're
trying
to
do,
but
then
the
question
is:
how
do
we
do
it,
and
I
think
these
are
some
of
the
things
that
we've
used.
Let
me
explain
what
they
mean
so
safety.
First,
this
one's
pretty
clear,
safe,
rust
code
is
memory
safe
data,
race,
free
and
free
of
undefined
behavior.
This
is
kind
of
the
top
principle.
A
That's
the
other
thing
I
should
mention
is
that
these
are
ordered
by.
If
you,
you
should
try
to
achieve
them
all,
but
if
you
have
to
achieve
one
more
than
the
other,
you
should
lean
this
way
right
and
so
safety
is
first
and
you
know,
there's
a
million
examples
of
how
we
enforce
safety,
but
ownership
and
borrowing
the
most
obvious
one,
and
there
aren't
really
any
places
that
we
compromise
on
it.
A
Iterators
are
my
favorite
example,
because
you
can
write
them.
They
go
as
fast
as
a
for
loop
or
even
faster,
since
they
overlaid
binds
checks,
but
in
other
languages
you
know
you
would
be
losing
performance
because
you'd
have
an
object
for
each
of
the
steps
in
the
iterator.
You'd
have
virtual
calls
all
throughout
here,
and
maybe
the
compiler
can
recover
it,
and
maybe
it
can't
right,
but
we
used
these
techniques
that
c
plus
plus
pioneered
to
kind
of
step
past
that.
A
But
I
think
there
are
just
a
lot
of
examples
once
you
start
digging
in
async
functions
fit
this
definition
right.
We're
trying
to
give
a
high
level
construct
without
it,
costing
you
performance,
sort
of
decompiling
down
to
the
same
kind
of
code.
You
would
write
and
see,
or
what
have
you
closures,
auto
draft
operator
overloading?
These
are
all
great
examples
of
that,
but
there
are
places
that
we
give
up
on
it
right
and
it's
safety.
A
That's
why
it
comes
second,
so
I
think,
like
array,
indexing
in
c
is
faster
than
it
is
in
rust,
because
we
don't
have
a
way
to
make
that
safe
without
bounce
checks
that
at
least
that's
tolerably
nice
to
use.
So
there's
actually
a
nice
thing.
Maybe
that
will
change
as
we
do
more
work
into
extended,
static,
proving
and
so
forth,
but
we
do
one
of
the
things
that
we
also
do.
A
lot,
I
think,
is
a
pretty
useful
pattern
is
when
we
take
away
something.
A
So
the
next
one
is
transparent
and
predictable.
The
role
here,
I
think,
is
that
rust
should
not
surprise
you
right,
and
that
means
both
from
performance.
You
should
be
able
to
kind
of
tell
how
what
exactly
a
code
is
going
to
do
when
it
runs,
but
also
from
sort
of
correctness,
point
of
view.
You
shouldn't
find
out
that,
in
fact
you
know
there's
some
surprising
hidden
operation.
They
weren't
aware
of
that
changes,
the
semantics
of
the
code-
and
there
are
a
lot
of
examples
of
this-
I
think
the
most
obvious
one
is.
A
We
don't
have
a
garbage
collector,
which
kind
of
radically
which
makes
the
performance
profile
of
your
code
not
predictable,
but
there
are
others
like
we
decided
early
on.
We
weren't
going
to
have
any
kind
of
copy
constructors,
all
right
so
in
c
plus,
when
you
have
a
function,
call
like
this.
A
common
performance
foot
gun
is
that
actually
there
might
be
some
complex
operation
happening
here,
whereas
in
rust
this
is
just
always
a
mem
copy.
A
Now
I
think
you
could
argue-
and
I
think
it's
kind
of
interesting
the
having
phrased
it
as
transparent
and
predictable.
You
could
argue
that
even
our
current
rules
are
not
as
predictable
as
they
could
be,
so
this
could
be
a
mem
copy
of
an
awful
lot
of
memory
right,
so
it
might
actually
be
kind
of
slow
and
then
there
are
other
things
that
we
like
cloning
in
rc
or
something
which
are
one
which
we
don't.
So
that's
a
debate.
There's.
A
Definitely
some
active
discussion
around
these
kind
of
questions,
but
I
think,
having
this
design
principle
written
out
gives
us
a
little
more
to
talk
about.
Is
that
really
the
principle
then?
And
if,
if
so,
does
that
imply
that
we
should
tweak
the
design,
then,
if
we
didn't
have
it
written
now,
so
there's
a
bunch
of
other
examples
of
places
that
we
try
to
be
transparent,
unwinding.
We
don't
like
it
because
it
makes
it
harder
to
reason
about
your
control
flow
makes
your
code
less
less.
Obviously
correct.
A
You
can't
quite
tell
what's
going
to
happen.
That's
why
we
have
the
question
mark
operator
so
that
we
can
see
it.
We
don't
like
to
have
implicit
allocation.
Typically,
there's
performance,
cliffs
that
come
from
that,
and
actually
I
was
looking
through
the
eight.
Oh,
I
don't
have
a
link
darn
it.
I
was
looking
through
the
lib
api
guidelines
and
there's
a
whole
section
of
rules
about
predictability
there.
So
I
think,
which
fits
directly
into
this
things
like
smart
pointers,
not
adding
inherent
methods.
A
One
of
them
would
be
optimizations
like
reordering
of
struct
fields
and
enums.
There's
things
that
compiler
does.
The
purpose
of
them
is
to
let
you
have
nice
things
like.
We
want
you
to
be
able
to
use
option
without
worrying
about
how
fast
it
is,
and
so
we
try
to
optimize
it
and
we
do
the
best.
We
can,
but
there
are
limits
to
what
we
can
do
and
it
changes
sometimes
from
time
to
time
and
so
there's
a
bit
of
transparency
loss
there,
the
next
principle
orthogonal
composable
and
extensible.
A
The
idea
is
that
rust,
in
a
lot
of
places
and
a
lot
of
ways
from
big
to
small,
is
really
aimed
at
having
little
pieces
that
you
can
put
together
in
all
kinds
of
ways,
and
I
think
this
includes
like
a
focus
on
portability.
So
at
the
highest
level,
you
want
to
be
able
to
take
take
code
targeting
one
well,
you
want.
A
We
want
to
be
able
to
take
russ
code
and
sort
of
use
it
on
many
different
systems,
which
is
a
kind
of
composability
composing
it
with
different
architectures
and
our
operating
systems,
but
also
the
way
we
build
the
code
itself.
So
some
of
the
prime
examples,
I
would
say
cargo
and
crates
io.
It's
the
reason
that
we
emphasized
cargo
so
early
on
was
that
we
knew
we
wanted
people
to
have
a
set
of
crates
that
they
could
build
and
combine,
and
as
far
as
language
rules
things
like
coherence.
A
The
reason
we
have
the
coherence
rules
is
exactly
that
we
figured
it
was.
It
was
an
absolute
imperative
that
you
should
be
able
to
take
any
two
crates
from
crates,
io
put
them
together
and
have
no
linking
errors
or
conflicts
or
other
kinds
of
things,
and
there
are
other
systems
that
are
more
flexible.
A
But
if
you
took
that
approach
you
wouldn't
have
that
property
and
it
seemed
to
us
more
important
to
have
consistency
and
composability
so
portability.
I
talked
about.
I
see
that
as
part
of
this
as
well
being
able
to
go
across
architectures
and
we
often
make
decisions
in
the
standard
library
like
we're
not
going
to
expose
atomics
and
so
forth,
and
you
could
go
on
and
on.
I
think
this
is
a
really
common
principle:
the
global
allocator
minimal
standard
library.
These
are.
A
A
I
think
auto
trades
we
automatically
determine
if
things
are
send
or
sync
that's
a
case
where
we
are,
it
makes
composition
a
little
more
fragile
than
it
otherwise
would
be,
but
it
gives
the
advantage
that
you
can
run
things
in
parallel
very
easily
and
that
was
kind
of
the
goal
we
were
going
for.
We
wanted
rust
to
be
a
language
where
parallel
code
just
worked
right,
so
the
next
one
almost
to
the
end
now
is
exposing
all
the
system
capabilities.
A
A
A
First
of
all,
the
fact
that
you
have
to
declare
that
you're
using
the
cabi
already
is
like
a
little
hurdle
towards
interoperating
and
so
forth,
but
the
c,
and
then
we
have
another
abi
that
we're
adding
for
weather
to
indicate
whether
or
not
the
c
function
will
unwind.
That
seems,
okay,
because
these
that
allows
us
to
have
nicer
things
right
that
allows
us
to
do
more
optimizations
to
make
rust
code
perform
better,
while
still
preserving
the
ability
to
expose
all
the
system
capabilities.
A
I
think
cmd
intrinsics,
you
know,
there's
just
a
lot
of
examples
of
os
string
and
so
forth.
That
are
all
aimed
at
the
same
concept,
and
I
think
the
way
we
compromise
on
this
and
why
it
comes
relatively
late
in
the
list-
is
there's
a
lot
of
things
that
we
support,
but
only
in
some
ways
right,
like
long
jump
or
something
like
that,
it's
they
tend
to
be
conflicting
between
safety
and
nice
things
right,
so
long
jump.
We
we
don't
allow
people
to
just
jump
over
arbitrary
frames.
A
That's
because
you
could
say
it's
for
safety.
You
could
also
say
it's
for
wanting
to
support
use
cases
like
rayon.
That
would
be
invalidated
if
they
could
do
that
and
as
far
as
composition
goes,
you
know,
we
we
tend
to
limit
ourselves
in
the
standard
library
to
things
that
are
portable
across
many
architectures.
Unless
you
opt
in
and
so
forth,
and
that's
kind
of
compromising
somewhat
you
don't
get
all
the
capabilities
of
your
system
right
away.
You
have
to
ask
for
them.
A
A
We
kind
of
encourage
you
to
to
check
for
all
the
edge
cases
right.
So
things
like
exhaustive
pattern
matching
is
a
good
example:
some
languages,
let
you
leave
off
cases
and
just
throw
an
exception
if
they
happen
to
occur.
We
didn't
want
to
do
that.
I
think
things
like
the
dead
code
lints,
which
catch
catch.
A
surprising
number
of
half-finished
refactorings
for
me
are
a
good
example
where
we
just
take
the
opportunity
to
to
go
the
extra
mile
and
look
for
problems
and
then
there's
a
lot
of
other
things
right.
A
It
seems
like
in
general,
if
we
have
the
ability
to,
we
opt
for
a
little
extra
checking.
There
are
some
places
where
we've
had
to
compromise,
usually
for
performance.
I
think
overflow
checks
are
my
favorite
example,
because
overflow
and
arithmetic
is
really
confusing,
but
we
wanted
to
to
so.
We
wanted
the
checks,
which
is
why
we
have
them
in
debug,
but
we
knew
we
couldn't
afford
them
all
the
time,
so
we
turned
them
off
and
release
and
it's
kind
of
a
we'll
catch
as
much
as
we
can
right.
A
A
This
is
still
evolving,
it's
a
work
in
progress
and
what
I'm
hoping
to
get
first
of
all
from
this
meeting
and
from
follow-ons,
and
this
is
feedback
on
which
of
these
things
are
good
or
which
parts
do
you
think
you
might
do
differently?
What,
if
you
were
looking
at
your
team's
work,
what
might
be
different,
but
I'd
also
like
to
really
just
try
applying
these
principles
as
we
go
as
we're
looking
at
new
designs
to
say:
do
these
principles
fit?
Is
there
some?
A
One
challenge
is
trying
not
to
have
too
many
there's
it's
easy
to
get
a
really
long
list,
and
then
it
starts
to
be
less
useful,
so
yeah
I'd
love
to
hear
that
we
have
a
few
minutes
if
we
have
either
ideas
of
things
that
aren't
in
here,
questions
about
why
the
ordering
is
the
way
it
is
counter
examples.
Whatever
you
got
I'll
just
leave
this
on
the
screen.
D
Yeah,
so
I
I
want
to
sort
of
add
me
that
that
there's
an
overflow
example
in
terms
of
you
know
we
do
turn
off
the
overflow
checks,
but
we
do
also
say
you
know
in
release
mode.
It's
still
a
consistent
portable
semantics,
in
terms
of
it
being
it's
going
to
always
be
modular
arithmetic
and
not
be
undefined
behavior,
which
I
think
c
doesn't
guarantee.
A
A
Yeah,
I
was
gonna,
say
it's
also
kind
of
hard
to
misuse
right
like
it's,
giving
you
it's,
but
not
it's
not
really
hard
to
misuse,
but
it
does
at
least
give
you
the
ability
to
to
know
what's
going
to
happen,
to
reason
about
those
cases
too,
but
it's
a
good
one.
I'm
going
to
write
it
down.
I
think
it's
transparent
and
predictable.
A
H
Yeah,
so
you
know,
as
we
talk
about
these
compromises
and
and
principles
and
and
ways
that
we
are
not
compromising,
I
I
it
occurs
to
me
that
that
it
would
be
interesting
to
have
an
atlas
of
where
these
compromises
have
been
made
in
the
past
or
or
where
they
have
explicitly
not
been
made
in
the
past,
and-
and
you
know
the
idea
here
is.
I
think
it
would
be
useful
in
general
just
to
understand
what
these
principles
are
and
how
the
community
understands
them,
but
also
moving
forward.
A
That's
really
good
one
thing
I
want
to
say
that
I
didn't
show,
but
that
I've
been
working
on
is
this
crazy
spreadsheet,
which
is
trying
to
map
out
a
lot
of
examples,
because
I
was
trying
to
figure
out
the
ordering
in
a
more
complete
way.
So
it
has.
You
know:
okay,
where
does
having
nice
things
win
over
other
stuff,
but
I
that
would
be
something
to
digest
offline,
but
I'm
not
sure
if
that's
the
kind
of
atlas,
you're
thinking.
F
F
A
No
that's
the
same
principle.
I
didn't
mention
it
in
the
slides,
but
I
do
see
this
as
like.
All
the
way
down
to
the
granularity
of
like
a
particular
like
question.
Mark
operator
should
compose
well
with
other
operators
in
the
language.
Up
to
you
know,
your
program
should
compose
well
with
different
operating
systems,
they're
kind
of
all
on
a
continuum
for
me.
I
A
J
Oh
okay,
oh
something!
I
just
noticed
that,
like
in
general,
that
tends
to
be
a
concern
that
tends
to
have
kind
of
like
cross
cut
across
is
cross-cutting
over
these
things.
That
is
par
of
sincere.
So
it's
also
this
that
it's
in
many
ways
it's
like
kind
of
a
it,
has
the
advantages
of
kind
of
starting
over,
so
that
it
is
very
concerned
about
exposing
all
the
system,
capabilities
and
all
the
capabilities
of
a
processor
and
being
very
portable
for
for
processors.
J
A
It's
exactly
trying
to
get
at
that
that
point
that
it's
not
portable
across
every
possible
thing,
but
across
the
things
we
think
people
use
the
most,
especially
because
that
does
impose
a
there's,
an
interesting
thing
here
of
like
if
you
hold
everyone
up
and
force
them
to
have
a
certain
level
of
kind
of
support
and
compatibility
or
not
force
but
encourage.
It
is
a
kind
of
tax
on
everyone.
A
A
G
C
C
One
thing
I
was
thinking
about
it
that
I've
heard
many
people
call
one
of
russ
superpowers
is
it's
community
it
would
it
be
even
worth
having
a
sort
of
something
about
the
community,
the
well-being
of
the
people
that
are
contributing
mechanisms
where
we
might
say
at
some
point.
You
know
what
we're
going
to
stop
trying
to
make
this
even
better,
because
it's
going
to
burn
out
everyone
or
something
like.
A
That
it's
a
good
lead
in
sean
because
I'm
also
iterating
on
a
set
of
community
principles,
all
right.
So
yes,
I
definitely
think
that's
worth
having.
I
don't.
I
I
kind
of
separated
them
out,
because
I
thought
it's
nice
to
talk
about
the
design
that
we're
shooting
for
and
then
separately
talk
about
the
processes
that
we
use
to
sort
of
meta
processes
that
we
usually
to
get
there
but
yeah
good
question
all
right,
so
I
think
we're
gonna
call
it
now
we're
three
minutes
over.