►
From YouTube: RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy
Description
Closing Keynote: Safe Systems Software and the Future of Computing by Joe Duffy
Someday in the future, all important systems software on the planet will be written in a safe programming language. The questions are, when, and how do we get there?
In this talk, I will describe my experiences at Microsoft building a new operating system written entirely in a Rust-like safe systems language. I will also talk about my subsequent efforts taking those experiences and applying them to the heart of Windows, and the associated technical and cultural challenges.
A
So,
for
those
of
you
don't
know
me,
I
most
recently
worked
in
Microsoft
I
was
in
charge
of
the
languages
and
compilers
and
IDE,
and
taking
dotnet,
open
source
and
and
cross-platform,
and
all
those
sorts
of
things
I
was
actually
there
for
12
years.
A
significant
amount
of
the
time
was
actually
working
on
safe
system
software
not
to
cut
to
the
chase
too
much,
but
to
cut
to
the
chase.
You
probably
haven't
seen
much
about
it
because
we
actually
didn't
ship
it,
and
so
that's
actually
part
of
the
story.
A
A
So
as
soon
as
you
know,
the
Moore's
law
is
over
sort
of
panic
set
in
you
know
we
were
working
close
to
this
Intel
to
come
up
with
new
technologies
to
solve
that
and
software,
so
that
included
pretty
basic
things
like
introducing
thread,
pools
and
better
ways
of
introducing
concurrency,
better
synchronization
primitives,
pretty
basic
stuff
that
people
take
for
granted
these
days,
some
exotic
things
like
software
transactional
memory.
So
we
actually
add
a
version
of
the
CLR
with
STM
built
into
it
turns
out.
A
A
Parallelism
primitives
that
today
are
sort
of
the
underpinning
of
async
and
await,
as
you
see
them
in
c-sharp,
and
so
back
then
we're
working
with
you
know
the
F
sharp
team,
who
was
really
the
one
of
the
earliest
pioneers
of
doing
async,
await
and
trying
to
get
those
ideas
into
c-sharp
and
that
eventually
panned
out,
but
notably
absent
during
this
period,
was
anything
about
safety.
There's
a
little
bit
of
message
passing,
so
you
could
say
that
was
absent
as
well,
but
really
the
biggest
thing
was
safety.
A
It
turns
out
that
doesn't
work
in
practice
because
you
end
up
with
lock
contention
in
places
that
are
completely
bizarre,
that
you
didn't
expect,
and
so
it
turns
out
taking
a
step
back
and
thinking
about
safety
in
an
entirely
different
way
was
a
better
path
forward,
and
it's
not
that
STM
is
bad.
You
know
it's
definitely
got
its
place,
but
the
fundamental
architectural
principles
of
isolation
and
safety
were
far
more
important
and
we
sort
of
missed
the
point
back
then
and
partially
it
was
because
we
were.
A
A
The
windows
theme
will
recur
so
around
the
same
time.
Obviously
you
know
this
is
a
pretty
abysmal
situation.
It
really
hasn't
gotten
better
over
the
years.
In
fact,
it's
gotten
kind
of
worse.
You
know.
Every
week
you
see
the
top
of
hacker
news
is
like
Oh,
some
new
buffer
overrun
and
some
new
exploit
some
remote
code
execution
in
some
critical
piece
of
software.
That
literally
the
world
depends
on
its.
It
is
kind
of
ridiculous
that
we're
in
2017
and
the
situation
has
not
gotten
much
better.
A
Thankfully,
you
know
we're
all
kind
of
jointly
working
on
a
solution
to
that,
but
this
was
back
then
even
back,
then
we
were
looking
at
hey.
Security
and
Windows
is
really
terrible
and
it's
a
really
bad
PR
thing,
and-
and
this
is
back
around
the
trustworthy
computing
initiatives,
if
you
remember
that
you
know,
Bill
Gates
is
one
of
his
top
priorities,
and
so
this
is
top
of
mind
as
well,
and
so
you
add
those
together
and
we're
kind
of
like
hey
we're
screwed.
What
do
we
do?
A
You
know
the
windows
had
this
antiquated
threading
model
that
didn't
scale
any
of
you
that
know
comm
single
threaded
apartments,
you
know,
thread
affinity,
there's
so
many
kind
of
deeply
rooted
problems
in
the
architecture
that
we
were
really
running
into
a
wall
when
multi-core
arrived
and,
of
course,
the
growing
security
threat.
You
know
what,
if
it
accelerated
even
further,
and
this
lack
of
safety
at
the
very
fundamental
heart
of
the
system
became
a
critical
and
fundamental
weakness.
What
would
we
do?
A
You
can't
have
separate
authors
for
these
components,
and
so
we
looked
at
this
and
you
know
there
are
many
promising
alternatives
for
the
more
you
know:
Kiko's
arrows
kyoto.
So
these
sort
of
more
secure
capability
based
operating
systems
had
been
around
for
a
long
time.
We
had
been
working
on
safe,
at
least
typing
memory.
A
And
so
this
was
literally
reused,
no
code
to
start
an
architect
at
the
right
way.
Don't
focus
on
you
know,
compatibility,
that's
the
big
thing.
I,
don't
know.
If
folks
realize
how
big
a
Microsoft
compatibility
was,
you
know,
a
breaking
change
was
just
forbidden
completely,
even
if
the
only
way
that
it
was
allowed
was
it
was
a
security
fix,
but
people
really
took
compatibility
very
seriously,
and
so
we
were
saying
hey.
No,
it's
Greenfield,
we're
gonna
start
from
scratch
and
we'll
see
where
it
takes
us
and
really.
This
is
an
insurance
policy.
A
We
didn't
go
into
thinking,
we're
actually
going
to
replace
Windows.
We
thought
hey
worst
case.
We
could
take
some
of
the
ideas
and
apply
them
to
Windows
best
case.
We
don't
actually
need
it,
because
it's
an
insurance
policy,
and
so
we
focused
on
these
core
concepts,
isolation
and
so
singularity.
We
actually
took
some
of
the
singularity
ideas
to
start
with.
A
This
is
a
project
that
came
out
of
Microsoft
Research
that
use
software
isolation
for
safety,
so
it
was
actually
building
on
the
fact
that
I
had
type
in
memory
safety
at
its
core
to
actually
have
lightweight
isolation,
and
this
is
what's
necessary,
especially
compared
to
Windows,
where
the
the
process
model
is
so
terribly
heavyweight.
I
think
you
know,
Windows
thread
is
roughly
the
cost
of
UNIX
or
Linux
process,
and
so
you
know,
Windows
process
is
just
enormous,
ly
heavy
weight
and
that
discourages
some
of
the
message.
A
Passing
is
sort
of
important
architectures
that
we
saw
capability
based
security,
both
in
the
application
model
and
the
programming
model.
So
we
actually
use
the
fact
that
we
had
typing
and
memory
safety
to
actually
embed
capabilities
into
the
programming
model
such
that
you
an
object.
Reference
really
is
an
unfortunate
in,
and
so
we
actually
used
object
references
as
essentially
capabilities.
A
Similarly,
there's
no
ambient
Authority,
so
there's
no
mutable
statics,
no
thread-local
storage,
etc.
Error
model.
You
know
comparing
two
win32
with
return
codes
and
some
exceptions,
but
mostly
return
codes,
and
you
know
c-sharp
that
had
implicit
any
api
can
throw.
You
know,
have
no
idea
what
it
is
in
fact
there's
something
called
asynchronous
exceptions,
so
the
garbage
collector
can
come
in
and
like
suspend
your
thread
and
injecting
exception
between
arbitrary
instructions,
and
so
it's
not
even
possible
to
know
where
all
the
errors
can
come
from
which
I
know.
That
sounds
ridiculous.
A
It
is,
and
so
we
said,
no,
no
all
errors
are
going
to
be
explicit
and
we
will
bet
on
fail
fast
in
a
big
way.
So
not
just
fail
fast,
for
you
know,
unhandled
errors,
but
fail
fast
for
unexpected
conditions
like
arithmetic
overflow,
even
out
of
memory,
and
so
what
we
ended
up
with
was
essentially
free
safety,
sort
of
working
in
harmony,
memory,
safety,
type,
safety
and
concurrency
safety
for
all
code,
with
the
exception
of
essentially
some
very
low-level.
A
You
know
microkernel
stuff,
that
interface
with
the
hardware,
but
99%
of
the
system
was
type
memory
and
concurrency
safe
code,
so
that
was
sort
of
a
system
architecture,
and
so
we
got
to
you
know,
writing
lots
of
code
and
it
turns
out.
You
know
we
started
using
static
analysis.
We
started
from
c-sharp.
Why
don't
we
start
from
c-sharp?
Well
we're
at
Microsoft.
So
that's
one
reason,
and
so
you
know
C
sharps
are
a
great
language.
Is
very
you
know
productive,
but
it
definitely
has
some
problems
like
the
fact
that
exceptions
can
permeate.
A
You
know
or
emanate
from
any
instruction.
There
are
other
problems
too.
It's
garbage
collected
there's
no
way
to
do
stack,
allocation,
there's
no
notion
of
lifetime
safety,
there's
no
notion
of
concurrency
safety,
and
so
we
essentially
took
c-sharp
and
we
started
changing
it
and
the
goal
was
really.
A
You
know
this
is
sort
of
a
false
bifurcation
of
the
space
but
rough
approximation.
You
know
you
tend
to
have
you
know
performance
and
safety
and
productivity
and
they're
often
net.
You
know
odds
with
one
another,
so
we're
looking
for
the
sweet
spot
where
it
was
a
safe
and
productive
language
while
also
being
performant
and
what
we
did
is
we
sort
of
went
and
looked?
You
know.
A
I
was
familiar
with
a
lot
of
the
research
in
you
know:
sort
of
advanced
type
systems,
I'm
a
big
Haskell
fan,
so
we
went
and
basically
dug
around
you
know.
I
was
worried,
you
know
cyclone
and
all
these
you
know
region
based
systems
in
the
past
and
borrowing
and
effect
types,
and
we
sort
of
took
all
those
things
and
threw
them
into
a
blender
along
with
c-sharp
and
said,
okay.
A
What
what
actually
comes
out
and
turns
out
what
came
out
was
something
that
was
really
a
good
blend
of
some
of
the
productivity
you
haven't:
C
sharp
and
the
performance
we
needed
and
the
safety
we
needed
and
it
turns
out.
You
know
this.
This
was
all
happening
2007-2008
somewhere
in
that
timeframe,
and
it's
funny
because
there's
around
the
timeframe
that
you
know
some
of
the
rust
concepts
started
coming
out
and
so
I
remember,
you
know
we
would
compare
notes
with
some
of
the
early
rusts.
A
A
You
would
actually
hit
Midori
on
the
back
end,
we'd
be
serving
up
requests
and
that
that
was
massively
parallel,
because
I
use
deep
neural
networks
and,
and
it
was
using
all
safe
parallelism
and
it
was
it
replaced
the
existing
1
million
lines
of
code
C++
system
that
had
existed
beforehand,
so
better
performance
safety,
better
productivity,
and
it
was
great
and
it
turns
out-
we
were
trying
to
figure
out
ok,
so
this
experiment
seems
to
be
going
well.
What
are
we
gonna
do
next,
and
so
things
like
this
started
happening.
A
You
know
the
government
actually
came
out
and
said:
hey
you
shouldn't
be
using
Internet
Explorer,
because
it's
just
not
safe.
It
turns
out
a
lot
of
these
bugs
in
Internet
Explorer
were
used
after
free
bugs.
Basically,
what
would
happen
is
you'd,
be
on
a
thread.
You'd
call
out
to
some
user
code
run
the
JavaScript,
it
would
call
back
into
the
the
the
engine
and
the
engine
would
reenter
into
some
piece
of
code
that
wasn't
expecting
to
be
rendered.
A
It
would
release
some
critical
resource
and
then
you
unwind
the
code
and
the
memory
would
be
freed
and
game
over,
and
this
happened
all
the
time
and
Internet
Explorer
and
it's
partially
the
way
they
wrote
the
code.
What
is
partially,
you
know
just
a
hard
problem.
There's
a
huge
C
in
C++
code
base.
I
should
mention
just
as
an
aside,
even
though
Windows
and
a
lot
of
its
components
are
C++,
it's
really
C
with
classes,
and
so
it's
not
very
modern,
the
C.
A
And
so,
as
we
talk
about
some
of
the
future
improvements,
that's
something
to
keep
in
mind.
So
we
went
to
Windows.
So
we
actually
moved
the
project
into
the
windows
team
and
said:
ok,
how
do
we
actually
make
this
thing
happen?
It
turns
out
we
bit
off
a
lot
there
and
we'll
see
the
outcome.
Wasn't
wasn't
awful,
but
I
think
this
starts
to
talk
to
some
of
the
challenges
that
we
have
with
safe
systems,
programming
in
particular.
A
Essentially,
what
we
found
was
there
are
a
lot
of
guys
who
have
been
and
gals
who've
been
programming
C
for
the
last
you
know
thirty
years,
and
not
only
were
unwilling
to
accept
to
adopt
some
of
the
C++
things
that
would
make
their
lives
easier,
like
smart
pointers
and
everything
and
never
mind
some
new
fancy
language
that
had
this
type
and
memory
safety
stuff
like.
Why
do
we
need
that
right?
We
seem
to
be
doing
well
without
all
those
fancy.
Things
see
see
previous
slide
with
the
use
after
free
bus.
A
It
is
human
human
challenges
that
are
going
to
get
in
the
way
like
has
anybody
talked
to
Lennis
about
whether
he
wants
to
replace
parts
of
the
Linux
kernel
with
rust,
good
luck,
and
yet
that's
where
we
need
to
go
so
the
outcome
of
this
so
I'll
save
you,
the
the
gory
details
of
what
it
looked
like
in
the
end,
but
essentially
we
ended
up
with
lots
of
learning,
unfortunately,
not
shared
broadly,
which
is
shame
on
us.
We
should
have
a
bride
in
research
papers
the
whole
time.
A
If
the
project
started
in
Microsoft
of
today,
it
would
have
been
open-source.
That's
a
sort
of
a
big
change,
since
when
I
was
when
I
was
there
or
towards
the
end
of
my
tenure
there,
we
did
end
up
with
some
improvements
to
c-sharp,
so
we
basically
said.
Okay,
let's
take
this
all
the
sets
of
things
that
we
needed
to
change
and
dotnet
and
c-sharp
and
make
you
know,
bring
those
back
to
c-sharp
so
that
it
could
be
used
for
more
System
z,
things
it
turns
out.
You
know,
got
some
nice
performance.
A
Wins
slices
are
coming
out,
we'll
just
basically
ability
to
take
a
subsection
of
an
array
without
actually
having
to
copy
and
allocate
it's
something
that
should
have
been
there
from
day
one,
but
wasn't
many
of
them
still
in
the
works.
We
also
launched
a
bunch
of
efforts
to
try
to
improve
the
state
of
affairs
in
C++.
You
probably
hate
me
for
that.
A
I
kind
of
I
have
trouble
sleeping
with
myself
at
night,
sometimes
as
well,
but
some
good
things
came
out
of
it,
like
you
know,
better
ways
of
writing:
C++,
better
tooling,
to
enforce
some
of
the
the
safety
things
you
know
really
with
modern
C++.
You
can
stick
to
a
safer
subset
with
smart
pointers
and
the
team
tried
to
define
you
know,
sort
of
a
borrowing
like
thing
that
would
work
with
supercilious
references
and
smart
pointers.
A
So
you
didn't
have
these
use
after
free
issues
running
rampant,
so
I
want
to
talk
a
little
bit
about
some
of
the
key
lessons
from
from
this
overall
experience
like
I,
said:
I
hope
not
to
be
depressing.
So,
let's
get
on
to
the
inspiration
and
innovation
part.
So
what
what
worked?
Well
surprisingly,
safety
Everywhere
worked
I
I
thought
that
was
the
biggest
bold
bet
that
we
were
making
I
thought
there
was
no
chance,
it
would
work.
You
know
the
idea
of
writing.
Entire
operating
system
with
safe
code
just
seemed
crazy.
A
At
the
time
everybody
else
told
us
we
were
crazy.
What
was
particularly
interesting
is
that
you
could
actually
have
data
parallelism
because
we
had
data
race,
free
ways
of
introducing
parallelism.
This
is
nothing
new
to
folks,
you
know
using
rust,
but
at
the
time
this
was
a
pretty
novel
and
their
productivity
wins.
As
a
result
of
that,
you
know
just
not
having
to
worry
about
all
the
classical
you
know,
buffer
overruns
and
and
standard
things
that
just
kill
productivity
and
suck
your
time
dry.
You
know
debugging,
just
we're
not
present
by
construction.
A
Where
this
phrase
you
know
correct
by
construction,
which
was
a
little
bit
of
a
lie,
because
you
know
it's
not
really
correct
by
construction
safe
by
construction.
It
had
a
nice
ring
to
it.
So
the
magical
combination
of
isolation,
security
capabilities
and
message
passing
was
actually
really
powerful.
Actually
you
see
this
in
Erlang
and
other
you
know
even
some
programming
models
that
you
don't
even
need
to.
You
know
change
the
language
like
octa.
For
example,
it
really
you
know
most
of
the
system
was
massively
parallel
because
of
this
alone.
A
I.
Think
one
of
the
funny
stories
I
like
to
tell
when
we
first
ported
the
speech
server
to
this
model.
It
was
in
C++
and
he
used
H
results
and
it
turns
out,
like
all
Taiwanese
speech,
requests
were
failing
with
the
same
error
code
and
the
code
just
silently
forgot
to
check
the
H
result,
and
so
some
garbled
answer
would
come
back
every
single
time
now.
A
I,
don't
know
what
it
says
about
the
QA
and
validation
that
this
wasn't
caught
before
get
into
production,
but
when
there
was
poured
into
a
fail
fast
model
boom,
it
just
failed
right
away.
You
found
it,
it
turns
out.
You
know
we
ran
pretty
aggressive
stress
programs,
you
know,
run,
run
one
program
and
do
as
much
as
you
can.
You
know,
run
multimedia
stuff
in
the
background
with
some
web
serving
with
some.
You
know
random,
just
random
things
at
compile
going
on
in
the
background
and
see
what
fails
and
it
turns
out.
A
We
get
to
the
point
where
most
of
the
failures
were
actually
integer
overflows,
because
we
failed
fast
on
integer
overflow,
it's
kind
of
annoying,
but
it
actually
pointed
out
like
hey:
did
you
mean
for
this
integer
to
overflow?
In
some
cases?
It's
okay,
you
know
it's
just
a
simple
performance
counter
or
something
about
in
many
cases
that
actually
pointed
out
a
bug
in
the
system
that,
for
many
other
systems
would
have
lain
dormant
for
who
knows.
A
You
know
years
if
not
longer,
and
the
result
was
performance
parody
with
Linux
and
Windows,
so
we
measured
mostly
server-side
benchmarks
like
spec
web
and
some
internal
benchmarks.
The
speech
recognition
done
from
mark
a
lot
of
client-side
benchmark
so,
like
you
know
some
spider
and
octane,
and
these
sorts
of
things.
But
you
know
our
goal-
wasn't
really
to
beat
the
performance
of
a
lot
of
these
systems,
although
we
ended
up
doing
that
largely
because
of
the
inherent
concurrency
in
the
process
model.
A
But
the
fact
that
we
even
got
close
exceeded
our
expectations,
I
mean
we
thought
we
would
never
get
there.
We
thought
this
is
gonna,
be
the
thing
that
killed
the
project
like
we'd,
never
get
to
performance
parity
and
in
the
end
people
really
didn't
care
about
the
performance
that
much
it
wasn't
like
a
selling
feature
and
I,
don't
think.
Even
at
10
or
20
percent
performance
hit
for
some
scenarios
would
have
been
catastrophic.
I
think
people
would
have
accepted
the
benefits
that
you
get
from
the
safety
and
the
productivity.
I
would
say.
A
You
know
we
wrote
five
seven
million
lines
of
code,
something
like
that
with
the
team
of
100
people,
we're
constantly
rewriting
pieces
of
the
system
as
we
went,
because
we
were
learning
as
well.
The
system
was
built
on
itself,
so
it
was
fairly
complicated,
but
for
a
team
of
100
you
know
we
basically
built
you
know
editors,
web
browsers,
compilers.
A
You
know
a
shell
file
system.
Networking
stack,
basically
everything
that
an
opera
state
operating
system
has
notepad.
You
know
everything
from
the
bottom
to
the
top
was
just
you
know,
100
people
and
doing
that
in
C
and
C++
like
I.
Just
would
not
have
happened.
It
really
wouldn't,
but
here's
the
things
that
didn't
work
and
I'm
gonna
spend
a
lot
more
time
on
these.
A
It's
short
term
productivity
and
what
I
mean
by
that
is
like
how
quickly
can
I
just
write
a
piece
of
code
and
see
what
it
does
it
turns
out.
That
was
a
constant
struggle
for
us.
I'll
talk
a
little
bit
about
that.
In
a
moment,
people
are
generally
unwilling
to
give
up
productivity
now
for
a
gain
later
on.
Maybe
maybe
there's
just
a
thing
in
like
the
United
States
or
something
everybody
wants.
Instant
gratification.
I
want
to
see
it
now,
but
the
reality
is,
you
know
the
business.
A
You
know
business
happens
that
our
breakneck
pace
nowadays,
you
know
startups-
are
coming
and
going
all
the
time.
It's
you
know
really
is
innovation
happens
a
lot
faster
and
so
anything
that
seems
like
it's
an
impediment
to
succeeding
at
that,
which,
frankly
is
the
thing
that
my
you
know,
CEO
or
whatever
is
gonna
reward
me
for,
like
that's
a
difficult
equation
for
a
lot
of
people
to
work
through
people,
as
I
mentioned,
you
know
really
convincing
people
that
hey
yeah,
you
can
write
safe
systems
code
safety
is
possible.
A
Like
you,
don't
need
to
use
C
and
C++.
You
know
you
can
actually
get
a
lot
of
benefits
from
using
this
thing.
It's
just
a
lot
of
people
are
stuck
in
there
in
their
ways
and
it's
it's
a
new
concept
for
a
lot
of
people
like
if
you've
been
reading
research
papers
for
last
twenty
years.
Thirty
years,
it's
not
a
new
concept,
but
there's
a
lot
of
sort
of
bias
that
people
have
against
even
the
word.
A
A
We
caught
hundreds
of
buds.
If
not
thousands
I
mean
you
can't
even
quantify,
because
you
catch
a
bug
simply
by
the
program,
not
compiling.
So
maybe
it's
even
millions
of
bugs
I.
Don't
know
it's
a
large
number
of
folks
that
we
caught
that
never
made
them
their
way
into
the
system.
People
take
that
for
granted,
there's
not
an
easy
way
to
quantify
it,
unfortunately,
and
even
the
ones
that
did
become
bugs
because
of
defense-in-depth
the
fact
that
you've
got
this
belt
and
suspenders
type
and
memory
safety
thing.
Underneath
you
it's
it's
harder
to
break.
A
You
know
basically
jailbreak
the
whole
system
you
can,
even
if
you
find
an
exploit
up
here,
well
turns
out
you're
gonna
turn
around
and
try
to
do
something
over
there
and
that's
gonna.
You
know
fail
fast
on
you,
so
that
defense-in-depth
actually
was
very
powerful
as
well
and
using
the
type
system
we
actually
used
a
lot
of.
We
use
that
to
enable
a
bunch
of
pretty
novel,
compiler
optimizations.
You
know
it's
interesting
to
see
the
Const,
a
generic,
constant
valuation
conversations
today.
A
So
like
one
of
the
nice
things
is
because
we
had
immutability
in
the
type
system
and
all
statics
were
guaranteed
to
be
immutable.
We
can
actually
evaluate
all
statics
at
compile
time,
and
so
all
these,
like
giant
tables,
that
you
have
to
build
up,
that
that
cost
you
at
runtime,
because
you
have
to
well
in
c-sharp
at
least
it.
Basically,
it
does
double
check,
locking
to
make
sure
that
things
are
initialized
and,
and
we
could
elide.
All
of
that.
A
It
turns
out
that
was
leaner,
like
5%
of
the
instructions
throughout
the
entire
system
could
be
alighted
simply
because
we
had
guaranteed
frozen
immutable
objects,
which
it
turns
out,
is
much
closer
to
sort
of
c++
and,
in
terms
of
you
know,
manual
initialization
in
context,
birth.
And
yet,
despite
these
wonderful
things,
people
didn't
love
it
all.
The
time
I
would
say:
don't
underestimate
the
syntactic.
You
know
a
lot
of
people
say
office
in
text
doesn't
matter
what
matter
is
the
is
the
concepts
in
the
semantics
and
it's
true,
but
it's
not
into
knots.
A
It's
not
the
whole
story.
The
syntax
is
the
user
interface
for
the
for
the
language,
and
so,
if
the
syntax
is
you
know,
scary
for
in
whatever
that's
just
gonna
be
yet
another
adoption
blocker,
yet
another
barrier
for
people
who
could
overcome
and
I
would
say
some
of
the
syntax
we
had
especially
around
borrowing.
A
A
They
don't
differentiate
between
values
and
renders
to
values
or
pointers,
to
objects,
and
that
actually
turns
out
to
me
one
of
the
critical
problems
that
we
tried
to
solve
in
c-sharp,
but
that
is
actually
where
most
of
the
syntactic
challenges
came
from
and
it's
not
just
in
text
like
I
said
it's
really
the
model
as
well,
but
the
syntax
and
people
look
at
it
say
wow.
This
is
bizarre.
What
does
this
mean?
A
Rigor
is
not
what
people
want
when
they
are.
Prototyping
I
talked
about
this
earlier.
In
fact,
the
type
system-
it's
not
just
the
rigor.
It's
also
you
know.
Oh
I
wrote
this
very
simple
code
and
I
got
this
wonky
error
message:
I
have
no
idea
what
it
means.
The
text
system
isn't
mapping
to
my
mental
model.
This
problem
at
all.
A
What
do
I
do
well,
a
lot
of
that
you
can
solve
with
better
error
messages.
So
I
know
the
mirror
stuff
that
came
in
last
year.
I
guess
it
would
have
been
made.
The
borrow
checker
able
to
give
out
much
more
diagnoseable
error
message.
It
was
a
fantastic
thing,
but
you
know,
even
if
there's
any
places
where
the
type
system
doesn't
match
the
humans
mental
model,
it's
gonna
be
constant
friction
and
we
we
ran
into
this
all
the
time
and
it
led
to
a
feeling.
A
People
would
say:
hey,
I
feel
like
I'm,
just
fighting
the
compiler
I
just
want
to
get
this
thing,
work
nationally,
see
what
it
what
it
does
and
you
know
or
and
and
they
just
spend
all
their
time.
You
know
tracing
they're
tracking
down
every
message
in
string.
Fear,
oh!
What's
going
on
rewriting
the
code,
weird
ways
contorting
themselves,
and
so
that
that
was
a
problem.
A
I
can't
say
that
we
ever
really
cracked
that
and
even
great
IDs
and
tooling
wasn't
enough
so
I
think
the
core
problem
was,
you
know
certain
developers
just
are
accustomed
to
not
even
thinking
about
memory
management
whatsoever.
It's
like
this
completely
opaque
thing.
That
just
happens.
You
know
like
Python
or
and
c-sharp
is
in
that
category,
so
you
could
argue
hey.
We
started
with
the
wrong
language,
but
I
feel
like
if
you're
gonna
as
soon
as
you
try
to
appeal
to
a
much
broader
audience.
A
A
This
one
surprised
me
so
reliability,
security,
even
productivity,
didn't
sell
and
it's
nothing
I
didn't
so,
like
you
know,
you
would
think
that
the
chief
executive
of
a
company,
the
size
of
Microsoft
would
care
deeply
about
security,
even
that
that's
sort
of
the
business
that
they're
in
and
I'm
not
saying
they're.
They
don't
care,
but
cranking
up
features
being
more
competitive
in
the
marketplace:
etcetera,
etcetera
to
the
extent
that
security
productivity,
reliability
helps
with
that
problem.
A
Yes,
I
think
you
get
a
lot
of
support
when
you
try
to
go
into
a
large
organization,
you
know
you've
got
to
sell
the
project
right,
you
got
it
or
you
can
sort
of
go,
go,
rogue
and
and
try
to
make
it
happen,
sort
of
as
a
grassroots
thing
and
I've
seen
that
work
quite
a
bit
but
you're
trying
to
do
something
as
large
as
like:
hey,
let's
get
support
for
replacing
components
in
Windows
with
rust,
or
something
like
that.
I
thought
that
there
would
be
more
support.
You
know,
like
obviously
it's
2017.
A
We
should
be
writing
systems
code
in
a
safe
language
if
we
can,
but
that's
not
the
prevailing
opinion,
at
least
from
my
biased
experiences
and
one
of
the
challenges
we
rarely
ran
into.
Was
this
notion
of
systems
programming
when
we
were
trying
to
sell
it
to
people
they're
like
what
is
systems
programming?
It's
this
vague
term
I.
Don't
a
system
is,
but
you
go
to
Wikipedia.
It's
not
I
mean
it
a
little
bit.
It
says
systems,
programming,
games,
pretty
software
and
software
platforms,
which
provide
services
to
other
software,
our
performance
constraint
or
both
so
I.
A
Guess
that
narrows
it
down
a
little
bit,
but
especially
today,
with
lots
and
lots
of
distributed
systems
like
a
lot
of
code
falls
into
this
category
and
I
actually
think
that's
a
good
thing.
The
only
other
thing
I'd
add
is
really.
Correctness
is
paramount,
and
unfortunately
often
at
the
expense
of
productivity,
which
is
a
lengthy
topic
in
and
of
itself
and
your
mileage
might
vary,
but
for
us
systems
turned
out
to
be
a
terrible
branding
strategy.
A
It
required
constant.
You
know
reiteration
of
the
message.
People
would
say:
oh,
oh,
what
I'm
doing
application
development
so
you're
telling
me
I
can't
use
this?
No,
no!
You
you
can,
but
it's
just
not
40
like
it.
Just
set
us
up
for
a
difficult
conversation
and
it's
true
it's
great
for
systems,
but
it
was
you
know.
I
also.
A
It
makes
it
a
tougher
sell,
but
in
the
end
I
think
inertia
is
the
biggest
hurdle
of
all
I
think
you
know
the
most
critical
software
on
the
planet
has
already
been
written
by
the
definition.
Otherwise
it
wouldn't
be
mission
critical
today
and
that's
the
software.
That's
already
picked
a
language.
In
many
cases
it's
gonna
be
see
and
convincing
people
to
move
away
from
that
is
is
quite
difficult.
A
So,
that's
not
to
say
we
shouldn't
try.
So
what
is
the
future?
Well
I.
Think
all
of
us
have
sort
of
seen
a
slice
of
the
future.
I
really
do
I
think
when
I
go
talk
with
folks
like
deep
in
the
bowels
of
Windows
and
talk
to
them
about
the
problems
that
they're
struggling
with,
and
you
know,
I
think
Microsoft's
getting
better
about
seeing
outside
of
the
holes
of
that.
You
know
those
buildings
I
think
you
know.
A
If
you
go
talk
to
Linux
contributors,
they
probably
have
a
better
awareness
of
what's
available
in
the
ecosystem
compared
to
you
know,
windows,
engineers,
but
I-
think
neither
categories
really
lived
and
breathed
the
experience
of
writing
a
very
fundamental
systems
component
that
really
demands
the
highest
performance.
Reliability,
security,
you
name
it
they
haven't
lived
through
the
experience
of
actually
writing
that
code
and
rust,
or
you
know,
insert
favorite
contender
for
the
new
systems
programming
language
of
the
future
here
and
the
question
is:
how
do
we
get
them
to
see
the
value
I?
A
Think
for
me,
living
through
the
experiments
made
me
a
believer,
but
the
question
is:
how
do
you?
How
do
you
get
people
to
become
believers
when
they
haven't
actually
done
it
themselves?
I
think
one
way
is
really
lowering
the
barrier
to
entry
and
making
it
super
easy
to
experiment
and
play
around
with
this
stuff.
But
there
are
other
things
to
this:
I
borrowed
this
from
Simon,
Paton,
Jones
I
think
it's
beautiful.
It
basically
tells
the
story
of
what
happened.
Our
language
clearly
not
rust,
but
this
is.
This
is
what
you
want
to
avoid.
A
A
So
how
do
we
avoid
that?
Well,
the
good
news
is
their
systems
everywhere,
based
on
my
definition
earlier
you
know
operating
system,
kernels
device
drivers,
browsers,
distribute
systems
which
alt
all
returned
to
databases
you
can
go
on
and
on
and
all
of
these
are
systems
that
really
should
be
using
a
safe
language.
I
think
there
are
more
systems
being
built
today
than
ever
before.
I
think
the
the
trends
to
do
more
distributed
programming
means,
like
you
know,
kubernetes
is
clearly
a
system
linka,
be
it's
clearly
a
system.
A
There
are
a
lot
of
these
systems
components
and
the
nice
thing
is
people
are
writing
lots
of
new
code
here
as
well,
and
so
certainly
looking
for
areas
where
people
are
creating
new
things.
I
think
that's
a
very
good
recipe
for
for
starting
to
sort
of
take
over
the
entire
space
and
make
it
the
the
default
answer
for
people
in
that
space.
A
Unfortunately,
there
is
no
silver
bullet
I
wish
there
was,
but
I
think
it's
some
comedy
of
doing
big,
bold
new
things,
patience
and
hard
work
and
being
in
the
right
place
at
the
right
time,
and
those
three
things
over
the
long
run.
I
think
put
you
in
a
good
position.
So
this
is
a
good
example
of
big,
bold,
new
work.
A
I
think
RIT
Ops
is
a
great
shining
example
of
really
innovating
and
using
rust
to
change
the
world
in
a
in
a
big
way,
but
I
think
in
addition
to
those
things,
incrementality
is
absolutely
essential,
and
this
is
something
I
think
I
learned
from
my
experience
in
the
project.
You
know
we
did
not
foster
an
incremental
solution
and
every
step
of
the
way
that
was
one
of
the
major
things
that
prevented
people
from
betting
on
us.
A
You
know
you
want
to
make
it
easy
for
folks
to
bet
on
rust
or
whatever
component,
that
you're
building
for
a
very
targeted
solution
and
then
allow
it
to
sort
of
grow
from
there
right
this
whole
like
swallow.
The
whole
thing
at
once
value
proposition
is
a
very
tough
sell.
In
fact,
many
large
ecosystems
just
can't
be
replaced
all
at
once.
Like
imagine,
you
know
Linux
in
canoe,
okay,
you
can't
just
rewrite
the
whole
world
all
at
once.
It
has
to
be
an
incremental
path.
A
It's
certainly
easier
to
write
new
code
and
that's
one
of
the
traps
that
we
fell
into.
It's
not
only
easier.
It's
a
lot
more
fun.
You
can
just
go
right,
lots
of
code
and
do
great
things,
and
then
you
know,
especially
today,
with
such
a
vibrant
open-source
ecosystem,
that
that
approach
works
better
today
than
ever
before,
but
really
to
get
at
the
heart
of
the
issue,
and
you
know
get
some
of
these
mission
critical
systems
on
on
the
right
path.
A
And
eventually
the
disruption
comes,
but
you
can
hardly
ever
predict
when
that's
going
to
be
so
one
possibility.
This
is
just
a
thought
exercise.
You
know
if
I,
if
I
were
to
not
me
doing
my
startup,
this
is
probably
something
I'd
be
working
on,
which
is,
you
know,
take
canoe
and
Linux
ecosystem
and
start
rewriting
components,
maintaining
as
much
compatibility
as
possible.
So
take
something
like
this
and
really,
you
know,
use
a
C
ABI
as
sort
of
the
outer
shell
and
really
start
replacing
the
guts
of
these
components,
one
one
at
a
time.
A
You
do
this
over
a
long
enough
period
of
time.
Next
thing
you
know
one
of
the
most
important
pieces
of
software
on
the
planet,
Linux
becomes
safe
and
then
eventually
you
can
get
rid
of
the
C
API
and
life
is
beautiful,
I
sort
of
liking.
This
too
a
skittles
analogy,
except
it's
like
an
inside-out
skittle.
It's
not
the
exterior,
isn't
hard.
If
the
exterior
is
soft,
the
inner
core
is
hard.
I
think
also,
you
know
finding
a
wave
to
ride
or
making
a
new
one
is
also
a
super
successful
strategy.
A
I
think
it's
largely
by
accident.
I
think,
but
you
know
it's
partially
goes
heritage
as
well,
but
I
see
you
know
the
correlation
of
go+
docker
plus
kubernetes,
like
this
whole
ecosystem
of
you
know,
cloud
native
components
really
picks
go
by
default
and
largely
I
think
you
know
it's
it's
part
of
the
culture.
It's
part
of
you
know.
A
There's
this
you've
got
a
cute
logo,
but
I
actually
go
for
a
lot
of
the
stuff
at
my
new
company
and
it's
you
know,
especially
if
you're
trying
to
build
a
new
eco
open-source
eco
system,
you
want
to
sort
of
go
with
the
flow.
If
you
will
and
I
think
you
know,
doctor
and
kubernetes
really
set
the
precedent
there,
but
I
think
finding
that
sort
of
an
analogy
like
what
is
the
next
big
system
or
big
important
technology.
That's
really
gonna
take
over
the
world
and
making
sure
that's
written
in
rust.
A
I
think
that's
a
very
compelling
approach.
Now,
who
knows
right
like
the
go
team
as
far
as
I
know
no
didn't,
have
much
involvement
and
come
in
saying
you
know
Solomon,
it's
offered
to
write
everything
and
go
so
you
sort
of
have
to
be
in
the
right
place
at
the
right
timing,
there's
a
little
bit
of
luck
involved
as
well,
but
that
also
leads
me
to
this
notion
of
distributed
systems.
Where
you
know
new
pieces
are
being
written
and
swapped
in
and
out
and
really
that's
that's
an
opportunity
where
people
are
writing
new
code.
A
They
can
pick
up
new
technologies,
they're
willing
to
do
that.
There's
an
RPC
boundary,
and
so
there's
not
this
messy
disgusting
sea
and
drop
stuff
that
you
have
to
deal
with.
You
know
to
worry
about
memory
management
on
both
sides,
because
if
you
have
the
CA
bi
is
the
shell.
You
have
to
worry
about,
Oh
pointer
came
in
and
now
it's
technically
unsafe,
but
we
pretend
it's
safe
on
the
inside
and
if
somebody
screws
up
and
the
whole
system's
at
risk,
at
least
here
you
have
much
stronger
isolation,
boundaries.
A
I
think
this
is
one
of
the
things
with
Midori.
That
sort
of
made
it
work
as
well.
The
entire
system
was
sort
of
a
distributed
system.
In
a
sense,
all
processes
were
sort
of
distributed,
software,
isolated
processes
and
communicated
using
RPC
and
the
world
is
sort
of
going
this
way,
so
maybe
maybe
I'm
wrong.
Maybe
Linux
is
the
wrong
thing
to
focus
on.
Maybe
the
right
thing
to
focus
on
is
the
fact
that
you
know
there's
this
distributed
operating
system,
that's
being
created
now
out
of
heterogeneous
polyglot
components
and
maybe
being
a
key
player.
A
There
is
really
the
right
long-term
strategy
that
very
well
could
be
the
case.
So
returning
to
my
original
premise,
I
think
in
the
future,
all
systems
will
be
safe
systems.
The
question
is,
you
know
how
long
until
we
get
there
and
what's
the
path
from
here
to
there,
but
I'm
pretty
convinced
that
the
people
in
this
room
and
the
community
around
you
guys
are
in
the
best
position
to
answer
that
question
and
really
make
that
change,
and
so
for
that
I'm
super
excited
and
I
say:
let's
go
build
a
safer
future.