►
From YouTube: 2022-02-21 Cross Team Collaboration Fun Times (CTCFT)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
All
right,
hello,
everybody
welcome
to
the
february
ctcft.
This
is
the
first
one.
We've
had
in
a
few
months,
the
first
one
of
22
2022,
and
so
I
just
want
to
say,
welcome
back
to
having
this
opportunity
to
have
talks
between
different
teams
for
rust
and
share
some
of
the
stuff
that
we're
working
on
more
internally.
A
And
so
I
just
as
a
reminder.
I
do
want
to
say
that
we're
going
to
have
a
decent
amount
of
time
for
questions
today,
and
so,
if
you're
attending
live
and
you're
interested
in
asking
a
question
for
either
of
our
talks,
then
you
can
just
put
your
hand
up
like
this
in
the
question
in
the
chat
and
then
we'll
add
you
to
the
queue
also,
I
just
remind
her
to
meet
yourself
and
turn
off
the
video
unless
you're
the
one
queued
up
to
speak
and
so
to
get
us
started
here.
A
We
also
have
wesley
and
potentially
felix
giving
us
an
update
on
the
compiler
team,
compiler
team
ambitions
for
2022.,
and
so
the
theme
of
the
cc
ctcft
is
planning
for
2022
and
so
I'm
kind
of
just
exploring
what
type
of
what
kind
of
stuff
we
have
coming
up
for
the
next
year,
which
I
think
is
a
pretty
nice
theme
to
start
of
the
year
with
afterwards.
As
always,
we'll
have
our
60
minute
social
hour.
It
might
be
a
bit
longer
today,
depending
on
when
we
get
started
with
it.
A
When
we
finish
the
talks
today,
we'll
have
I
forget,
if
we
normally
have
the
announcement
or
like
open
mic
at
the
at
the
closing
of
the
ctcft
or
right
now,
but
I'll
put
it
at
the
end
for
for
this
month
and
then,
if
anybody
has
any
announcements
that
they'd
quickly
like
to
shout
out,
we
can
do
that
right
at
the
end.
B
Hey,
thank
you,
okay.
So
I'm
going
to
talk
about
the
survey,
so
we've
been
doing
an
annual
survey
of
the
russ
community
kind
of
every
year
for
a
while.
Now
I
don't
even
remember
how
many
years,
but
there's
quite
a
few
last
year,
ryan
and
I
decided
to
give
the
the
the
survey
a
little
bit
of
an
overhaul.
So
we
we've
kept
around
some
of
the
kind
of
old
favorite
questions.
But
we've
polished
a
few
questions.
B
We
added
a
bunch
more,
and
so
it
was
a
bit
different
in
2021
compared
to
the
previous
few
years.
So
thank
you.
Everyone
who,
who
filled
it
out
lots
of
people,
did
we
had
just
over
9
000,
complete
responses,
which
is
a
new
record
and
I
think
around
12
000
kind
of
partial
responses.
B
So
a
lot
of
people
feel
that
so
so,
thanks
very
much,
and
thanks
also
to
well
for
the
folk
who
helped
translate
the
questions
and
have
been
translating
the
answers
and
also
to
a
bunch
of
folk
who
who
gave
some
really
good
input
while
we
were
kind
of
working
on
the
overhaul
of
the
survey.
B
So
most
of
the
rest
of
this
slot,
I'm
just
going
to
like
talk
about
some
of
the
the
results,
the
as
far
as
has
popped
up.
We
got
the
blog
post
that
came
out
last
week
and
that
has
a
summary
of
some
of
the
results
and
is
worth
giving
a
read.
If
you
haven't
already
I'm
gonna,
probably
repeat
some
of
those
and
talk
about
a
few
more
exactly
what
we're
gonna
share,
kind
of,
like
more
long
term,
is
still
being
decided.
B
If
you
have
opinions
about
that,
then
there's
a
kind
of
policy
proposal
on
the
survey
repo.
I
can
post
a
link
to
that
pr
later.
If
people
are
interested
in
that,
but
probably
the
next
step
is
we're.
Gonna,
try
and
put
together
a
kind
of
summary
report
that
captures
pretty
much
all
of
the
results,
but
without
too
much
analysis
and
we'll
send
that
at
least
to
everybody
on
a
rust
team,
so
that
that
can
hopefully
help
with
your
your
planning
and
thinking
for
the
for
the
year.
B
B
B
Okay,
so
well,
I
already
said:
we've
got
like
9
000
responses
of
those
like
90
were
rust
users.
We
do
ask
for
kind
of
non-users
and
form
users
to
fill
out
as
well,
but
usually
in
a
minority
of
those
rust
users,
we
tend
to
see
a
lot
using
rust
at
work.
So
this
year,
40
people
said
that
they
use
rust
a
lot
at
work.
B
So
that's
either
as
their
kind
of
like
main
language
or
soul,
language
and
another
19
percent
said
they
use
it
a
bit
and
41
said
they
don't
use
it,
and
this
is
one
that's
a
bit
hard
to
compare
to
previous
years,
because
we
asked
a
slightly
different
question.
I
don't
have
like,
like
previous
year's
data,
to
hand
it
anyway,
but
people
always
ask
like
how
that
compares
to
previous
years.
For
now
and
for
this
talk,
I'm
just
gonna
focus
on
on
what
we
got
this
year.
B
So
I
wanted
to
start
off
with
just
some
kind
of
feel-good
statistics.
Really
we
asked
a
couple
of
different
questions
about
kind
of,
like
sentiment,
kind
of
questions,
whether
you
agree
with
these
statements,
so
only
one
percent
of
respondents
felt
that
programming
with
rust
was
not
fun.
So
I
like
that
that
like
makes
me
happy
as
a
as
a
statistic,
even
fewer
just
a
quarter
of
a
percent
thought
that
rust
was
not
beneficial
and
and
another
small
number.
Only.
B
One
percent
said
that
the
the
benefits
were
not
worth
the
challenges
of
of
using
rust
and
when
we
asked
about
whether
people
were
were
using
rust
for
projects
at
work,
90
people
who
have
done
so
would
use
rust
again
or
sorry
are
likely
to
use
rust
again
in
the
future.
So
so
those
are
the
kind
of
statistics
that
we
want
to
track
year
on
year
into
the
future,
but
they
they
make
me
happy
for
for
this
year
so
far.
B
B
I
guess
that
that
last
one
is
maybe
a
little
bit
interesting,
like
the
numbers
are
up
there
with
the
kind
of
strong
technical
reasons,
74
use
it
because
they
want
like
precise
control
over
what
their
machine
is
doing.
B
Sorry,
these
there's
there's
not
much
of
a
narrative,
I'm
kind
of
just
reading
numbers
out,
so
I'm
gonna
kind
of
like
hop
over
to
the
the
next
topic,
which
is
where
people
are
developing
software
again.
This
is
not
particularly
surprising
but
kind
of
confirms
the
kind
of
assumptions
we
make
70
of
people
develop
on
on
linux,
another
31
on
windows
and
32
on
mac.
B
So
you
know
that's
kind
of
like
a
strong
majority
for
linux
and
I
think
it's
interesting
that
windows
and
mac
users
have
about
equal
numbers
where
people
target
so
so,
where
rust
is
running
again.
Kind
of
80
on
linux,
39
on
windows
and
one
that
was
really
surprising,
was
a
full
24
are
targeting
wasm
web
assembly
as
a
as
a
target.
So
these
are.
This
was
a
multiple
choice.
Question
and
lots
of
people
take
lots
of
of
boxes,
and
I
think
there's.
B
This
is
one
place
where
kind
of
like
a
deeper
analysis
of
that
is
going
to
be
really
interesting,
because
I'm
pretty
sure
that
there
aren't
a
quarter
of
all
rust
developers
targeting
just
web
assembly,
but
but
even
so,
that's
I
think,
an
interesting
statistic.
B
B
So
you'll
notice,
these
numbers
don't
add
up
to
100,
because
it's
multiple
choice,
questions
but
yeah
it's
about
three
times
as
many
people
using
stables
nightly
and
as
for
why
people
are
using
nightly
so
72
it's
for
for
features
either
a
specific
feature
or
for
all
the
features
that
come
with
nightly
and
that's
like
the
overwhelming
reason
people
are
using
nightly
is
for
is
for
new
features,
but
then
the
the
next
most
important
reason,
24
percent
of
respondents
use
nightly
because
a
dependency
requires
it
and
20,
because
a
tool
requires
it,
11
use
it
because
they
test
it
in
nci.
B
So
I
again,
I
don't
have
like
previous
numbers,
it's
interesting
to
see
how
we're
tracking,
in
terms
of
how
many
people
are
using
kind
of
like
stable
versus
a
nightly
tool
chain,
and
that
analysis
will
will
come
later
and
a
similar
measure,
I
think
kind
of
like
we.
We
ask
questions
about
stability
as
well,
so
just
about
the
stable
compiler.
I
think
we
got
really
good
numbers
here.
Only
two
percent
worry
about
their
code
breaking
when
they
update
their
stable
compiler
and
obviously
we
have
our
backups
compatibility
promise.
B
But
that's
working
like
people
do
not
worry
about
upgrading
their
compiler
version
and
that's
all
they're
stable
compiler
version.
I
think
that's
really
great,
even
fewer
just
one
and
a
half
percent
feel
that
they
sometimes
have
to
make
non-trivial
changes
to
their
code
when
they
upgrade
their
compiler.
B
So
kind
of
like
making
a
little
leap
again
like
one
area
that
kind
of
like
I've
always
been
kind
of
like
you
know,
pushing
and
rust,
is
tooling,
and
I
think
kind
of
the
survey
is
a
really
great
opportunity
to
get
information
about
which
tools
people
are
using
and
how
they're
using
them.
So
I
think
this
year,
kind
of
like
two
kind
of
d.
Two
areas
that
can
like
stood
out
to
me
were
ids
and
debuggers,
so
we
asked
people
how
they
edit
their
code
and
again
multiple
choice.
B
Questions
people
take
more
than
one,
but
77
people
use
an
ide
of
some
kind.
That's
that's
a
lot
like
more
than
I
would
have
guessed.
40
people
use
kind
of
like
a
more
basic
text
editor.
So
so
I
feel,
like
that's,
probably
a
change
compared
to
a
few
years
ago
of
the
ide
folk.
Sorry
not
of
the
idea
of
all
users.
B
The
most
popular
id
was
was
vs
code
with
60
of
users
using
it
at
least
some
of
the
time
versus
about
27
prefer
kind
of
a
more
kind
of
like
traditional
full-featured
kind
of
ide
and
in
terms
of
kind
of
peop
of
sentiment
like
66
people
have
a
positive
impression
of
id
spot
and
rust,
which
is,
I,
I
think,
pretty
great
compared
to
20
28
having
a
negative
impact
and
56
think
that
it
got
better
in
the
last
year.
B
So
I
think
that's
kind
of
really
impressive
and
you
know
shout
out
to
everyone
kind
of
his
word
on
bust
analyzer,
rls
jet
brands,
etc.
For
doing
that,
good
work,
debugging
is
interesting.
B
I
think
it's
interesting
whether
you
know
debuggers
are
kind
of
like
traditionally
a
really
essential
tool
for
persistence,
programmers
and
there's
kind
of
like
a
bit
of
a
feeling
that
in
rust
you
don't
need
one
so
much
so
I
was
interested
in
just
interested
to
see
like
whether
the
statistics
back
that
up
so
65
percent
of
people
use
some
debugger
some
of
the
time.
So
so
that
means
obviously
like
35
of
people,
never
use
a
debugger.
I
thought
that
would
be.
B
I
thought
fewer
people
will
be
using
a
debugger
to
be
honest,
but
so,
but
that's
that's
pretty
interesting
to
me
and
in
comparison,
68
of
people
do
debugging
using
some
kind
of
logging,
whether
that's
print
line
or
using
the
debug
macro
or
using
something
more
formal,
like
a
tracing
library
or
whatever
so
they're
kind
of
comparable
numbers.
So
that's
like
65
percent
use.
Some
kind
of
debugger
compared
to
68
do
some
kind
of
logging
to
debug
their
problems.
B
B
The
rest
survey
are
quite
nice
and
certainly
in
comparison
to
to
kind
of
like
the
sentiment
that
we
saw
for
other
parts
of
that
question
like
that
kind
of
41
38
split
is,
is
fairly
negative
for
for
debugging,
okay.
So
talking
of
kind
of
like
this
kind
of
like
sentiment
about
things,
I
wanted
to
kind
of
like
quickly
go
over
kind
of
some
of
the
the
percentages
of
people
like
kind
of
like
positive
sentiment
about
stuff,
because
I
think
this
is
kind
of
good
to
know
so.
B
Kind
of
most
positive
impressions
were
about
documentation
and
compiler
error
messages,
both
of
which
had
like
90
percent
of
people
thought
they
were
good
in
comparison
on
the
compiler.
Nobody
will
be
surprised
that
compile
times
got
a
pretty
measly
score,
36
percent,
but,
on
the
other
hand,
get
a
compiler
errors.
So
that's
like
isis,
had
a
73
kind
of
positive
impression,
which
is
is
pretty
good.
We
didn't
ask
about
many
kind
of
like
domains
of
programming.
We
probably
should
have
asked
some
more.
B
We
did
ask
about
async
programming,
which
only
got
39
and
gui
programming,
which
only
got
five
percent
positive
impressions,
but
that's
probably
not
too
surprising
either,
given
the
the
state
of
kind
of
like
gui,
programming
and
rust.
B
Sorry,
I'm
just
kind
of
seeing
where
we've
got
to
okay.
So
one
of
the
really
interesting
questions
that
that
we
asked-
and
this
is
a
suggestion
from
from
from
now
on-
from
the
foundation
and
at
microsoft,
so
she
suggested
asking
like
what
people's
biggest
worry
was
for
the
for
the
future
of
rust
or
what
things
were.
So
this
was
again
like
a
multiple
choice.
Questions
people
could
take
more
than
one
so
don't
expect
the
numbers
to
add
up
to
100.
the
the
biggest
sorry.
B
The
most
popular
worry
was
that
there
was
not
enough
industry
usage
of
rust,
and
that
was
at
38,
and
I
given
kind
of
like
how
positive
2021
has
been
in
that
direction.
I
would
expect
that
number
to
kind
of
like
be
falling
from
previous
years
and
fall
in
the
future
as
well.
B
The
next
biggest
worry
was
that
the
the
language
would
get
too
complex
and
33
of
our
respondents
have
all
sort
of
the
the
rust
users
who
who
filled
the
survey
had
that
worry,
followed
by
thirty
percent,
worried
that
the
developers
on
the
project
weren't
getting
the
the
support
that
they
needed
and
26
percent
of
people
were
not
worried
about
anything
at
all.
So
so
that's
the
the
nice
number
and
and
ever
every
other
warrior
there
are.
B
B
We
asked
quite
a
lot
of
information
about
developers,
kind
of
experience
and
and
about
who
they
are,
I
guess,
but
but
and
kind
of
we'll,
we'll
we'll
get
deeper
into
that
in
the
and
the
the
data
we
share
later
on.
But
for
today
the
the
bit
I
wanted
to
share
was
about
people's
experience
with
other
programming
languages.
So
where
they've
come
from,
so
we
asked
whether
people
had
any.
B
B
So
the
the
the
most
popular
kind
of
oh-
and
I
said
so
so
this
year
we
we
changed
slightly
from
previous
years.
We
previously
asked
about
individual
programming
languages.
This
year
we
asked
about
kind
of
like
classes
of
programming,
languages
or
or
paradigms
so
the
the
most
popular
was
dynamic
programming
languages.
So
this
is
or
scripting
languages,
so
javascript,
ruby
python.
That
kind
of
the
83
of
our
users
have
decent
experience
with
those
languages.
B
Next
up
was
kind
of
your
your
classic
statically
typed
languages.
So
this
is
your
java.
C-Sharp
go
72
there
and
then
c
and
c,
plus
plus,
was
kind
of
is
kind
of
like
the
or
system
traditional
system
spoken.
Languages
is
kind
of
like
a
fair
ways
down
from
that
58
and
then
kind
of
modern
languages
with
kind
of
serious
type
systems.
So
this
is
like
scala,
kotlin
and
swift.
That's
24
and
functional
language,
statically
typed,
functional
languages
like
haskell
was
17
and
dynamically
type
function.
B
Languages,
like
list
was
even
fewer,
just
13,
so
I
I
think
it's
helpful
to
understand
kind
of
like
the
the
the
backgrounds
of
where
kind
of
like
rust
users
are
coming
from,
and
I
think
it's
really
interesting
that
you
know
the
the
kind
of
like
the
the
the
nearest
languages
or
languages
that
maybe
have
kind
of
like
a
lot
of
influence
on
rust.
B
Okay,
so
that's
that's
all
the
numbers,
hopefully
I
haven't,
bought
everyone
to
death,
like
I
say,
they'll,
be
kind
of
like
a
summary
report
for
for
team
members.
B
Hopefully
soon
we
don't
have
any
kind
of
like
firm
date
yet,
but
what
would
be
really
useful
to
know
both
for
for
the
analysis
that
we'll
be
doing
this
year
and
also
for
for
planning
the
survey?
You
know
the
end
of
this
year
and
in
future
years,
is
what
you'd
like
to
know
like
as
a
as
a
team
as
a
working
group?
What
would
you
like
to
know
about
rust
users?
B
Oh
sorry,
I
should
say
like
we
are
we're
not
just
constrained
to
the
kind
of
like
the
annual
community
survey
as
well
like
it
might
be
interesting
to
do
other
kinds
of
surveys.
B
So
what
we'd
like
to
know
is
what
you
would
like
to
know
and
if
we
can
figure
that
out
from
the
data
this
year,
then
we'll
try
and
get
you
an
answer,
and
if
we
can't,
then
that's
really
good
feedback
for
us
for
for
next
year,
as
well.
This
year's
survey
and
and
future
years
surveys.
So
so,
please,
let
me
know
or
ryan,
and
I
know
if
you,
if
you
have
any
of
that
kind
of
feedback,
so
so
yeah.
That's
that's
all
thanks!.
A
Great,
so
I
think
we
have
a
little
bit
of
time
here
to
do
a
question
period.
Nico
I'll
hand
it
over
to
you.
First,
it
looks
like
you
have
your
hand
up.
C
I
do
I
have
a
question
nick
I'm
curious:
did
you
cross-reference
the
backgrounds
that
people
came
from
with
anything
else
like
their
biggest
worries
or
like
what
they
why
they
use,
rust
or
and
so
forth?
So.
B
We
have
not
done
any
of
that
kind
of
like
deeper
analysis
yet,
and
you
know
deep
is
a
is
relative
and
I
realize
that's
not
super
deep,
but,
like
we
haven't
done
any
kind
of
like
cross-referencing,
we
haven't
really
dived
into
the
data
beyond
just
trying
to
get
kind
of
like
the
the
basic
numbers
at
this
stage.
So
I
think
that's
kind
of
like
that
kind
of
cross-referencing
is
super
interesting.
B
We
would
you
know,
there's
obviously
a
lot
of
different
cross-referencing.
You
can
do
and
kind
of
like
a
with
a
you
know,
data
to
size,
so
it'd
be
really
interesting
to
know
like
specifically,
what
like
folk
are
interested
in
like
particularly
like
interesting,
because
it's
actionable
for
the
team's
planning
or
whatever,
not
just
interesting,
because
it's.
D
B
B
There's
it's
so
I
thought
that
would
be
an
interesting
thing
to
say
today,
but
it's
actually
kind
of
difficult
to
interpret
because
there's
a
lot
of
overlapping
areas.
So
so
for
so
sorry,
I'm
just
kind
of.
B
Yeah,
so
so,
basically,
it's
kind
of
the
the
largest
domains
that
people
are
working
in
were
basically
kind
of
like
the
the
kind
of
web
back-end
networking
cloud
infrastructure
that
kind
of
group
of
domains
we
asked
about
it.
It
was
a
multiple
choice.
Question
we
asked
about
so
many
different
ones
that
it's
actually
kind
of
hard
to
compare.
B
So,
for
example,
we
asked
about
embedded
with
an
operating
system
and
without
so
maybe
if
we
combine
those
two,
then
it
will
be.
You
know
higher
up
the
list
than
it
looks
at
the
moment,
but
maybe
it
won't.
This
is
multiple
choice
and
maybe
everybody's
already
ticked
both
of
those.
B
So
it's
it's
one
of
those
questions
where
even
to
kind
of
like
get
the
simple
answers
takes
a
bit
of
analysis,
but
that's
that's
certainly
one
of
the
ones
that
I
plan
to
kind
of
like
dig
into
a
little
bit
for
the
the
initial
summary
data
that
we're
gonna
send
out.
Okay,.
C
Yeah
I'll
see
I'll
see
the
floor
to
josh,
but
I'll
just
note
before
I
go
that
I
I
think
it's
really
good
to
focus
on
what
you
do
in
response
to
the
data.
I
like
that,
but
also
that
I
think
like
with
domains
in
particular,
I
would
be
interested
to
try
to
do
some
of
that
cross-correlation
because
knowing
I
think
that
does
seem
very
actionable
to
me
to
know.
For
example,
you
know
people
who
are
doing
embedded
have
these
specific
concerns.
C
E
All
right
josh,
so
I
am
thrilled
to
hear
so
many
positive
sentiments
about
rust.
I
know
many
people
are
the
thought
crosses
my
mind
that,
like
we
try
to
reach
people
who
are
interested
in
answering
the
survey
but
aren't
necessarily
involved
in
rust
or
using
rust
actively.
But
it's
clear
that,
like
90
of
people
who
answer
the
survey
are
using
rust.
E
Are
there
any
plans
or
have
there
been
any
discussions
for
how
we
can
make
a
concerted
effort
to
reach
and
survey
people
who
have
bounced
off
of
rust
are
waiting
to
try
rust
because
there's
some
blocker
for
them?
Basically,
the
set
of
people
that
we
are
going
to
miss
information
from
because
they're
not
here
yet,
and
that's
a
circular
problem.
B
Our
users
really
has
not
really
been
owned
by
anybody
and
has
just
been
kind
of
ticking
along
over
the
years,
and
so
we
ryan-
and
I
have
kind
of
like
started
with
the
annual
survey
to
try
and
kind
of
get
deeper
into
this
area,
so
yeah,
so
absolutely
kind
of
like
understanding
the
users
who
bounce
off
is
is
really
important,
but
also
kind
of
really
difficult,
and
I
think
it's
interesting
that
we
get
like
10
may
not
sound
like
very
many,
but
that's
like
over
a
thousand
respondents
who
who
no
longer
use
rust,
filling
out
the
survey-
and
I
think
that's
kind
of
that.
B
You
know
the
only
data
we
have
of
anywhere
near
this
kind
of
like
scale
about
those
users,
and
you
know
you
know,
obviously
far
more
than
a
people
kind
of
like
fit
in
github
issues
or
whatever,
but-
and
I
think
kind
of
like
one
thing
we
kind
of
struggled
with-
was
what
exactly
we
wanted
to
kind
of
like
ask
those
users
so
so
yeah
I
mean,
I
think
that
the
the
survey
is
like.
B
Actually,
the
the
annual
survey
has
like
a
bit
more
reach
into
those
kind
of
former
users
than
than
any
other
tool
we
have
at
the
moment,
and
so
thinking
about
exactly
what
we
want
to
ask
them
like
in
in
the
following
years
would
be
really
good
to
know
beyond
that.
I
think
that
kind
of,
like
it's
important,
not
to
get
too
hung
up
on
surveying.
B
I
think
that,
like
getting
information
about
how
users
is
super
important,
but
often
like
a
survey,
isn't
the
best
way
to
do
that,
and
especially
with
users
well
non-users,
who
are
hard
to
actually
kind
of
like
track
down
and
get
to
take
part.
Then
we
might
get
much
more
useful
data
by
doing
kind
of
like
one-on-one
interviews
or
focus
groups
or
usability.
B
E
On
the
survey
in
that
way,
I
just
wanted
to
ask
if
there
had
been
any
thoughts
of
how
to
extend
that
reach
or
how
to
specifically
reach
those
people,
I'm
thinking
specifically
of
like,
as
we
try
to
make
the
language
more
usable.
I
would
love
to
make
sure
that
we
are
hearing
concerns
from
people
who
bounce
off
and
don't
come
back
and
not
just
people
who
bounce
off
lightly
but
are
still
close
enough
to
know
that
the
survey
exists
right
yeah.
E
B
A
All
right,
I
don't
think
we
have
a
few
comments
in
in
chat
here,
but
I
will,
I
think,
pass
it
over
to
wesley
now
and
we
can
get
started
with
the
compiler
team.
D
Ambitions
would
you
mind
pulling
the
slides
up
for
us?
Oh
yes,
I
can
do
that.
I
just
like
to
be
able
to
look
at
my
notes.
D
Perfect
great,
thank
you
yeah,
so
this
this
talk
is
basically
about
an
upcoming
blog
post.
That's
getting
published
titled
compiler
team
ambitions
for
2022
by
felix,
and
I
based
on
some
funding
we
did,
and
so
most
of
this
talk
is
actually
about
kind
of
the
meta
pieces
of
that
planning
and
not
so
much
about
the
content
of
the
blog
post,
but
there's
a
sneak
peek
at
the
contents
of
the
blog
post
at
the
end.
D
So
if
you
could
go
to
the
next
slide,
yeah
so
kind
of
the
background
here
is
just
an
observation
that
in
previous
years
the
compiler
team
is
often
kind
of
oscillated
between
having
planned.
F
D
Ahead
of
time
plans
for
the
year
and
processes
to
try
to
achieve
those
plans
and
working
groups
and
things
like
that
and
then
other
times
things
have
just
been
very
unplanned
and
ad
hoc
and
and
that's
fine
too,
but
for
this
year
we
wanted
to
be
a
little
bit
more
organized
and
that's
sort
of
in
contrast
to
last
year,
which
was
which
was
very
ad
hoc,
even
though
lots
of
really
great
stuff
happened.
So
next
slide
so
part
of
the
goals
of
our
process.
Here
was
a
few
simple
things:
one.
D
We
wanted
to
find
out
what
contributors
were
actually
working
on,
there's
a
lot
of
people
in
the
compiler
team
and
especially
on
the
compiler
team
contributors
sub
team,
and
most
of
them
are
self-motivated
to
work
on
things.
It's
not
really
top
down.
You
know
felix
and
I
can't
come
up
with
a
list
of
things
and
tell
people
to
go
work
on
them.
It's
really
what
interests,
people
and
and
what
they
want
to
work
on
and
that
sort
of
decides.
D
You
know
the
the
different
things
they
contribute
and
it's
not
always
clear
to
us
what
people
are
interested
in
working
on
or
might
want
to
work
on,
but
aren't
sure
if
you
know
there
are
other
people
that
could
support
them,
working
on
those
things
or
not
kind
of
related
to
that
we
wanted
to
see
if
there
were
common
themes
to
those
those
things
that
people
wouldn't
work
on
between
different
sets
of
contributors,
we
were
really
hoping
that
there
would
be.
D
Ideally
what
we
would
like
to
do
is
spin
up
some
working
groups
or
project
groups,
or
even
if
it's
just
you
know,
one
or
two
people
like
try
to
get
some
people
connected
so
that
they
know
you
know
who's,
maybe
interested
in
working
on
that
same
thing.
Who
could
they
bounce
ideas
off
of
who?
Could
they
ask
for
code
reviews
things
like
that?
D
We
wanted
to
give
the
community
an
idea.
What
we're
working
on
the
release
team
does
a
really
great
job
showing
off
what's
in
every
release
that
goes
out,
but
I
think
it's
not
always
obvious
to
the
larger
rust
community.
What
might
be
coming?
You
know
in
the
very
short
term
or
in
kind
of
a
more
medium.
You
know
over
the
course
of
2022
kind
of
time
frame.
D
We
wanted
to
highlight
some
of
the
ways
that
the
community
can
help
out,
even
though,
like
I
said
before,
we
kind
of
are
a
large
team.
We
want
to
keep
growing
that
team.
We
want
to
enable
new
people
to
contribute
to
the
compiler.
D
We
want
to
grow
people
in
the
roles
that
they
already
have
in
the
organization,
and
we
also
you
know
going
back
to
what
people
want
to
do.
We
heard
from
contributors
that
some
of
them
were
interested
in
mentoring,
people
for
specific
roles
or
specific
kind
of
projects,
or
things
like
that,
and
so
we
wanted
to
be
able
to
highlight
some
of
those
efforts
and
then
finally,
we
also
wanted
to
showcase
the
growth
and
maturity
of
the
project.
D
We
have
a
lot
of
very
consistent
contributors.
We
have
people
who
work
on
rust
in
their
free
time
who
are
paid
to
work
on
rust
and
really
just
showing
off
how
many
people
get
back
the
project
or
contribute
the
project
in
various
ways.
I
think
is
a
really
big
sign
of
maturity
for
the
project
and
really
speaks
to
some
of
the
stuff
that
you
know
we're
doing
so
next
slide.
D
So
this
process
was
kind
of
come
up,
informally
and
and
on
the
fly
it
wasn't
really
given
a
whole
lot
of
thought
ahead
of
time.
So,
while
this
I
think
has
worked
well
for
us,
there's
definitely
you
know
tweaks
and
things
that
could
probably
be
done
to
streamline
or
improve
it.
But
the
very
first
thing
we
did
was
just
open
a
thread
on
the
tea
compiler
suelop
channel.
To
literally
just
ask
people
to
spitball
ideas
for
what
could
go
on
the
roadmap
and
kind
of
see
what
people
might
be
interested
in
working.
F
D
Or
what
they
thought
you
know
would
be
a
good
thing
to
work
on
and
then
separately
felix
and
I
wrote
up
kind
of
lists
based
on
some
of
the
feedback
in
that
thread,
based
on
things
that
we
knew
people
in
the
project
were
already
working
on
or
that
were
they
were
very
interested
in
working
on
or
things
that
we
thought
could
you
know
would
be
great
to
tackle
if
we
had
the
resources
or
whatever.
D
That
separately,
we
came
together
and
we
consolidated
those
listed
in
one
document
and
one
of
the
kind
of
really
interesting
things
that
emerged
at
this
point
was
a
very
clear
distinction
between
a
list
of
things
that
we
felt
like
we
could
achieve
this
year
very
concretely
and
we
decided
to
call
those
things
initiatives
and
then
there
was
another
list
of
things
that
we
both
thought
would
be
excellent
if
we
could
get
done,
but
as
it
is
now,
we
don't
really
know
that
those
things
will
get
done
this
year,
and
so
we
called
those
things
aspirations.
D
So
after
that
we
went
back
to
the
compiler
team
and
the
compiler
team
contributors,
we
send
some
emails
with
links
to
the
consolidated
document
and
scheduled
one
of
our
friday
design
meetings
just
to
go
over
the
document
and
read
it
and
talk
about
it
with
people
and
see
what
the
feedback
was,
whether
we
were
on
the
mark
or
had
missed
things
and
even
just
pm,
to
people
to
make
sure
we
got
feedback
from
everybody
on
the
team
and
there
wasn't
something
important.
We
were
missing
or
whatever
and
then.
D
D
D
I
think
it
was
totally
worth
it,
but
it
is
a
time
investment
to
do
something
like
this
related
to
that
we
set
deadlines
for
various
pieces,
and
I
think
that
was
really
helpful
as
a
forcing
function
to
make
sure
that
stuff
got
done,
but
it
was
also
important
to
kind
of
remember
that
a
lot
of
these
were
kind
of
self-imposed,
and
so
if
there
was
some
really
important
reason
to
delay
something
or
whatever,
then
we
could
do
that
and
not
to
get
too
fixated
on
on
hitting
every
single
deadline.
D
You
know
exactly
and
then
I
think
one
of
the
really
interesting
things
that
came
out
of
this,
for
me
was
the
outcome
of
just
having
people
talk
about
what
they
hoped
or
what
they
wanted
or
planned
to
do.
This
year
was
extremely
valuable.
D
There
were
multiple
areas
where
felix,
and
I
thought
it
would
be
really
great
if
we
could
do
this,
and
maybe
even
one
or
both
of
us
were
interested
in
doing
something
there.
We
just
didn't
know
you
know,
would
we
have
enough
people
to
make
it
an
initiative
instead
of
an
aspiration
and
debugging
in
particular,
was
one
area
where
we
thought
you
know.
We
really
need
to
do
something.
The
survey.
B
D
Nick
mentioned
earlier,
debugging
was
one
of
the
pieces
that
really
stuck
out
from
that
as
currently
very
lacking
to
people
in
the
community,
and
it
turned
out
that
there
were
a
lot
of
people
on
the
team
that
were
interested
in
contributing
here.
So
we're
actually
spinning
up
a
debugging
working
group
this
year
to
make
some
progress
on
that.
D
So
kind
of
a
sneak
peek
as
to
what's
in
the
blog
post,
there
were
three
main
things
or
three
main
themes.
I
should
say
that
we
identified
for
2022.
one
was
fulfilling
russ
promise,
which
is
really.
D
D
So
this
is
typically
improvements
to
the
technology
or
the
tooling
or
the
infrastructure
or
whatever,
that
benefits
people,
maintaining,
maintaining
and
extending
the
compiler
itself
next
slide,
and
so
between
those
three
themes
and
the
things
that
we
concretely
thought
we
could
do
the
initiatives
and
the
things
that
we
hope
or
would
love
to
do
if
we
had
infinite
resources,
but
we're
not
sure
that
we
can
actually
get
done
this
year.
We
have
these
lists
of
topics
so
addressing
issues
of
unsoundness
in
the
compiler.
D
We
think
we
can
make
concrete
progress
on
that
this
year.
We
think
we
can
make
concrete
progress
on
various
pieces
of
asic
rust,
like
implementations
for
async
functions
and
traits,
and
some
of
the
other
enhancements
around
just
using
async
rust.
We
think
we
can
make
a
lot
of
great
progress
on
debugging.
D
We
think
there
are
some
pieces
there
that
are
probably
going
to
be
more
aspirational
in
nature,
really
deep
integrations
with
gdb
and
lldb
and
windy
bg
and
visual
studio
and
the
multitude
of
debuggers
out
there
is.
We
would
love
to
have
that,
but
we
think
that's
probably
aspirational
this
year
this
year,
we
really
like
to
focus
more
on
fixing
some
of
the
kind
of
fundamental
issues
and
making
things
have
a
really
solid
foundation
there.
D
D
Expressiveness
is
really
kind
of
about
the
gap
between
things
that
have
been
approved
in
russ
the
language
and
things
that
are
stable
on
a
stable
compiler
for
things
that
are
not
implemented
at
all,
currently
in
the
compiler
and
there's
a
lot
of
those.
So
we
we
think
we
can
make
progress
in
some
of
those
things
and
other
things
are
probably
going
to
be.
You
know
in
the
future
and
then
finally,
librarification
is
really
about
splitting
out
pieces
of
compiler
so
that
they
can
be
reused
across
other
projects.
D
This
impacts
things
like
using
mirror
for
formal
verification,
or
even
some
of
the
things
within
the
project
like
miri
and
address
sanitizers,
and
things
like
that
and
then
finally,
the
things
that
we
would
love
to
do,
but
we
think
are
probably
at
least
currently
not
going
to
get
done
this
year,
addressing
the
backlog,
high
issues.
D
We
have
plans
to
try
to
triage
them,
but
I
don't
know
that
we
will
actually
make
progress
in
resolving
you
know
a
vast
majority
of
them
or
something
we
would
love
to
have.
You
know
improvements
to
how
the
compiler
team
runs
organizationally
or
procedurally,
we
would
love
to
see
more
work
on
some
of
our
alternative
back
ends
like
cogen,
gcc
and
cogent
and
crane
lifts,
and
I
think
there
probably
will
be
things
that
happen
there
this
year,
but
I
don't
know
that
we
will
be
able
to
drive
those.
F
So
just
want
to
jump
in
quickly
here,
because
I
watching
leslie
talk.
There
was
one
thing
here
that
I
want
to
stress.
Anything
that
you
want
to
add
to
the
compiler
is
in
some
ways
an
aspiration.
These
concrete
aspirations
were
chosen,
particularly
because,
while
we
don't
have
the
resources
today
to
do
them
based
on
what
people's
timelines
are,
they
do
have
owners.
These
are
things
where.
If
someone
were
to
show
up
and
say
I
want
to
help
with
this,
we
do
have
a
plan
in
terms
of
there's
a
person
named
who
says.
F
Yes,
I
am
willing
to
help
mentor
somebody
with
getting
started
in
this
area.
So
it's
really
important
to
me
that
we've
teased
out
the
aspirations
as
things
that
it's
deliberately
meant
to
be
a
way
to
invite
people
to
come
in
and
help
us
succeed
this
year
and
the
other
detail
there
is.
A
number
of
these
items
in
this
table
are
specifically
ones
that
they're
meant
to
be
things
where
you
don't
have
to
have
a
lot
of
expertise
in
the
compiler
source
code
itself.
F
To
make
big
impact
you'll
see
the
spelled
on
the
blog
post
itself,
but
I
want
to
stress
it
here,
since
we
have
such
a
mix
of
people
in
this
audience.
I
want
to
stress
this
there's
items
on
here,
such
as
the
team
operations
item,
where
there's
big
bullet
points
for
things
that
you
we
hypothetically
do
not
need.
Necessarily
someone
who's
got
compiler
expertise
to
deliver
in
other
ways.
The
examples
there
are
things
like
automated
test
reduction.
F
Tooling
is
an
area
that
I
think
we
could
make
big
strides
on,
and
you
don't
have
to
be
a
compiler
expert
to
do
that
and
our
performance
profile.
Our
what's
the
word,
our
benchmarking
suite
yeah
our
performance,
benchmarking
infrastructure
has
a
lot
of
needs
that
don't
require
compiler
expertise
to
deliver
on.
It
just
needs
that
a
lot
of
us
don't
have
expertise
with
like
web
front-end
things.
D
Yeah
yeah,
thanks
for
adding
that
I
definitely
I
was
trying
to
trim
the
chart
down
a
little
bit
and
and
cut
off
the
owners
and
things,
but
there's
more
details
on
all
of
these
things
in
the
blog
post
and,
as
felix
said,
there's
also
links
to
the
people
that
own
all
of
these
certain
areas.
Some
of
these
areas
are
split
across
concrete
initiatives
and
aspirations,
and
so
they
have
different
owners,
some
of
them
for
those
different
things,
but
all
of
the
details
in
the
blog
post
is
going
out
tomorrow.
A
All
right,
great
yeah,
so
we
have
a
few
minutes
for
questions
here.
I'll
wait
to
see
if
anything
comes
up
in
chat,
but
I'm
not
sure
anybody
has
put
their
hand
up
just
yet
niko
I'll
hand
it
over
to
you.
C
Yeah,
I
didn't
see
any
hands
up,
but
I
have
a
question
and
thank
you
all
a
second
remy
here
I
was
wondering
I
was
thinking
about
sharing
knowledge
and
plans
and
I
think
the
mcp
process,
and
so
on
has
been
great,
but
I'm
realizing
like
as
I
watch
some
things
go
by
that
I
at
least
partly
a
function
of
just
not
having
as
much
time
as
I
would
like
to
follow
along
in
zulip.
Don't
really
know
like
how
we
plan
to
re-architect
here
and
so
forth.
C
C
F
So
this
wrote,
the
content
of
this
document
proposal
was
mainly
focused
on
technical
stuff.
Like
there's
a
point
where
I
think
I
especially
called
out-
and
some
of
it
like
we're
just
focusing
on
technical
stuff
here,
not
social
processes
et
cetera,
and
I
don't
I
don't-
have
a
good
reason
for
why
we
chose
to
do
that.
It
was
just,
but
I
figured
be
of
interest
to
the
larger
audience
at
and
that's
the
other
question
you
asked
about
knowledge.
Sharing.
I'm
curious
is
your
is.
F
Are
you
asking
that
about
specifically
about
cro
sharing
knowledge
across
other
teams?
Are
you
meaning
both
sharing
knowledge
within
the
team
and
across
other
teams?.
C
I
meant
more
like
amongst
compiler
team,
but
and
sort
of,
I
guess
the
somewhat
larger,
like
compiler
team
and
adjacent
people
who
hack
on
the
compiler
like.
I
would
love
to
to
to
hear
more
about
the
plans
around
around
here
stuff.
You
know
specifically,
but
I
and
I
just
think
that
there
it
would
be
great
to
try
to
have
some
organizational
like
organized
effort
to
to
have
more
conversations
like
that
happening,
and
I'm
wondering
if
that's
something
that
could
be
a
good
working
group.
D
Yeah,
I
I
think
that
would
be
great.
I
think
it
sort
of
falls
in
a
little
bit
with
some
of
the
team
operations
things.
I
think
there
were
a
few
non-technical
things
that
did
get
called
out
there
and
that
would
probably
be
a
good
fit
for
some
of
that.
C
F
There
was
a
question
in
the
chat
from
frederick
tens.
Is
there
an
overview
of
what's
concretely
planned
in
the
short
term,
for
the
improvement
categories
which
have
concrete
initiatives?
I
think
the
best
answer
there
is
sometimes
like.
I
think
that
the
text
of
the
blog
post,
which
we'll
see
when
it
gets
posted
it
does
spell
out
some
amount
of
specific
things
for
the
different,
different,
concrete
initiatives
in
terms
of
spelling
out
what
their
owners
are
planning
to
deliver.
F
But
I
will
admit,
I
think
it
didn't
get
into
as
enough
as
much
detail
as
some
people
would
hope
in
terms
of
I've.
Definitely
had
some
people
read
the
document
and
gave
me
feedback.
This
thing
that
you
listed
here
is
like
a
multi-year
initiative.
What
are
the
actual
goals
and
milestones
that
you're
going
to
be
delivering
on
this
year,
and
my
reaction
is
to
say
well
this
thing's
this
document's
already
late
as
it
is.
F
I
don't
want
to
go
back
around
and
try
to
get
like
that
level
of
detail,
but
like
what
like
what
is
said
in
terms
of
future
iterations,
the
document
I
think,
if
it
could,
it
would
be
good
to
get
that
level
of
concrete
detail
into
the
document
on
the
first
go-around.
If
we
can
do
it.
A
All
right,
it
looks
like
we're
at
the
end
of
questions
I'll,
give
it
another
few
seconds
here
all
right,
perfect!
Well,
thank
you!
So
much
wesley
and
felix
for
the
talk
here.
I'm
just
gonna
pull
us
back
over
to
the
agenda,
we're
almost
at
the
the
top
of
the
hour,
and
so
I'm
just
gonna
leave
it
open
for
another
few
minutes.
If
there's
any
announcements,
people
like
people
would
like
to
make,
but
if
not,
that
is
all
good.
C
I
have
an
announcement
so
doc
jones
and
I
have
been
discussing-
I
don't
know
if
any
of
you
saw,
but
there
was
a
paper
that
came
out
a
while
ago
about
doing
analysis
of
non-coding
roles
in
open
source
communities
and
they
analyzed
like
npm,
contributor
data
and
other
stuff
and
doc
jones,
and
I
have
been
discussing
some
with
the
authors
of
that
paper
who
are
really
interested
in
applying
their
kind
of
metric
analysis
to
rust,
and
one
of
the
things
I
was
hoping
for
is
that
if
people
are
on
this
call,
who
would
like
to
chat
about
that?
C
Maybe
we
can
do
it
in
the
social
hour
if
there
are
like
kinds
of
analyses,
you
would
like
to
do
to
look
at
what
kind
of
projects
are
active,
other
kinds
of
data
that
you
or
just
or
who
are
who
knows
what
piece
of
code
best
or
things?
There
are
questions
that
you
feel
like
you
could
possibly
answer
I'd
like
to
chat
about
them
during
social
hour.
So
that's
the
announcement.
A
Great
thanks
nico
anything
else
from
anybody.
E
Just
a
mention
that
instrument
coverage
is
going
to
be
stable
soon,
and
I
wanted
to
invite
people
to.
If
you
have
performance
sensitive
rust
code,
you
will
soon
be
able
to
do
instrumentation
based
code
coverage
on
your
code.
Try
to
figure
out
more
about.
What's
going
on
with
it,
I'm
looking
at
doing
some
of
the
same
stuff
with
profiling
and,
more
generally,
the.
E
There's
a
number
of
efforts
going
on
right
now
to
try
to
stabilize
some
of
our
long-standing.
This
has
been
unstable,
forever
kinds
of
features
like
cargo's
timing,
option
or
strip
or
20
other
things,
and
I
would
encourage
people
who
are
keeping
an
eye
on
particular
features
that
they
think
will
never
be
stable
and
who
have
kind
of
given
up
hope
on
them
being
stabilized
to
revive
that
discussion
and
like
hey,
I'm
still
interested
in
this.
What
can
I
do
to
help
with
this?
E
A
All
right
and
then
I'm
just
taking
a
look
at
chat
wesley.
I
can't
see
the
characters
that
you
put
in
because
they're
showing
up
as
blocks
for
me,
but
I
assume
that
was
not
putting
your
hand
up
at
justin.
Sorry,
those
are
those
were
just
celebrations
for
instrument
coverage
being
stabilized,
perfect.
Yes,
good
reason
for
excitement
all
right,
so
in
that
case
I
will
close
off
the
ctcft,
we'll
hop
over
to
the
social
hour.
So
thank
you,
everybody
for
coming
out
to
the
february
ctcft
and
we
will
be.
C
Part
of
one
other
thing
all
right,
we
were,
we
were
saying
we're
gonna,
do
a
longer
talk
about
this
next
time,
but
we're
looking
for
ways
to
to
grow
the
set
of
or
to
incorporate
suggestions
on
what
kinds
of
things
would
be
great
to
cover
during
the
ctcft.
C
A
Indeed,
yes,
organization
would
be
a
very
nice
for
our
background
setup
of
the
ctcfts
all
right,
so
yeah
we'll
hop
over
to
the
social
hour,
and
we
will
see
you
next
month.