►
From YouTube: Rust and Tell Berlin - July
Description
“Rust and Tell“ is a monthly event to share ideas, and learn about new things in and about Rust. Meet fellow Rustaceans, share your learnings, get motivated and inspired.
https://berline.rs/2020/07/28/rust-and-tell.html
#1: 00:06:09 Implementing Fast Route Planning Algorithms in Rust by Payas Rajan
#2: 00:23:24 Rust'N'Games by Stephan Dilly
#3: 00:54:30 To the 90s and Back: Adventures in Rust COM Programming by Ryan Levick
#4: 01:24:20 zbus Announcement by Zeeshan
A
If
you
have
your
video
on,
give
me
a
thumbs
up
or
a
thumbs
down,
if
you
don't
want
to
go,
alright
good
cool,
so
welcome
everybody
to
another
edition
of
rest
and
tell
we're
very
happy
to
to
have
you
here,
welcome
to
all
those
who
have
been
at
a
rest
intel
before,
either
in
person
or
online,
and
welcome
to
everybody
who
is
new
and
might
be
joining
us
from
berlin
or
beyond
other
places
in
this
beautiful
world
a
little
bit
about
the
organizers,
I'm
ryan
levick,
and
you
can
find
me
on
twitter
at
ryan,
underscore
lubbock
and
I'll,
introduce
myself
a
little
bit
later.
A
So,
a
little
bit
about
the
concept
of
the
meetup
rest
intel
is
for
beginners
to
experts
to
share
your
struggles,
ideas,
hacks
projects,
anything
and
everything,
whether
you're
an
advanced
user
of
rust
or
just
beginning
with
a
language.
It
doesn't
matter
whether
you've
been
programming
for
30,
40
50
years
or
just
learned
how
to
program.
Yesterday,
we
would
love
to
hear
your
story.
This
is
really
a
space
for
the
community
to
learn
and
grow
together
and
we
are
willing
to
take
any
and
every
talk
and
happy
to
help.
B
And
we
also
followed
a
berlin
code
of
contact,
which
is
now
the
world
code
of
contact.
If
you
join
from
from
emma
somewhere
else,
then
berlin,
it's
basically
just
to
treat
the
people
here
nicely
and
with
respect
and
treat
yourself
with
with
respect,
and
if
you
encounter
someone
which
is
harassing
you
or
is
making
mean
comments
or
something
else,
please
feel
free
to
get
in
touch
with
us.
We
take
those
things
very
very
seriously.
B
Since
we
are
online
now
we
have
a
different
emma
setup
than
in
person.
So
we
are,
am
I
using
zoom
and
assume
chat
so
emma
during
the
talks,
you
have
the
chance
to
ask
any
question
and
you
can
just
them
type
them
into
the
zoom
chat.
B
We
also
have
a
have
a
matrix
chat
or
what
is
called
now
element
chat
and
after
the
second
talk,
we
will
go
into
the
zoom
breakout
rooms,
which
means
we
will
have
three
or
four
rooms
where
you
can
join
and
turn
off
your
camera,
or
you
can
just
chat
with
the
other
people
about
anything
you
want,
and
I
mean
you
will
get
a
notification
after
the
second
talk.
B
A
B
A
We're
not
streaming
live
on
youtube
or
streaming
it.
On
another
platform,
we
can
paste
the
link
to
that
okay
to
the
zoom
as
well,
but
the
recording
will
be
live
on
youtube
and
for
those
of
you
in
the
future,
watching
this
on
youtube.
B
Hello,
hey
and
yeah,
and
feel
free
to
type
any
question
you
have
in
the
chat
rooms.
A
So,
just
going
back
to
what
this
meetup
is
about,
we
really
want
you
to
come
and
give
a
talk.
We
are
always
open
to
helping
you
with
your
talk.
So
please
please,
please,
even
if
you
do
not
have
a
fully
formed
idea
of
what
you
want
to
talk
about,
feel
free
to
get
in
contact
with
us
through
meetup
or
on
twitter
linkedin.
A
Wherever
you
happen
to
find
either
of
us,
we
are
happy
to
work
with
you
and
we
would
love
to
hear
from
you
and
yes,
we
really
do
mean
you
and
also
a
thank
you
to
jan
eric
for
helping
us
once
again
with
the
setup.
As
always,
he
has
been
very
kind
and
patient
with
us
as
helping
us
with
all
the
technologies
of
streaming
that
we
have
still
not
gotten
a
handle
on.
So
thank
you,
yanav
for
your
for
your
help
there.
We
really
appreciate
it.
B
And
the
talks
for
today
the
first
talk
will
be
from
from
pious
who
joins
us
from
california,
and
he
will
talk
about
implementing
fast
route
planning,
algorithms
and
the
second
talk
will
be
from
stefan.
He
joins
us
from
hamburg
and
he
will
talk
about
games
and
rust,
rust
and
games,
and
then
the
last
talk
will
be
from
ryan
himself.
B
A
Yeah,
we'll
see
trust
me.
It's
going
to
be
fun.
I
can
see
people
running
for
the
hills.
Now.
No,
it's
going
to
be
fun.
We're
going
to
get
into
some
fun
stuff,
all
right.
So
with
that
we
are
done
with
the
introduction
and
then
we're
going
to
hand
it
off
to
pious
for
the
first.
A
C
Okay,
hello
good
evening,
thank
you
so
much
for
coming.
I
hope,
you're
able
to
see
my
screen.
Is
it
visible.
A
C
Okay:
okay,
let's
start
so.
C
And
thank
you
so
much
for
coming
in
2015
nick
cameron,
a
research
engineer
at
mozilla
working
on
the
rust
compiler.
This
blog
called
featherweight
musings,
wrote
a
blog
post
that
started
with
this
sentence.
Graphs
are
a
bit
awkward
to
construct
and
rust
because
of
rus
stringent
lifetime
and
mutability
requirements
and
internet
being
internet.
In
responses
to
in
response
to
nick's
blog
an.
C
After
next
post,
there
were
several
similar
posts
about
graphs
and
rust,
probably
the
most
notable
of
them
being
written
by
nico
matsakis,
called
modeling
graphs
and
rust,
using
vector
indices
and
all
of
these
posts
tries
to
answer
the
same
question.
What
is
the
correct
representation
of
a
graph
without
violating
the
rust
body
checking
rules?
C
Now
this
was
five
years
ago.
Where
do
we
stand
today?
The
most
popular
creed
providing
the
graph
data
structure
appears
to
be
one
called
pet
graph,
which
is
downloaded
about
9000
times
every
day,
but
does
having
one
excellent
general
purpose.
Graph
trade
supplies
for
all
use
cases
very
likely.
Not
let
me
introduce
to
one
such
problem,
but
we'll
have
to
start
from
the
first
principles
for
that.
So,
let's
look
at
what
a
graph
is,
so
a
graph
is
composed
of
nodes,
edges
and
edge
weights.
C
For
the
purposes
of
this
talk,
we
shall
consider
that
only
simple
graphs,
so
self
loops
and
parallel
edges
are
not
allowed
and
we
shall
assume
that
edge
weights
are
always
positive
integers.
So
we
shall
relax
this
assumption
later
now.
The
problem
we
are
trying
to
solve
is
to
find
the
shortest
path
from
a
source
with
a
vertex
s,
to
a
target.
Vertex
t.
D
C
The
graph-
and
that
looks
simple
right.
Well,
it's
not
so
simple.
C
C
D
C
With
graphs
and
no
that.
C
Typo
in
the
title,
it
is
the
archive
word
of
this
word
connection.
I'm
glad
that
computer
science
has
reached
a
milestone
where
we
can
find
papers
with
archive
words
in
the
titles.
C
C
C
And
we
update
the
green
labels
on
the
nodes
adjacent
to
the
new
frontier
if
needed,
so,
for
example,
in
this,
in
the
example
we
took,
we
have
updated
the
label
for
this
vertex
because
we
found
a
new
shortest
path
from
s
to
this
vertex.
We
are
the
vertical
on
the.
A
C
D
C
C
Find
the
target
t
the
complexity
of
this
algorithm
from
the
original
paper
is
order
of
v
square,
but
better
algorithms
have
are
known
now
and
if
we
use
fibonacci.
C
Known
complexity
of
this
algorithm
comes
to
be
ordered
off
v
log
v
plus
e.
Now
we
can
do
slightly
better
than
this
for
an
intuition.
Let's
say
what
happens
if
you
start
frontiers
developing
frontiers
from
both
the
source
and
the
target,
so
you
develop
a
frontier
from
the
source
that
goes
in
the
forward
direction
and
another
one
from
the
target
in
the
reverse
direction,
and
wherever
the
both
the
frontiers
overlap,
we
can
find
at
the
shortest
path
using
the
overlap
in
the
frontiers.
C
C
Right
so,
since
the
queries
are
randomized,
we
will
see
some
minor
variations
in
the
time
it
takes
for
query,
but
we
can
see
that
it
takes
approximately
10
to
15
milliseconds
per
query
right
and
for
every
query.
We
are
settling
approximately
hundred
thousand
nodes,
and
this
is
not
good.
We
can
do
something
better
than
this.
C
So
let's
talk
about
contraction
hierarchies,
which
is
what
this
talk
is
all
about,
so
in
2006
the
center
for
discrete
mathematics
and
theoretical
computer
science
at
rutgers
to
cut
the
shortest
path
problem.
As
a
challenge,
research
groups
were
asked
for
seven
papers
and
out
of
it
came
a
whole
host
of
speed
up
techniques
that
could
be
used
to
make
the
shortest
path
computation
faster.
C
C
Routing
now,
under
this
model
becomes
like
driving
to
travel
long
distances.
You
want
to
hop
on
the
highway
as
soon
as
possible
and
keep
driving
on
the
highway
only
descending
to
the
local
roads
when
you
reach
close
to
your
destination-
and
this
is
exactly
how
our
search
works
and
if
you
have
ever
wondered
why
google
maps
takes
you
to
highways
even
for
short
distances.
This
is
exactly
the
reason
for
it.
C
C
Then
we
order
the
vertices
in
order
of
increasing
order
of
their
importance
that
we
just
assigned.
And
finally
all
of
this
leads
us
to
the
applying
the
operation
that
gives
ch
its
power
shortcuts,
for
example,
for
the
vertex
v.
If
u
to
v
to
w,
is
the
shortest
path
from
u
to
w,
then
we
can
add
the
shots,
and
then
we
can
add
a
shortcut.
U
to
w.
C
C
This
gives
us
a
nice
speed
up
in
the
time
for
the
dijkstras
algorithm,
so
in
the
running
example
that
we
have
taken
so
far.
If
I
contract
the,
if
the
numbers
in
red
are
the
importance
of
the
vertices
and
if
we,
if
we
apply
the
contraction
operation
to.
C
An
index,
but
it's
like
adding
more
information
to
the
graph
that
can
supplemental
information
to
the
graph
that
can
help.
A
C
Searches
run
faster,
but
we
cannot
run
regular,
bi-directional
textures
for
the
query
algorithm.
We
need
to
restrict
our
algorithm
to
run
only
in
directions,
so
the
forward
search
goes
only
from
vertices
that
are
have
low
importance
to
vertices
that
have
high
importance
and
the
backward
search
goes
from
vertices
that
have
high
importance
to
those
that
have
lower
importance
right.
So
in
the
example
that
we
took
the
forward
search
goes
from
one
to
all.
C
The
nodes
where
the
neighboring
nodes
are
bigger
than
one
are
bigger
than
the
neighbor
are
bigger
than
the
neighbors
and
the
backward
switch
goes
from
13
to
4,
because
13
is
the
largest
vertex.
13
is
the
largest
in
terms
of
its
importance,
and
then
the
search
goes
from
13
to
all
the
vertices
that
it
can
reach
where
the
importance
is
lower
than
the
neighboring.
D
C
These
libraries
are
designed
to
solve
a
broad
set
of
problems
for
most
people
and
implementing
such
specialized
algorithms
is
clearly
beyond
their
scope,
but
there's
something
that
we
can
learn
from
them,
which
is
how
to
represent
a
graph
edges,
how
to
represent
vertices
and
how
to
represent
edge
weights
and
how
to
represent
the
operations
that
are
allowed
on
the
edges
and
the
edge
weights
of
the
graph
right.
So,
for
example,
let's
look
at
c
plus
plus.
C
C
Let's
look
at
boost
graph
library
right
and
as
soon
as
you
start
looking
through
the
boost
graph
code,
the
first
thing
that
strikes
you
is
that
the
library
is
chock
full
of
trades
for
everything
from
deciding
whether
the
graph
is
stored
as
an
additional
list
or
an
adjacency
matrix
to
deciding
whether
edges
are
directed
or
undirected.
Everything
is
handled
using
traits
and
even
more
important
than
that.
C
The
operations
allowed
on
different
types
of
nodes,
edges,
edge
weights
are
decided
using
traits
and
traits
are
not
a
first
class
citizen
in
c
plus
plus,
which
makes
these
implementations
probably
easy
to
use
when
you're
using
something
like
boost
but
really
difficult
to
do
it
yourself,
and
this
is
where
rust
steps
in
now
traits
are
a
first
class
citizen
and
trust.
So.
C
That
rust
makes
it
incredibly
easy
to
implement
generic
graphs
deal
structures.
For
example,
we
have
here,
I
implemented.
A
C
C
C
This
way,
what
we
have
constrained
our
type
edge
weight.
We
have
constrained
our
edge
way
to
always
be
of
type
that
implements
the
operator
plus
doing
this
in
c,
plus
plus,
is
neither
fun
and
not
easy.
I
mean
this
would
require
something
like
a
boost,
the
boost
conception,
library,
but
that
is
an
additional
dependency
that
needs
to
be
pulled
in
and
maintained
over
time,
which
is
again
not
a
very
pleasant
experience.
C
So
I
have
been
working
on
this
for
some
time
now
for
about
a
year
and
the
results
that
I've
been
getting
are
pretty
good
and,
let's
see-
and
of
course,
since
it's
dressed,
the
performance
is
also
pretty
good.
It's
only.
C
At
how
good
the
performance
is,
this
is
again
running
100
queries
on
the
same
graph
that
we
looked
at
last
time,
but
you
can
easily
see
that
the
runtime
has
come
down
for
every
query
from
14
milliseconds
to
17
microseconds,
and
the
reason
for
this
is
because
we
can.
We
have
drastically
reduced
the
search
space,
the
average
source
space
for
the
dijkstra's
queries
that
are
running
on
the
graph
right.
We
can
try
running
it
a
couple
of
more
times
just
to
be
sure
that
these
randomized
queries
were
not
a
good
case
for
us.
C
C
C
The
performance
is
good
if
you
are
familiar
with
get
familiar
with
rates
and
if
you
think
it
makes
it
really
easy
to
implement
the
same
algorithm
and
then
use
it
again
and
again
for
different
types
of
edge,
reads
and
edges
and
all.
C
C
A
C
In
production,
then,
maybe.
A
E
Okay,
so
I
think
it's
already
two
months
since
my
last
rust
intel
presentation
and
this
this
time
it
will
be
quite
different
because
I'm
actually
talking
about
my
my
day-to-day
business,
which
is
in
games,
actually
I've
developed
games
for
the
last
13
years
and
over
the
last
one
and
a
half
years,
roughly
it's
more
and
more
happening
is
in
in
rust
as
well.
E
So
when
I
was
asked
to
to
quickly
maybe
talk
about
this
topic,
I
I
gladly
accept
it
because,
of
course,
this
is
something
that's
that's
dear
to
my
heart
and
not
let
not
that
the
talk
from
last
time
wasn't
as
well,
but
the
kind
of
graphics
fidelity
that
we
had
had
last
time
in
my
little
gui
tui
application.
E
What
is
maybe
lacking
when
we
are
talking
about
modern
games.
So
today
we
are
talking
about
games
that
we
are
building
as
a
company
and
the
first
one
of
these
is
actually
called
stack,
four,
which
we
started
working
on
beginning
of
last
year
and
you
can
get
a
quick
glimpse.
E
E
So
yeah
stack
4
is
a
3d
game
of
connect
4
and
it's
out
for
mobile
in
canada
right
now
in
a
so-called
silent
launch,
so
basically
trying
to
iron
out
the
last
couple
of
bucks
and
seeing
how
people
react
to
it,
and
it's
on
it
runs
on
the
platforms
of
ios
and
android,
and
the
reason
why
I
picked
rust
in
this
particular
case
was
that
I
wanted
to
have
a
authoritative
server
implementation
that
was
supposed
to
implement
the
actual
game.
Logic
of
connect.
E
Four
and
I
didn't
want
to
duplicate
basically
code
between
front
end
and
back
end.
So
the
engine
that
I'm
using
in
this
particular
project
is
unity
and,
I
think,
replicating
the
kind
of
complexity
that
this
sort
of
mature
engine
gives
us
was
definitely
out
of
scope
for
this
project.
E
So
we
stuck
to
to
what
we
were
used
to,
which
is
using
such
engines,
and
I
still
wanted
to
use
the
opportunity
to
to
benefit
from
from
rust's
features
in
a
sense
that
I
was
really
focused
on
performance
when
it
came
to
the
ai
implementation.
And
maybe
you
can
look
at
the
actual
tech
that
I'm
that
that
is
used
in
here.
E
So
there
is
a
core
library
that
implements
the
game
logic
in
rust
and
that
is
used
between
shared
between
front
end
and
back
end,
and
I
mean
the
the
the
major
reason
for
that,
for
this
was
to
have
a
fast
ai
implementation,
because
that
is
actually
something
that
I
knew
from
the
past
would
be,
could
be
a
potential
bottleneck,
doing
it
in
a
in
a
managed
language
like
c-sharp,
which
is
the
main
language
you
are
using
when
you
are
writing
your
game
in
unity,
so
yeah
and
the
and
the
additional
plus
side
for
me
was
that
I
wanted
to
be
able
to
check
those
calculations
on
the
back
end
and
validate
that.
E
No
one
is
cheating,
so
it
was
kind
of
straightforward
to
look
for
a
technology
that
would
be
able
to
run
on
both
sides,
and
you
can
see
already.
This
is
also
using
go
in
the
back
end,
and
that
is
because,
back
in
2008
and
beginning
of
2019,
when
we
started
with
this,
the
whole
async
await
and
and
back-end
framework
landscape.
E
For
me
was
still
looking
to
unstable,
let's
say
for
me
to
to
really
make
the
call
to
go
full
on
rust,
so
there's
sort
of
a
step
in
between
that
we
did
for
stack
four,
which
is
that
we
are
using
actually
go
as
the
server
implementation
framework,
and
this
is
also
using
the
same
c
based
rust
library
that
the
front
end
is
also
using
so
sort
of
a
hackish
kind
of
thing.
E
But
it
worked
really
well
for
us,
because
the
really
performance,
critical
code,
that
needed
to
be
as
fast
as
possible
was
still
written
in
rust
and
benefited
from
all
those
benefits
that
we
got
from
from
this
full
control
over
the
memory
management,
for
example-
and
we
will
see
a
little
bit
more
about
that
later
as
well.
E
This
is
a
tower
defense
based
mechanic,
so
you
can
see
towers
that
are
shooting
kind
of
entities,
and
this
was
a
step
into
into
a
much
more
complex
direction
with
this
project.
So
it's
much
more.
E
Interesting,
I
hope
I
didn't
destroy
any
ears
here.
It
definitely
was
very
loud
on
my
machine,
as
you
can
see
in
this
in
this
short
video.
It's
it's
much
more
interactive,
there's
much
more
going
on
there's
much
more
real
time
involved,
and
so
it
was
a
much
more
interesting
use
case
for
us
and
yeah.
It's
pretty
much.
E
The
same
kind
of
approach
that
I
started
out
with
here,
as
in
stack
4,
was
to
first
figure
out
a
core
game
logic
that
was
written
in
rust
anyway,
but
then
I
also
took
the
next
step
and
kind
of
decided.
Okay,
let's
get
rid
of
this
whole
go
thing.
We
are
talking
about
middle
of
or
end
of
last
year,
so
for
me
it
was
definitely
interesting
to
to
start
using
one
of
those
async
frameworks
in
rust
and
and
give
this
whole
back
end
a
complete
rust
kind
of
foundation.
E
So
this
is
what
we,
what
we
did
here
and
the
project
is
still
in
prototype
phase.
So
it's
not
something
you
can
play
out
out
there,
but
it's
something
we
are
very
interested
in
in
proceeding
with
since
the
whole
technology
behind.
It
is
super
interesting
for
us
and
the
kind
of
game
mechanic
is
super
promising,
because
we
are
kind
of.
E
I
don't
want
to
go
too
deeply
into
the
game
design
kind
of
considerations
here,
but
for
us
this
was
a
very
interesting
combination
of
two
genres
and
something
that
we
didn't
see
a
lot
out
there
in
the
wild.
E
But
when
it
comes
to
the
actual
technology
was,
was
some
some
things
that
we
that
we
stepped
up
from
from
the
last
project.
In
this
one,
and
in
particular
I
wanted
to
highlight
two
of
them,
which
is
I
mean
first
of
all,
I
mentioned
it
already.
There
is
no
go
involved
in
this
project
anymore,
so
the
whole
back
end
is
completely
written
in
rust,
but
there
is
a
clear
separation
between
the
game
logic
and
the
whole
back-end
api
implementation,
because
the
game
logic
again
is
also
shared
with
the
front
end.
E
So
the
the
the
complexity
of
this
kind
kind
of
game
makes
it
requires
us
to
do
a
lot
of
extrapolations
on
the
front-end
side
to
be
able
to
know
what
happens
in
the
next
couple
of
seconds
in
the
game
play
without
always
synchronizing
tons
of
entities
between
front-end
and
back-end,
and
so
we
kind
of
took
this
approach
to
have
a
deterministic
logic,
implementation
that
is
run
on
both
sides,
basically
on
the
front
end
and
the
back
end,
and
we
kind
of
only
synchronize
between
those
two,
the
input,
events
that
are
happening.
E
This
is
kind
of
a
standard
approach
in
gaming,
but
it's
it's
something
that
made
it
super
easy
for
us
to
reuse
again.
This
kind
of
logic
library
on
both
sides,
but
something
that
that
we
did
differently
here
I
wanted
to
highlight-
is
using
flat
buffers
for
one.
So,
in
contrast
in
the
stack
four
project
that
I
showed
you
before,
we
actually
communicated
between
the
the
core
library
and
the
the
game
or
or
go
using
json
objects.
E
That
was
all
fine
for
for
this
particular
use
case,
because
it
wasn't
that
much
data
that
needed
to
go
back
and
forth
and
there's
also
much
less
input.
Events
that
you
actually
need
to
need
to
synchronize,
but
because
of
the
fact
that,
in
this
game,
as
you
can
see,
we
have
many
more
entities
going
on
and
basically
you
you
have
to
be
able
to
synchronize
with
with
up
to
a
thousand
entities
that
could
be
simultaneously
on
screen.
E
And
so
what
we
are
using
here
is
a
is
a
library
called
flat
buffers,
there's
an
actual.
Actually,
a
pretty
nice
talk
from
a
meetup
in
san
francisco.
I
think
about
it.
E
There's
a
rust
implementation
for
it,
and
what
it
essentially
does
is
that
it
allows
you
to
serialize
data
by
mapping,
basically
by
mapping
directly
into
into
the
memory
from
different
languages
and
to
be
able
to
interpret
this
memory
from
different
languages
in
the
same
way.
So
you
don't
have
to
have
you
don't
have
this
whole
overhead
that
you
are
using
when
you're
that
you're
having
when
you're
using
json,
for
example,
and
that
gave
us
a
nice
boost
in
in
performance
there?
E
Secondly,
entity
component
systems
is
a
super
big
buzzword
in
in
the
rust
community,
and
that
is,
I
think
that
has
two
reasons.
First
of
all,
rust
makes
it
super
hard
to
design
your
whole
entity
relationships
differently.
So
ecs
is
something
that
is
pretty
straightforward
and
there's
also
a
couple
of
nice
meetup
talks
about
ecs
in
general.
I'm
not
going
to
go
too
deeply
on
those,
but
the
the
whole
idea
is
that
you
are
instead
of
referencing
directly
between
multiple
entities.
E
You
have
them
all
in
contiguous
arrays,
essentially,
so
it
makes
it
super
easy
and
fast
to
iterate
over
them,
which
is
one
of
the
predominant
access
patterns
that
we
see
in
this
in
this
sort
of
game.
That
tower
rangers
is,
and
it
also
it
allows
us
to
to
also
from
from
another
perspective,
to
architect
the
whole
game
in
a
in
a
nice
way
where
you
can
add
behavior
to
entities
by
basically
just
adding
components
to
them.
E
Instead
of
having
this
this
weird
class
hierarchies
that
I'm
that
I
remember
from
back
in
the
past
in
c
plus
plus
so
back
in
end
of
last
year,
what
kind
of
back-end
technology
did
we
use
for
the
actual
web
api?
That
was
a
rocket,
and
that
is
something
that
I
wasn't
too
happy
with
at
the
time
because
it
made
me
it
forced
me
into
using
instable,
rust
or
nightly
rust,
and
that's
something
I
really
didn't
feel
good
about,
because
there
were
multiple
times
that
it
broke.
E
My
build
pipeline
when
suddenly
some
nightly
releases
didn't
support
the
the
version,
some
sort,
some
version
of
some
some
of
my
tools
anymore.
So
that
was
definitely
something
I
I
really
didn't
like
so
much
and
also
the
fact
that
back
in
that
back
in
that
time
I
mean
the
stable
thing-
also
changed,
I
think
pretty
recently,
but
back
in
the
in
last
year.
That
wasn't
the
case
and
also
the
the
fact
that
it
didn't
support
asic,
which
was
something
that
I
really
was
interested
in.
E
Having
like
to
to
really
save
and
and
scale
easier
with
my
back-end
implementation
on
a
very
cheap
kind
of
server
infrastructure,
because
for
us
as
a
super
small
company,
it
was
essential
to
really
not
waste
any
money
anywhere
possible
and
yeah.
But
we
will
see
that
in
our
current
project
we
are
actually
using
a
different
kind
of
solution
that
I'm
currently
much
more
happy
with.
E
So
yeah
the
idea
here
is
it's
a
racing
game.
It's
super
simple
and
casual,
and
but
it's
still
interesting
from
a
technology
perspective
because
you're
competing
against
99
opponents
at
the
same
time,
so
you're
racing
against
other
actual
players
out
there,
whoops,
not
what
I
wanted
and
the
this
is
called
in
in
our
game
world.
There's
a
term
called
royale
mechanic
for
that,
because
there's
a
couple
of
games
that
that
does
that
do
something
similar
where
you're
competing
against
99
opponents
until
basically
one
is
left
and
then
wins
the
game
again.
E
This
game
is
currently
live
in
canada
in
a
test
environment
and
yeah,
and
we
have.
We
are
using
a
similar
tech
stack
to
what
what
I
showed
you
before,
but
this
time
it's
a
it's
a
game
that
is,
that
was
too
simple,
actually
to
also
have
a
client
side.
So
this
is
for
purely
back-end
rust
implementation
and
the
the
the
back
end
sort
of
acts
as
a
entry
point
to
the
database
when,
if
you
will
so,
we
have
a
pure
rest
based
api,
we
are
saving
all
the
data
in
dynamodb
databases.
E
So
there's
a
there's,
a
very
nice
crate
that
gives
you
access
to
all
those
aws
services
and
for
us,
a
very
scalable
solution
was
using
this
dynamodb
and
there
is
actually
async
wrappers
for
that.
So
that
is
all
all
no
problem.
Same
same
goes
for
redis,
actually
that
we
are
that
we
have
to
use
as
a
caching
layer
in
between,
because
there's
a
couple
of
access
patterns
that
are
that
are
super
expensive
to
to
always
hit
the
actual
database.
E
And
it's
a
it's
a
very
straightforward
approach
to
use
radius
in
between.
For
that
and
again,
there's
a
nice
crate
for
that
out
there.
It's
it's.
It's
all
async,
no
problem
to
integrate
into
a
tokyo
based
runtime,
which
is
the
one
that
I'm
going
for
in
our
current
system.
So
I
have
no
experience.
E
I
cannot
say
much
about
how
the
alternatives
look
like,
even
though
I
actually
aren't.
I
actually
am
tempted
to
look
into
them,
because
tokyo
actually
pulls
in
a
lot
of
dependencies
and
a
lot
of
bloat
right
away.
But
that
is
something
I
guess
a
a
battle
for
another
day.
But
what
I'm
really
happy
with
in
this
back-end
implementation
is
using
warp.
E
That
is
something
that
I
didn't
have
on
the
radar
at
least
last
year
when
I
chose
rocket
so
warp
basically
provides
you
an
async
implementation
for
for
web
servers
and
for
me,
the
the
kind
of
ergonomics
in
how
you
are
building
up
your
endpoints
and
services,
and
how
this
whole
thing
is.
Super
modular
was
kind
of
intriguing
to
me
and
right
now.
I
really
am
happy
with
this
solution
using
warp
and
I'm
definitely
going
to
go
forward
with
that.
E
Even
though
I
I
must
admit
that
those
benchmarks
that
you
can
see
on
what's
what's
this
site
called
anyways,
so
it's
it's,
definitely
not
not
the
fastest
in
those
in
those
benchmarks,
but
you
always
also
have
to
take
those
benchmarks
with
a
grain
of
salt
right
and
for
me
it
was
always
more
beneficial
to
go
with
something.
That
is
that
that
is
maintain
more
maintainable
and
easier
for
me
to
grasp-
and
maybe
it's
a
little
less
fast,
but
I'm
building
usually
building
stateless
back-end
apis
anyway.
E
E
So
the
idea
is
always
to
to
give
you
a
really
good
feeling
of
of
a
community
in
the
games,
and
you
you
want
to
know
where
those
people
are
coming
from,
that
you
are
competing
against,
and
so
it's
a
it's
a
best
practice
sort
of
also
in
the
in
the
industry
to
assign
everyone
the
flag,
that
of
their
country,
where
they're
coming
from
so
that
you
have
a
feeling
of
this
international
kind
of
challenge
and
competition
that
you're
engaging
with
and
for
for
the
longest
time
I
was
using
actually
a
go
implementation
and
I
actually
used
it
in
the
in
the
rust
based
back
ends
as
well.
E
I
just
basically
ran
it
in
a
docker
container
as
a
microservice,
and
all
that
it
gave
me
was
a
ip
lookup
to
a
country,
and
I
always
felt
bad
about
it
because
it
was
first.
I
mean
it
was
not
super
fast.
It
was.
It
took
a
lot
of
memory,
so
I
actually
paid
more
money
than
I
had
to
to
to
run
this,
for
example,
in
the
in
the
aws
container.
E
It
didn't
give
me
ap
ip
v4
and
6
at
the
same
time,
and
it
also
had
a
shady
sort
of
license
where
they
always
tried
to
sell
you
up
into
some
sort
of
priced
tier
where
you
had
to
where
you
could
get
more
accurate
kind
of
results,
and
that
is
something
that
I
really
had
on
my
list
for
a
long
time
to
look
into
so
in
my
last
project,
I
actually
found
a
solution
on
on
crates
io.
E
That
does
this
whole
thing
in
rust,
but
for
my
so
to
my
surprise,
it
was
way
worse
than
what
I,
that
than
the
solution
that
I
had
used
in
written
go.
E
So
I
looked
into
it
and
it
turned
out
to
be
basically,
the
problem
was
that
it
was
always
keeping
this
super
unoptimized
sort
of
data
structure
in
memory
for
the
whole
database
for
the
whole
ip
database
to
look
up
into,
and
so
I
decided-
okay,
let's,
let's
finally
do
this
myself
and
implement
it
in
in
the
right
way,
and
I
still
want
to
write
a
blog
post
about
that
because
it's
it's
it's
now
so
much
more
performant
and
I'm
really
happy
with
the
result.
It
supports
ipv4
and
six.
E
At
the
same
time,
it
uses
a
completely
free
and
reality
free
kind
of
database
that
that
is,
that
is
provided
by
all
the
different
isps
out
there,
where
you
can
get
the
ip
ranges
and
the
the
who
is
lookups
behind
that
and
the
country
as
well.
So
in
the
end,
I'm
throwing
out
all
the
crap
that
I
don't
need
and
basically
just
reduce
it
for
ip
range
to
country
lookup,
and
that
is
what
you
can
now
find,
also
on
crates
and
and
github
and
yeah.
E
It's
also
using
warp,
and
it's
super
fast,
even
though
every
the
whole
database
is
in
memory.
As
well,
but
that
is
something
that
really
again
emphasized
for
me
how
easy
it
is
to
write,
really
performance
systems
in
rust,
where
you
don't
have
to
jump
through
a
ton
of
hoops
to
make
this
possible.
Yes,
the
learning
curve
was
was
kind
of
intense
for
me
as
well,
but
that's
something
that,
after
a
year,
I
must
say,
really
paid
out
paid
off
quite
well.
E
So
a
couple
of
highlights
why
we
are
happy
with
our
decision
to
go
for
rust.
I
mean
obviously
the
sea
interoperability
for
us
was
one
of
the
major
factors
right.
We
couldn't
be
using
rust
in
an
engine
like
unity
if
there
wasn't
this
sort
of
opportunity
to
go
through
a
c
api.
E
So
that
is
something
that
that
really
was
important
and
actually,
in
the
end,
the
fact
that
there
is
no
real
run
time
and
that
it's
super
lightweight
allows
us
to
to
use
this
in
in
every
sort
of
place,
and
that
is
the
sort
of
portability
that
that
I
was,
for
example,
that
I
didn't
get.
E
For
example,
when
I
looked
for
for
a
short
period
of
time
to
do
the
same,
with
go
actually
back
in
the
days,
yeah
of
course,
implementing
a
complicated
ai
like
we
did
in
stack
four
that
goes
through
a
search
tree
in
into
the
I
don't
know,
20th
level
or
something
to
really
be
able
to
at
least
do
super.
E
Intelligent
moves
was
something
that
was
super
hard
to
implement
in
a
in
a
like
a
language
with
memory,
with
a
with
an
automatic
memory,
management
and
garbage
collection,
because
you
had
to
keep
in
mind
so
much
stuff.
You
had
to
to
to
do
so
much
things
to
to
make
sure
that
you're
not
allocating
in
places
where
you
can
maybe
forget
about
that.
E
It's
happening
there,
and
that
is
something
that
rust
really
makes
easy
for
you
to
not
run
into,
because
I
mean
it's
basically
the
opposite
kind
of
approach
right,
where
it
shouts
into
your
face
whenever
you
do
you're
doing
something
that
that
you
didn't
want
to
do
and
yeah
this.
The
ergonomics
and
safeties
is
something
that's
emphasized
in
a
lot
of
discussions
about
rust.
But
for
me
it
really
there's.
E
There's
one
example
that
I
keep
telling
people
and
it's
it's
funny
because
it
kind
of
came
through
in
in
the
previous
talk
as
well,
which
is
ergonomic
for
me
to
to
be
able
to
still
get
benefits
that
other
languages
give
you
by
doing
like
dynamic
dispatch
and
and
russ
basically
makes
it
easy
for
you
to
have
this
in
a
compile
time
level
where
you
are
when
you
are
looking
at
those
graph
traits
that
we
saw
in
the
previous
talk.
That
is.
E
That
is
a
prime
example
for
me
to
have
flexibility
like
you're
used
to
in
other
languages,
but
have
it
at
runtime
with
high
performance
and
yeah.
I
still
want
to
also
I
keep
emphasizing,
I
think
also
my
last
stop
cargo
and
the
whole
community.
But
it's
still
for
me.
E
One
of
the
reasons
why
I
keep,
I
guess
not
losing
faith
when
I'm
when
I'm
running
against
the
wall
for
the
100th
time
in
a
rust
problem,
because
then
I
realized
okay,
there's
other
solutions
out
there
that
I
that
I
can
get
my
inspiration
from
and
and
there's
a
super
helpful
community.
Even
when
you
reach
out
to
those
authors
and.
E
And
you,
you
always
get
help,
and
that
is
something
where
which
I
also
learned.
It
could
be
much
different
in
in
other
communities
or
other
language
communities,
and
I
know
it's
it's
sort
of
something
people
do
is
like
highlighting
some
of
the
crates
they
really
like,
and
I
did
a
little.
E
I
picked
out
a
selection
a
little
differently
this
time,
because
I
think
these
are
my
prime
examples
of
underappreciated
crates,
and
one
of
them
actually
could
also
be
interesting
for
to
the
to
my
the
previous
speaker,
because
it's
actually
an
implementation
of
dijkstra
and
also
a
ton
of
other
graph
search
algorithms,
and
it's
it's
one
that
I
picked
because
it
has.
It
just
has
like
260
stars,
but
it's
it's
the
core
library
for
for
every
game,
basically
on
our
site.
E
That
has
any
sort
of
ai
implementation,
because
it's
a
it's
a
super,
flexible
and
still
very
performant
graph
search
implementation,
which
is
which
is
an
essential
problem
in
game
development
and
yeah.
We
are
we,
I
emphasize
the
entity
component
system
aspect
of
our
games,
and
that
is
something
we
are
using
hex4.
E
It's
not
the
most
popular
choice
out
there,
and
I
think
this
is
also
a
reason
why
I
want
to
emphasize
it,
because
it
has
a
much
more
easy
to
grasp
api.
I
think
in
in
my
understanding
it's
much
more
flexible.
It
doesn't
put
too
many
like
constraints
on
you
like.
If
I
look
at
specs,
for
example,
as
an
alternative,
that's
definitely
something
that
makes
you
forces
you
to
style.
Your
your
implementation
in
a
certain
way
and
hex
gives
you
much
more
freedom
here
to
choose
how
you
want
to
implement
stuff
cargo
lipo.
E
I
actually
won't
open
this
link
this
time
super
important.
If
you
want
to
do
cross-platform,
especially
mobile
libraries,
because
it
reduces
the
pain
a
lot
to
to
to
build
or
cross
build
mac
or
ios
libraries,
that
is
a
absolute
necessity
to
exist
either.
Otherwise,
I
never
would
want
to
like
interface
with
xcode
myself
to
be
able
to
build
the
libraries.
E
So
that's
definitely
something
I'm
super
thankful
that
it
exists
and
a
very
small
library
for
for
a
simple
caching,
if
you
want
to
add
a
simple
caching
implementation
in
memory
for
your
application
servers,
that's
something
I
I
used
in
a
couple
of
places
already
and
it
it's
very
small,
but
it's
super
fast
and
and
does
the
job
basically,
and
it
has
a
joke
of
130
stars,
even
though
I
know
a
lot
of
people
who
are
using
it
already
and
last
but
not
least,
ranking
something
super
important
in
games,
the
bayesian
skill
rating
system
implementation.
E
I
was
super
surprised
to
find
it
that
it
was
already
there
and
rest.
I
I
kind
of
was
afraid
that
I
had
to
implement
it
myself
and
I'm.
It
was
one
of
those
surprises
that
that
really
made
my
life
so
much
easier.
There's
a
there's,
a
crate
for
that
it
does
all
the
the
crazy
math
for
you
and
you
can
focus
on
actually
getting
your
product
on
the
street,
and
so
that
was
my
little
selection
of
highlight
crates
that
I
wanted
to
share
with
you
so
yeah.
Thank
you
very
much.
B
Thank
you
so
much.
Stefan
interesting
talk.
We
have
one
question
so
far
in
the
zoom
chat
and
I
think
the
person
asks
what's
tech
and
power.
I
guess
it's
the
benchmark
tool.
E
Yeah,
that
was
the
benchmarking
site
that
I
was
referring
to
exactly
I
mean
it's.
Actics
is
the
clear
winner,
I
think
in
most
of
the
categories
there,
and
so
it
yeah,
it
might
be
surprising
to
not
use
that
but
call
it
personal
taste
or
whatever.
For
me,
warp
was
much
more
ergonomic
to
use,
and
I'm
kind
of
sticking
with
that,
because
those
couple
of
milliseconds
of
improvements
I
get
from
actics
are
not
worth
the
hassle
for
me.
B
Okay,
one
question
I
got:
do
you
have
a
comparison
about
the
server
cost?
Like
I
mean
you
talked
about
using
go
in
the
past
and
now
rust.
Do
you
have
a
comparison
of
I
saved
200
bucks
a
month
or
something
like
this
yeah?
That.
E
Would
be
awesome
to
quantify
it,
but
that
is
that
is
super
hard,
because
I
never
translated
as
something
directly
basically
from
go
to
rust
and
so
the
there's
no
direct
comparison
between
the
same
product
written
in
in
go
and
rust
and
to
be
able
to
compare.
E
But
what
I
actually,
what
I
can
actually
extrapolate
based
on
is
the
the
iplookup
service
that
I
translated
to
rust.
B
Okay,
cool
and
there's
one
more
question
popping
up
and
one
person
asks.
Would
you
think
of
using
rocket
again
as
it
is
about
to
be
supported
by
stable,
rust.
E
I
I
guess
no,
but
that's
not
based
on
like
any
facts
that
it's
worse
than
warp
now,
but
it's
more
like
I'm
happy
with
warp,
and
I
this
is
totally.
This
is
totally
not
based
on
any
observations,
but
I
could.
I
would
assume
that
the
ton
of
macros
that
were
that
rocket
supports,
would
also
maybe
hit
the
compile
times
a
little
bit,
and
that
is
something
that
I'm
already
struggling
with
in
in
my
rust
projects.
E
So
I'm
I
I
wouldn't,
I
guess,
add
another
crate
that
would
heavily
put
put
their
work
in
into
into
macros
and
waste
more
compile
time
on
that.
D
B
And
I
have
one
more
question:
would
you
recommend
a
beginner
who
is
just
I'm
starting
out
in
game
development
and
like
in
the
multiplayer
world
to
use,
go
or
or
like
rust
or
se.
D
E
I
think
it's,
I
think
it's
not
a
game,
specific
question
and
I
I
my
personal
opinion
is,
I
think,
it's
hard
to
start
out
with
rust
as
a
first
language
in
general,
no
matter
if
you're
doing
games
or
whatever
and
yeah
it's
it's
hard
to
judge.
Now
that
when
you
come
from
from
a
background
of
c
plus,
plus
and
stuff,
I
think
it's
not
that
not
that
tough,
but
I
think
I'm
in
general,
I
wouldn't
suggest
starting
out
with
the
rust
anyway
to
anyone.
B
B
B
B
A
A
All
right
so
yeah
hi
everybody,
I'm
I'm
ryan
and
I'm
going
to
be
talking
about
a
nearly
30
year
old
technology
today.
A
So
let's
have
some
fun
we're
going
to
be
talking
a
little
bit
about
calm
programming,
why
you
probably
don't
care
about
com
and
probably
shouldn't
care
about
it,
but
it's
still
fun
and
interesting,
and
I'm
going
to
talk
about
it
to
see
if
we
can
learn
a
little
bit
about
things
in
russ
like
dynamic
dispatch,
unsafe,
all
kinds
of
fun
low-level
stuff,
while
looking
at
something
that's
nearly
30
years
old,
I
know
I
know
you're,
probably
you
know
walking
away,
and
this
is
me
right
now
trying
to
keep
you
here.
A
A
Even
if
what
you
learned
today,
or
at
least
the
specifics
of
what
you
learned
today,
might
not
be
directly
applicable
in
your
day
to
day,
there's
still
some
interesting
tidbits
in
there
to
learn
about
and
we're
just
having
a
little
bit
of
fun
poking
around
with
something
that's
been
around
for
a
really
long
time,
a
little
bit
about
who
I
am
when
I'm
not
co-hosting
this
meetup
with
bastian.
I
am.
A
I
do
work
for
microsoft,
so
there's
there
is
a
little
connection
there,
but
my
background
is
definitely
not
in
windows.
I
have
used
linux
and
I
guess
mac
for
basically
my
entire
programming
career,
I'm
not
a
windows
programmer
at
all,
although
I
guess
lately,
I've
been
slowly
converting
into
one,
but
that's
out
of
choice
and
not
really
out
of
being
forced
to
at
microsoft.
On
my
day
to
day,
I
focus
on
rust,
so
everything
rests
at
microsoft
and
our
usage
of
rust
at
at
microsoft.
A
So
if
you're
interested
in
that
as
well,
I'm
happy
to
answer
questions
about
that
as
well.
But
today
we're
going
to
be
talking
about
a
technology
that,
until
about
I'd,
say
a
little
less
than
a
year
ago
was
completely
foreign
to
me.
I'd
never
heard
of
it
before,
and
so
you
know,
if
you're
in
that
boat
as
well,
hopefully
you
can
go
on
the
same
journey
that
I
went
on.
A
What
we're
going
to
be
talking
about
today
is
about
the
difference
between
an
api
and
an
abi,
and
so,
if
you're
not
familiar
with
the
difference
between
these
two
terms,
we'll
talk
about
that
now,
hopefully,
if
you're,
if
you've
programmed
before
you're
familiar
with
the
term
api,
an
application
programming
interface.
A
So
this
is
the
interface
of
some
thing
in
your
program
and
if
we
kind
of
limit
that
down
to
functions,
you
can
imagine
an
api
of
a
function
being
how
many
arguments
does
it
have
you
know
what
are
the
types
of
the
arguments
things
like
that
and
really,
if
you
think
about
what
an
api
is,
it's
really
a
high
level
construct
when
you're
thinking
about
an
api
you're,
not
necessarily
thinking
about
the
the
bits,
the
ones
and
zeros
registers
memory
stuff
like
that,
even
if
you're
programming
in
a
low
level,
language,
like
c
you're,
you're,
usually
not
thinking
about
what
register.
A
Is
this
argument
going
to
go
into
it's
it's
only
if
you
go
lower
level
than
that
and
program
in
something
like
assembly
that
you're
usually
worried
about
that
and
that's
where
the
idea
of
an
abi
comes
into
the
application.
Binary
interface
and
this
binary
interface
is
really
like.
The
nitty
gritty
of
your
function
call
or
whatever
api
that
we're
talking
about
really
very
specific
down
to.
How
does
this
api
work
it?
How
it
works
in
the
actual
computer
is
the
interface's
abi
so
like?
A
Let's
take
a
a
specific
thing
here:
what
are
method
calls
actually
or
function
calls
to
be
even
more
specific.
What
are
they?
What
happens
when
you
call
a
function
in
a
program
if
you've
never
stopped
to
think
about
it
before,
usually,
when
you
think
about
a
function,
call
you're
thinking
about
it
in
high
level
terms,
yeah,
I'm
practicing
some
arguments
and
some
code
is
getting
run
and
then
I'm
getting
a
result
back
but
like
well.
What
actually
happens
when
you
call
that
function?
A
What
registers
do
arguments
go
into
what
if
those
arguments
are
too
big
for
those
registers,
so
we
put
it
on
the
stack?
Do
we
does
it
need
to
go
on
the
heap?
What
order
do
the
arguments
go
in
if
I
write
the
the
function
with
argument?
One
argument
two
argument.
Three,
and
I
have
three
argument
registers
you
know:
does
it
go
into
our
register?
One
does
our
event
one
go
into
register
one,
or
does
it
go
into
register
three
and
in
backwards
order?
A
How
is
the
return
value
given
back
to
the
to
the
caller
of
the
function?
Do
I
put
it
in
some
special
register?
Do
I
put
it
on
the
stack
like
these?
Are
things
that
when
you
call
a
function,
the
caller
of
that
function
and
the
the
callee
of
the
function
need
to
agree
upon?
Because
if
they
don't,
then
things
won't
work.
If,
if
the
caller
expects
the
first
argument
to
go
in
and
register,
you
know,
ax
and
the
colleague
of
the
function
expects
the
first
argument
to
go
on
the
stack.
A
A
But
it's
also
an
interesting
way
for
us
to
look
at
different
apis
of
method,
calls
and
so
method,
one
here
and
I'm
using
the
term
method,
even
though
these
are
clearly
functions
for
a
reason
that
we'll
get
to
in
a
minute
method.
One
here
takes
the
same
arguments
as
method:
two,
it's
the
same
exact
function
so
from
a
high
level
perspective.
These
are
the
exact
same
methods.
A
The
only
difference
between
the
two
is
that
one
has
this
extern
standard
call
attached
to
it
and
the
other
one
doesn't
so
in
rust,
parlons
the
method
one
has
the
kind
of
default,
the
default
rust
api,
and
what
is
that?
Actually,
at
the
end
of
the
day?
Well,
it
depends
on
what
version
of
the
compiler
you
are
and
it
can
change
from
from
compiler
version
to
compiler
version
and
even
from
like
you
know,
commit
to
commit
of
the
compiler.
A
There's
really
no
guarantee
that
russ
gives
of
exactly
what
the
abi
of
this
method
will
be.
So
if
we
need
these
guarantees,
we
need
to
know
exactly
what
that
is.
We
have
to
specify
an
actual
calling
convention
here
and,
if
you're
wondering
well,
then
how
does
rust
work
if
it
can't
agree
upon
it
well
per
compiler
version.
It
does
agree.
So
it's
always
the
same.
So
if
you
compile
a
bunch
of
rust
code,
it
will
have
the
same
calling
convention.
A
But
this
is
why,
for
instance,
when
you
compile
crates,
you
always
compile
your
dependencies
from
source
because
there
is
no
standard
calling
convention,
and
so,
if
we
were
to,
like
you,
know,
put
up
a
bunch
of
binaries
on
on
crates.I
o
and
pull
those
down.
Who
who
knows
what
the
the
calling
conventions
of
those
would
be,
and
your
code
just
wouldn't
work,
and
so
rust
on
purpose
does
not
have
a
standard
calling
convention.
You
have
to
opt
into
one.
A
If
you
need
one
specifically
and
then
here
we're
taking
the
standard
call
calling
convention,
which
again
has
a
reason
that
we'll
look
at
in
a
second
and
you
can
see
on
the
the
right
side
of
the
screen,
particularly
on
the
kind
of
second
assembly
instruction
there,
that
one,
the
method
one
is
getting,
is
reading
a
pointer,
that's
passed
to
it
and
the
rsi
register,
whereas
in
method
two,
it's
reading
it
from
the
stack,
rsp
plus
20.,
so
20
bytes
into
the
stack
it's
reading
from
there,
and
so
this
is
how
these
differ.
A
Apparently
structs,
that
get
passed
in
if
they're
a
certain
size
and
the
current
calling
invention
of
russ
for
rust
c145.
It
will
pass
that
in
as
a
pointer
in
a
register.
But
if
you
standard
call
it
we'll
pass
it
on
the
stack
okay.
So
now
we
know
that
that's
how
things
work,
at
least
in
rus
1.45,
and
how
things
work
for
standard
call
calling
conventions.
This
is
the
abi
of
our
function.
We,
we
can
see
exactly
what
registers
and
where
our
arguments
are
being
passed,
cool
all
right.
A
So
so,
why
are
we
talking
about
this
like?
What
was
the
issue?
Well
imagine
you're
back
in
the
early
90s
in
your
microsoft
and
you're
thinking,
okay,
we
have
a
bunch
of
these
old
class
132
apis,
they're
kind
of
flat
c
style,
apis
they're
apis
that,
for
instance,
linux
still
uses.
So
you
know
you
know
you
could
argue
hey.
They
should
have
never
changed
that
linux
still
uses
flat
style
apis
that
they're
c.
A
You
know
c
compatible
kind
of
very
all
in
one
name
space
that
that
is
how
windows
worked
and
still,
and
some
apis
of
windows
still
works.
But
microsoft
is
like
hey
it's
the
90s.
We
want
to
do
object,
oriented
programming
and
we
want
to
do
it
with
c
plus,
plus,
but
c
plus
plus,
just
like
rust,
does
not
have
a
set
abi.
A
So
there
is
no
set
abi
in
c
plus
just
like
in
rust.
You
have
to
opt
into
it.
You
have
to
say
I
want
this
specific
calling
convention.
Otherwise,
c
plus
is
free
to
choose
whatever
it
wants
from
compiler
version,
a
compiler
version,
and
so,
if
you
were
to
just
compile
like
straight
c,
plus
plus
one
version
for
a
library
and
one
version
for
your
application
code-
and
they
didn't,
you
know
they
were
different
versions
of
the
compiler.
They
wouldn't
work
with
each
other,
and
so
microsoft
was
like.
A
We
want
to
create
a
library
once
and
have
code.
That's
you
know
far
in
the
future.
Different
version
of
c
plus
be
able
to
call
that
with
the
same
api.
A
So
how
do
we
want
also
assure
that
our
apis
are
flexible
and
don't
require
too
much
manual
memory
management,
which
is
a
problem
of
a
lot
of
linux
apis,
for
instance,
you
can
very
easily
you
know,
allocate
a
resource
forget
to
clean
it
up
and
stuff
like
that.
This
is
still
an
issue
in
in
linux.
Nowadays,
in
an
issue
and
and
and
windows
win32
apis,
you
know
I
put
issue
in
air
quotes
because,
depending
on
your
perspective,
it's
an
issue,
but
you
know
I.
I
definitely
think
there's
enough.
A
There's
definitely
some
evidence
out
there
to
say
that
that
developers
often
forget
to
to
clean
up
after
themselves
or
to
use
these
apis
correctly.
So
we
want
to
kind
of
abstract
that
away
from
the
developer
as
much
as
possible.
D
A
It
exactly-
and
this
is
the
thing
that
for
a
while,
I
was
struggling
with
like
if
you
look
at
the
documentation,
I'm
sorry
to
whoever
wrote
the
documentation,
it's
very
fuzzy
and
unclear
of
exactly
what
com
is.
Basically
it's
this.
It's
a
stable,
binary
interface.
The
api
doesn't
change,
so
they
picked
some
api.
A
It's
a
it's
a
programming
model,
that's
based
on
interfaces
and
we'll
look
at
how
you
declare
an
interface
and
exactly
what
that
is,
and
it's
memory
managed
through
reference
counting.
So
just
if
you're
familiar
with
rust,
you
have
rc
or
or
arc,
or
you
know
if
you've
done
object,
c
or
swift.
These
are
languages
that
use
reference.
A
So
where
is
com
used
like
what?
Why
are
we
talking
about
this
30
years
after
it
came
out?
Came
out-
and
I
think
93
was
the
first
year
like.
Why
do
I
care?
Well
there's
still
after
all
this
time,
some
windows
and
non-windows
apis
out
there
that
are
built
on
top
of
com
like
directx,
direct2d,
direct
3d,
direct,
writes
stuff,
like
that.
So
if
you're
doing
game,
programming
or
graphics,
programming
on
windows,
you
still
have
to
use
com
exclusively,
basically
ole
or
olay
is
a
an
api
for
doing
document
sharing.
A
I
don't
think
it's
really
used
a
lot
much
nowadays,
but
also
kind
of
was
the
the
the
kind
of
introduction
to
the
world
for
com.
I
found
this
out
recently
that
core
foundation
plug-ins
so
on
on
mac
or
on
apple
platforms,
use
com,
apparently,
which
is
surprising,
and
then
the
windows
runtime,
which
is
the
kind
of
new
flavor
of
apis
newish.
I
mean
it's
been
around
for
10
years
now,
but
the
the
the
way
that
you
write
like
you
know.
A
Modern
windows
applications
is
using
these
windows
runtime
and
it's
built
on
top
of
com,
so
it's
kind
of
a
layer
or
several
layers
on
top
of
this
com
stuff,
and
so,
if
you're
you're
writing
a
csharp
app
or
whatever
and
you're
using
xaml
or
some
of
these.
You
know
modern
windows,
apis,
it's
it's
using
calm
under
the
hood.
A
So
how
do
we
support
calm
and
rust,
like
the
reason
that
I
that
we
need
to
do
this
is
because
hey
we
probably
want
to
work
with
windows
right
like
it's.
It's
still
an
operating
system
that
gets
a
ton
of
users.
We
want
to
be
able
to
use
it
and
a
lot
of
their
apis
require
calm.
So
how
do
we
should
have
good
support
for
and
russ
so
that
we
can
take
advantage
of
this
stuff
so
that
we
can
write
things
like
direct
2d
applications?
A
Direct3T
applications,
like
you
know,
aaa
games,
for
instance,
use
use
these
things.
So
how
do
we
do
that?
Well,
we
need
a
way
and
russ
to
declare
in
interfaces
to
correctly
call
interface
methods,
methods
on
these
interfaces
to
correctly
hook
into
the
memory
management
model.
That
com
deals
with
and
to
implement
these
com
classes,
which
are
the
like
objects,
that
implement
the
interfaces.
A
A
So,
let's
look
at
declaring
interfaces.
What
does
that
look
like
well?
This
is
again.
This
is
a
a
crate
that
I'm
working
on
now
called
com.
You
can
find
it
on
crates.I
o
under
com,
and
this
is
how
you
declare
an
interface
and
here
we're
declaring
an
interface
called
I
animal,
and
it
has
two
methods
on
it.
You
can
eat
some
food
and
it
can
give
you
its
happiness
as
a
you
size.
A
So
can
tell
you
how
happy
it
is,
and
this
is
you'll
you'll
notice,
it's
a
bit
of
a
funny
syntax
here.
You
have
this
like
uuid
thing:
that's
because
you
can
get
interfaces
by
a
unique
identifier
string,
so
we
have
to
to
do
that.
That's
a
part.
We
won't
talk
about
and
we're
passing
like
a
pointer
to
food.
That's
because,
like
we're
really
talking
about
low
level
things,
this
has
to
be
kind
of
c
abi
compatible.
A
So
you
can't
just
you
can't
pass
like
a
a
vector,
a
rust
vector
in
there,
because
that
the
the
abi
of
a
rest
vector
its
layout
in
memory,
is
not
it's
not
set
in
stone,
so
it
could
change
from
compiler
version
compiler
version,
so
we
have
to
be
very
careful
about
what
we
pass
across
this
api
layer,
but
this
is
what
it
looks
like
kind
of
in
a
rough
way
we're
declaring
an
interface
I
animal.
It
inherits
from
I
unknown,
which
we'll
look
at
in
a
second.
A
It
can
eat
food
and
it
can
give
you
its
happiness.
That's
that's
what
it
looks
like
here,
and
then
we
have
an
interface
called.
I
unknown
that
that
all
other
interfaces
inherit
from
here
and
it
has
three
methods
on
it,
and
these
are
the
three
kind
of
like
this
is.
If
you
want
to
understand
com.
This
is
what
it
it's
all
about.
A
The
first
one
we'll
skip
the
first
one
for
a
second
query:
interface,
the
first,
the
next
two
are
have
to
do
with
its
memory
management
model.
So
add
reference
is
basically
increasing.
Its
reference
count
and
release
is
decrementing.
Its
reference
count.
So
every
time
that
you
get
a
new
kind
of
handle
on
an
interface,
you
need
to
call
adref
and
if
you
no
longer
are
using
the
handle,
you
need
to
call
release,
and
so
hopefully,
in
your
head,
you're
thinking,
hey.
A
A
The
uuid
that
you
see
on
the
screen
there
for
the
for
some
given
interface
is
the
interface
that
I
have
here
compatible
with
this
other
interface
and
kind
of
like
convert
it
into
it.
So
like
dynamically
at
runtime,
I
can
just
provide
an
id
for
an
interface
and
optionally
get
that
interface
from
from
another
interface,
and
you
know
if
it
doesn't
support
that
interface,
because
it
doesn't
implement
that
interface,
then
it
just
returns.
You
know
a
negative
result.
Basically,
so
that's
high
unknown.
So
now
we
have
to
figure
out.
A
How
do
we
actually
do
interface
method
calling-
and
this
is
where,
like
this
is
generated
code
right
here-
you
won't
actually
write
this.
All
that
we
looked
at
before
that.
That
macro
that
we
looked
at
before
is
is
implementing
this
for
you,
and
you
can
see
that
an
eye
animal
interface
is
just
a
pointer
to
a
v
table
pointer.
A
So
there's
a
little
bit
of
indirection
in
there
on
line
seven,
you
have
a
non-null
pointer
that
points
to
another
pointer
which
points
to
some
a
v
table,
and
so,
if
you're
familiar
with
with
dynamic
dispatch,
this
is
what
dynamic
dispatch
is
all
about.
We're
going
to
a
v
table
a
a
a
virtual
table
where
we
actually
dispatch
our
our
method.
A
A
And
here
here
I
added
a
a
little
bit
to
so.
You
can
see
it
better.
Sorry
that
I
didn't
use
that
before-
and
this
is
what
a
v
table
looks
like
you
have.
The
I
animal
v
table
has
its
parent
v
table
in
it
at
the
beginning
of
it
and
the
eat
and
happiness
methods
in
it
as
well
and
notice
there
that
it's
using
the
standard
call
function
that
we
solved
here.
So
we
know
exactly
when
we
call
this
function.
A
A
Memory
management,
real
quick,
we
said
it
before
on
when
we
dropped
the
I
animal
interface,
it's
going
to
call
release
on
the
I
unknown
interface,
so
that
just
decrements,
the
the
pointer
and,
of
course,
the
the
backing
implementation.
When
the
reference
count
reaches
zero,
the
whole
thing
will
be
freed
because
it's
not
used
anymore
and
on
clone
we're
calling
ad
ref.
So
every
time
we
clone
a
handle
to
our
our
interface,
we
add
a
reference
to
it,
and
this
is
how
memory
is
managed.
So
you
can.
A
You
basically
can
be
assured
that,
as
long
as
you
have
a
an
eye,
animal
that
it's
it
has
valid,
it
has
valid
memory
because
we're
we're
only
getting
another
one
if
we
clone
and
we're
in
adding
ref
and
we're
only
releasing
it
when
we
drop
the
thing
and
we
no
longer
use
it
and
then
real,
quick.
Exposing
a
class
looks
like
this,
so
we're
basically
doing
the
reverse,
where
we
declare
the
implementing
class.
A
In
this
case
our
animal
is
a
lion
and
we
have
to
implement
the
the
eat
and
happiness
methods
on
it
here
and
what
the
macro
the
class
bang
macro
does.
Is
basically
in
reverse,
implement
a
v
table
that
when
it
gets
called,
it
will
call
our
our
eat
and
our
happiness
methods
for
us,
and
so
everything
kind
of
lines
up
the
client
can
call
into
a
v
table
the
class
implements
that
b
table
and
when
the
client
calls
through
that
v
table,
it
will
go
to
the
implementation.
A
A
So
you
know
if
this
is
weirdly
strangely
interesting
to
you,
you
can
get
lost
in
it.
There's
a
whole
bunch
of
other
stuff
in
there
like
registering
classes,
class
factories,
blah
blah
blah
we're
not
going
to
get
into
any
of
that.
We
just
looked
at
kind
of
the
core
low-level
thing
of
how
we
call
into
a
an
interface
and
how
we
implement
that
interface,
and
this
is
what
it
looks
like
in
real
life.
Here's
a
some
direct
2d
code
being
called
in
here.
A
It's
for
an
app
that
I'm
working
on
right
now
that
is
not
finished.
This
is
what
it
looks
like
right
now.
Eventually
it
will
be
a
clock
that
will
go
around
it's
not
done.
I
didn't
know
I
was
giving
this
talk
today,
so
sorry
for
the
unfinished
clock,
if
you're
interested
in
and
looking
into
this
windows
programming,
weird
30
year
old
interfaces
and
stuff
like
that,
come
come,
join
us
you'll
notice,
down
below
it
says,
com
has
been
superseded
by
winrt
windows
runtime,
which
is
true.
A
This
is
what,
when
rt
looks
like
so
you're
importing
some
namespaces,
and
then
you
get
safe,
real,
safe
code
that
you
can
call
in
here
and
it's
all
built
on
a
foundation
of
the
snarly
unsafe
com
that
we
just
looked
at,
but
is
because
of
the
metadata
safe
to
to
call
all
right,
and
that
was
a
whirlwind
tour
of
a
30-year-old
technology
and
here's
awkward
bill
gates
dancing.
B
A
And
it
would
be
hopefully
at
some
point
like
com
on
linux,
which
is
still
used,
for
instance,
and
and
for
the
stuff
in
firefox.
You
should
be
able
to
use
the
commerce
crate
for
that
as
well.
So
maybe
we
can
start
consolidating
the
the
community
a
little
bit
so
there's
not
a
ton
of
different
implementations,
but
right
now
it's
all.
B
A
Does
com
support
method
of
overloading?
I
believe
it
does.
It
should
in
languages
that
support
overloading
you
would
because
the
methods,
the
names
of
the
methods
don't
actually
matter,
it's
just
their
place
in
the
v
table,
and
so
we
have
a
mapping
in
our
rust
code.
That
says
like
the
eat
function
on.
A
I
animal
is
like
the
second
method
in
the
v
table,
and
so,
if
the
backing
class
that
implements
that
calls
it,
you
know
fubar
instead
of
e,
doesn't
matter
as
long
as
it
is
just
it
has
the
same
signature
and
it's
in
the
same
place
in
the
v
table,
and
so
you
could,
in
theory,
have
multiple
methods
named
the
same
thing
as
long
as
they
dispatched
to
two
places
in
in
the
v
table.
But
of
course,
rust
can't
support
that,
because
rust
doesn't
support
overloading,
so
you'd
have
to
give.
B
Them
different
names,
but
yeah
cool
next
question
is:
does
does
the
new
win,
ui
use
com2.
A
So
when
ui
uses
winrt
under
the
hood,
and
so
if
you're
interested
in
when
ui
then
contribute
to
the
winrg
project
and
because
when
rt
uses
com
under
the
hood,
then
yes,
when
ui
uses
com
at
the
end
of
the
day,
we
are
working
on
there's
a
whole
bunch
of
things
in
addition
to
com,
basic
com,
support
and
basic
winrt
support
that
are
needed
for
wind
ui
and
we're
working
towards
that.
A
So,
yes,
eventually,
you
will
be
able
to
write
when
ui
windows,
applications
in
rust
and
just
plain,
hopefully
rather
idiomatic
rust,
so
come
join.
Help
us
build
that.
B
This
one's
a
reason
to
get
a
like
a
windows
laptop
soon
again,
and
I
pick
one
more
what's
the
plan
at
microsoft
to
use
rust
on
com
interface,
I
think
you
just
answered
this.
A
Yeah
there's
a
whole,
I
mean
we
want
to
start
using
more
and
more
rust
at
microsoft
and
a
bunch
of
our
obviously,
our
external
apis
are
com
based
and
internal
apis
that
you
know
outside
developers,
don't
ever
see,
are
also
com
based
and
so,
and
we
have
a
bunch
of
technology
that
we
definitely
are
still
very
much
investing
in.
That's
like
like
when
our
t,
for
instance,
it's
built
on
top
of
com,
so
this
is
all
like.
B
Ecosystem
so,
okay,
and
then
let's
ask
the
last
the
last
one
too,
are
you
also
planning
to
add
a
layer
on
top
of
com
rs
that
makes
it
safe.
A
Now,
if
you
we
might
add
a
layer
to
comrs
that
would
allow
you
if
you're
writing
a
interface
and
rust
and
the
backing
implementation
is
in
rust
that
you
can
assume
that
it's
safe
and
maybe
we'll
add
some
support
there,
but
but
really
there's
just
there's
not
enough
information
to
know
whether
what
you're
doing
is
fully
safe
according
to
to
the
rust
runtime.
A
There
are
some
things
that
will
definitely
make
it
safer
to
use,
for
instance,
we're
working
in
the
sorry
in
the
safe
transmute
working
group,
which
I'm
in
in
order
to
better
be
able
to
declare
types
as
having
certain
layouts
in
memory
with
the
type
system,
so
so
being
able
to
say
in
the
type
system.
This
type
has
a
stable
layout.
It
you
know,
is
this
big?
It's
it
has
this
alignment
blah
blah
blah?
A
You
can't
talk
about
in
the
in
the
type
system
today
about
those
ideas.
We're
gonna
make
it
so
that
you
can
and
then
we
can
encode
that
and
some
of
these
apis
and
make
it
so
that
it's
harder
and
harder
to
screw
up
the
com
api.
But
I
don't
think
we'll
ever
get
to
a
point
where
we
can
make
it
fully
where
you
don't
have
to
write
unsafe,
because
there's
just
not
enough
info
to
know
that.
B
It
makes
sense
yeah
well,
thank
you
so
much
yeah
and
there
is
a
little
like
announcement
from
sisha
and
there's
no
rust
and
tell
without
question
so.
D
B
Thank
you
so
much.
We
will
try
it
out
and
there
is
the
link
in
the
zoom
chat
for
people
who
want
to
see
it
cool.
Well,
if
there
are
any,
if
there
are
any
last
questions
from
anyone
feel
free
to
talk,
and
if
not,
we
see
you
in
august
last
tuesday
of
the
month
as
always
feel
free
to
get
in
touch
with
ryan
or
me
to
give
a
talk.