►
From YouTube: RustFest Zürich 2017 - Type-safe & high-perf distributed actor systems with Rust by Anselm Eickhoff
Description
Introducing a working prototype for a minimal actor-oriented system runtime to handle millions of actors and passed messages, across processor cores and even machines. It is written in and used from Rust. Using an additional code-generating build script, type-safe remote message sending and handling is magically desugared from plain Rust function calls and definitions, including dynamic dispatch with traits. This makes it possible to write complex, extensible distributed systems in idiomatic Rust.
About Anselm Eickhoff:
Self-taught hacker and CS student from Germany. Got the crazy idea to build Citybound - a new, large-scale city simulation game and engine, on my own. I’m busy plowing through all the custom technology that needs to be invented and implemented for that, all of which I write in Rust.
A
So
this
is
what
happened
for
me
and
I
will
talk
to
you
today
about
typesafe
high-performance,
distributed
active
systems
and
rust.
I
would
introduce
myself
as
a
hacker
who
loves
systems
that
are
complex
and
interesting
ways
and
I
think
that
this
has
in
large
parts
to
do
with
what
I
grew
up
with,
which
were
games
like
a
train
or
SimCity
2000
we're
at
a
very
young
age.
A
I
was
interacting
with
these
really
complicated
systems
and
through
play
getting
an
intuitive
feeling
for
something
like
that,
and
what
I
think
needs
to
happen
in
general
is
that
we
should
bring
this
intuitive
systems
level
thinking
to
the
next
generation
and
I
think
the
best
way
to
do
that
is
through
Play
as
well.
My
brand
for
doing
that
is
a
play,
and
let
me
tell
you
about
my
first
step
along
this
mission.
A
Thinking
back
to
these
city
building,
games
of
my
childhood
I
realized
that
a
lot
of
my
interests
intersect
there
and
it
was
really
the
logical
thing
for
me
to
do
to
create
a
city
building
sandbox,
where
large-scale
cities
with
citizen
level
detail,
become
understandable
and
design
able
and
the
new
thing
which
I
wanted
to
add
is
in
a
collaborative
planning
fashion.
And
this
is
my
project
which
I've
been
working
on
for
a
couple
years
now
called
City
bound.
A
Let
me
give
you
a
short
history
and
I
will
go
through
this
really
quickly,
but
just
to
give
you
the
general
background,
it
all
started
in
2013
when
EA
and
Mac's
us
together
announced
a
new
instance
in
the
genre-defining
series
of
SimCity,
SimCity
2013,
and
what
I
promised
was
this?
Like
beautiful,
detailed
cities
where
you
could
see
every
individual
car
and
they
said
they
would
simulate
every
individual
citizen
with
their
lives,
and
you
could
watch
that
and
interact
with
that
when
they
released
it.
A
But
but
still
this,
this
promise
and
this
vision
of
actually
simulating
a
huge
city
at
the
individual
person
level
was
so
fascinating.
For
me,
that
I
really
really
wanted
to
try
for
myself,
and
this
is
what
started
city
bond
I
started.
First
by
building
some
traffic
simulation
prototypes,
I
used,
JavaScript
and
WebGL,
simply
because
there
was
what
I
was
most
familiar
with
and
which
allowed
me
to
iterate
the
quickest
and
once
I
had
that
ready.
A
I
just
announced
that,
in
a
blog
post,
together
with
my
like
general
plans
of
all
I,
want
to
do
a
city,
bullying,
game
and
assume
cities
separated
and
I
had
what
I
call
the.
Let
me
see
if
I
can
figure
this
out
yeah
the
announcement
weekend,
because
they
literally
spend
a
whole
weekend
just
answering
comments
and
questions
by
other
people
who
were
also
frustrated
by
SimCity
and
who
really
believed
in
my
vision.
I
then
quickly.
A
Continued
iterating,
implementing
several
very
important
basic
game
features
and
I
started
to
interact
more
and
more
closely
with
my
newfound
community.
Through
blog
post,
update
videos
and
even
programming
live
streams,
there
was
I
would
say
one
defining
moment
where
I
invented
and
implemented
a
first
prototype
of
what
I
call
planning
mode
which
really
sets
it.
Apart
from
other
city
building
games,
where
you
don't
directly
manipulate
the
city,
you
just
don't
build
roads
over
buildings,
but
you
create
first,
a
draft,
a
plan
of
what
you
want
to
create
much
like
in
real
life.
A
That
represents
the
kind
of
change
set.
I
think
this
should
be
intuitive
to
as
programmers
that
you
want
to
apply
to
your
city
and
that
this
would
be
the
main
way
of
interacting
and
playing
city
bound,
but
soon
after
that,
I
got
into
a
phase
where
I
noticed
myself,
focusing
more
and
more
on
like
hardcore
optimization
problems
and
low
level
architecture.
Questions
in
JavaScript.
A
It
took
me
quite
some
time
just
to
get
the
graphics
and
fundamentals
going
again.
I
did
some
preparation
for
geometry.
Procedural
buildings
then
decided
to
focus
on
these
difficult
topics
like
memory
layout,
persistence,
optimization
and
realized
that,
if
I
would
continue
with
C++,
I
would
probably
be
able
to
finish
within
my
lifetime,
but
I
would
also
go
insane.
So
luckily,
at
this
point
in
time,
I
heard
about
rust
and
it
seemed
stable
enough
to
give
it
a
try.
So
I
gave
it
a
try
and
got
really
blazingly
quickly
through
the
graphics
and
fundamentals.
A
Part
thanks
to
projects
like
gleam,
for
example,
which
allowed
me
to
immediately
focus
on
the
difficult
topics
like
memory
layout
found
out
that,
of
course
they
are
inherently
difficult.
But
rust
allowed
me
to
do
both
really
difficult
low-level
stuff,
but
then
abstracted
nicely
so
I
could
move
on
quickly
to
re-implement
my
traffic
simulation
and
I
decided
at
this
point.
A
I
wanted
to
have
again
I
kind
of
released
to
my
community
and
I
decided
to
radically
change
how
I
think
about
the
project
and
decided
to
make
it
open
source
and
to
make
the
first
prototype,
even
though
it
was
just
traffic
simulation
available
to
all
of
my
fans
and
I
also
launched
a
page
on
patreon.
Since
then,
I
have
been
again
reiterating
from
the
beginning.
All
the
different
game
features
that
I
needed,
and
we
will
take
a
look
at
that
later.
A
If
you
use
them
to
give
you
an
idea
of
how
I
arrived
at
using
actor
systems,
let
me
give
you
my
original
motivating
challenge,
which
was,
of
course,
to
simulate
a
whole
metropolis
in
real
time
on
one
computer.
This
implies
several
challenges.
The
first
one
is,
if
you
think
about
it,
it's
common
in
game,
development
that
you
have
millions
of
particles.
For
example,
the
particles
are
pretty
simple
things
like
they're
all
the
same
in
size.
A
They
don't
have
references
to
other
particles,
whereas
for
me,
I
have
citizens
with
a
workplace
and
other
family
members,
and
they
might
have
different
amounts
and
different
kinds
of
resources,
each
of
them
so
and
I
needed
to
batch
process,
millions
of
them
several
like
60
times
per
second
at
least
so.
What
I
needed
was
to
achieve
cache
locality
for
something
like
that,
even
though
they
were
dynamically
sized
second,
because
I
was
pretty
much
aware
that
my
game
state
would
be
several
gigabytes
in
RAM.
A
A
Already
back
in
C++
times,
where
I
decided
to
only
use
plain
old
data
and
what
I
call
special
recursively
compact
containers,
where
you
have,
for
example,
a
struct
of
vectors
and
maybe
a
dictionary
in
there,
but
each
of
them
are
laid
out
consecutively
in
memory
and
if
they
grow
the
whole
thing
grows
and
the
individual
parts
gets
more
space.
That's
a
whole
topic
in
itself,
if
you're
interested
in
asking
about
it
later,
but
I
think
I
kind
of
get.
A
The
idea
across
the
important
thing
is
that
now
everything
in
my
game
stayed
each
entity
has
a
continuous
data
format
that
is
the
same,
but
in
RAM
and
disk,
but
there's
a
problem
because
these
entities
cross
reference
each
other
and
like
they
can
both
be
moved
in
memory
and
also
persisted
to
disk.
And
at
this
point,
if
you
just
use
pointers
as
references
that
stops
working,
they
stopped
being
valid.
So
the
solution
for
Redis
again
something
pretty
common
in
game
development,
I
used
entity
IDs
as
an
indirection
and
slot
maps
that
resolve
the
entity.
A
Ladies
into
actual
pointers
at
runtime,
the
last
challenge
and
the
toughest
one
which
I
think
we're
all
facing
was
parallelization.
It
was
clear
that
one
core
wouldn't
be
enough
to
simulate
it,
maybe
not
even
one
computer,
if
I'm
thinking
about
really
large
cities
or
whole
regions,
and
what
is
the
solution?
Well,
this
is
something
that
we're
all
thinking
about.
That
is
a
problem
to
all
of
us.
A
The
traditional
approaches
that
you
take
many
cores
or
many
computers
and
pretend
that
they're
1,
and
for
that
you
use
shared
memory
and
synchronization
that
is
inherently
unsafe
and
tricky.
Rust
helps
a
little
bit
with
that,
but
if
you
think
about
the
scale
that
I'm
dealing
with
where
you
have
millions
of
tiny
entities-
and
you
want
to
synchronize
them
in
real
time,
it
just
kind
of
stops
being
feasible.
A
But
I
heard
about
this
other
philosophy,
where
you
do
the
opposite,
and
you
say
that
what
if
one
computer
was
real
like
many
computers,
how
do
many
computers
communicate
in
the
internet?
They
pass
messages
with
each
other.
Why
don't
we
just
take
this
pattern
and
scale
it
down
and
say
that
our
basic
abstraction
is
a
computer
which
I've
seen
before
only
in
Erlang,
but
it
works
really
well.
There
and
I
really
enjoyed
writing
systems
that
way,
and
this
basic
abstraction
is
not
called
a
tiny
computer,
but
it's
actually
an
actor.
A
It's
also
known
as
an
object
in
the
original
sense,
as
Alan
Kay
defined
it
when
he
invented
object-oriented
programming
and
the
idea
is
really
simple:
it's
just
an
object
that
has
isolated
state
that
only
it
itself
can
mutate
and
the
only
way
it
can
influence.
Other
hector's
objects
is
to
message
passing
by
sending
the
messages
so
to
represent
this
cycle.
Let's
just
take
one
actor
here,
which
has
some
actor
state
and
it
receives
a
message
from
another
actor.
A
It
has
a
message
handler
that
is
associated
with
this
particular
type
of
message
and,
while
handling
the
message
we
can
mutate.
The
actor
state
to
produce
a
new
actor
state
and
we
can
send
arbitrary
messages
to
other
actors,
and
all
of
this,
you
built
everything
in
an
actor
system
based
architecture.
A
There
were
even
I
think
actor
systems
for
us
when
I
started
this.
There
were
definitely
a
lot
of
solutions
for
actor
systems
out
there,
but
I
needed
something
much
more
lightweight
than
most
of
them,
because
they
had
lots
of
fancy
features.
They
operated
on
a
really
high
level,
which
is
cool
if
you're
writing
high
level
applications
like
Web
Services,
or
something
like
that.
But
I
was
really
okay
with
something
less
fancy
like
I,
didn't
need
to
hide
a
synchronicity
or
something
like
that.
I
just
needed
raw
speed,
so
I
started.
A
Writing
my
own
actor
system,
which
I
called
Kay
and
when
I
started.
I
realized
that,
thanks
to
my
previous
work,
I
already
had
a
lot
of
the
basic
ingredients
that
I
needed
to
represent
the
actor
state
and
messages.
I
could
use
my
plain
old,
beta,
plus
recursively
compact
containers
for
the
actor
identity
and
references
between
actors.
A
Furthermore,
they
don't
care
where
and
by
whom
they
are
updated,
so
it
doesn't
really
matter
on
which
core
an
actor
is
running
and
which
core
decides
to
process
which
actor
wins.
So
again,
you
separate
your
business
logic
for
from
things
like
multi-core
load.
Balancing
actors
also
don't
care
when
and
how
often
they
are
updated
and
scheduling
is
something
very
important
in
games
where
you
might
have
rendering,
which
runs
at
a
different
pace
than
physics
which
runs
at
a
different
pace
than
other
things.
A
That
only
need
to
be
updated
from
time
to
time
and
doing
something
like
this
is
very
natural
and
easy
in
actor
system.
So
again,
because
the
business
logic
itself
doesn't
care
how
grunts?
If
you
combine
some
of
the
previous
points,
that
actors
don't
care
when
at
home
they
are
updated
and
where
and
how
they
are
stored.
A
You
realize
that
it
actually
becomes
possible
to
stop
the
whole
simulated
world,
save
it
to
the
disk
and
resume
it
at
any
later
point
without
any
serialization,
and
one
extra
bonus
thing
is
that
actors
don't
care
who
exactly
they
interact
with
if
they
send
a
message
to
someone,
they
don't
care
about
the
type
of
that
l
director.
They
just
care
that
it
will
understand
this
message,
which
allows
you
to
actually
create
a
whole
new
form
of
dynamic
dispatch
from
them.
A
A
Here
we
are,
and
I
will
start
by
just
drawing
a
plan
for
a
small
village.
You
were
drawing
like
a
four-lane
road,
let's
create
another
second
four-lane
road,
maybe
a
couple
smaller
ones
to
connect
everything,
and
you
can
see
it
automatically,
like
figures
out
pretty
complex
intersection
geometry
here,
if
I
wanted.
I
could
have
like
this
horrible
six
way,
intersection
here
and
just
works.
Okay,
let's
say
I'm
happy
with
that.
A
So
I
built
that
you
can
see
the
roads
built,
you
can
see
it
created
traffic
lights
for
this
horrible
intersection
which
actually
have
timings
that
kind
of
make
sense,
but
just
like
this,
it's
a
little
boring
and
empty.
So
let's
spawn
a
couple
of
buildings
where
people
can
live
all
right,
that's
good!
And
now,
if
you
wait
for
a
second,
we
will
see
that
some
cars
appear
and
these
are
actually
the
inhabitants
of
these
buildings
going
about
their
daily
business.
You
can
see
the
cars
like
break
and
slow
down.
A
A
This
person,
in
particular,
is
like
getting
more
and
more
hungry
and
more
and
more
sleepy
as
I
think
all
of
us
are,
but
they
actually
solve
these
problems
by
driving
to
these
like
great
buildings
here,
which
are
grocery
shops
and
the
grocery
shops
selling
food
and
everything
you
see
here
is
actors
like
every
piece
of
road
is
an
actor.
Every
family
is
an
actor.
Every
family
actor
belongs
to
this
family.
Every
house
is
an
actor.
A
The
renderer
itself
is
actually
an
actor,
and
all
these
other
objects
send
it
messages
to
render
themselves
and
I
think
you
can
see
that
I
mean
this
is
just
the
village
but
I'm
actually
representing
every
single
person
with
all
of
their
detail.
I'm,
not
cheating,
they
go
back
to
the
same
home
and
so
on.
A
But
of
course
the
important
question
for
me
was:
would
it
actually
scale
to
the
scale
that
I
wanted?
So
let
me
restart
that
and
use
a
handy
generating
tool.
So,
let's
force
the
game
to
create
a
huge
10
by
10
kilometer
grid
of
roads
with
8
Lane
roads.
Actually,
here
you
see
the
plan
for
that.
Let
me
zoom
out
it's
pretty
big,
let's
build
that!
A
This
takes
a
little
bit
now,
because
this
is
something
that
would
never
really
happen
in
the
game
itself
like
I
would
just
gradually
build
the
city,
but
it
doesn't
really
take
that
long.
Now,
you
can
see
the
roads
building
again
with
the
traffic
lights
and
everything
just
here
to
give
you
a
sense
of
scale
and
now,
if
you
look
at
the
frames
per
second
and
slows
down
a
little
because
right
now,
it's
calculating
all
the
pathfinding
from
every
possible
spot
in
this
grid
to
every
other
possible
spot.
A
And
yeah:
let's
just
wait
for
it
to
settle
up
what
I
will
do
next
is
I
will
spawn
100,000
cars,
which
should
be
enough
to
simulate
which,
which
should
be
enough
to
simulate
a
city
of
about
1
million
people,
because
at
rush
hour,
there's
roughly
10%
of
the
population
on
the
road
at
once.
According
to
statistics,
I
looked
this
up.
I
just
don't
have
the
source
now,
okay,
so
let's
spawn
the
cars
again,
give
it
a
second
for
them
to
appear
I.
A
A
A
But
now,
let's
come
back
to
these
freedoms
that
I
mentioned
earlier
and
really
think
them
to
their
logical
conclusion:
actors:
don't
care,
we
aren't
how
they're
stored
so
storing
them
on
a
different
computers.
Okay,
they
don't
care
where
and
by
whom
they
are
updated,
so
updating
them
on
a
different
computers.
Okay
and
since
everything
is
asynchronous
and
actors,
don't
really
care
when
exactly
their
messages
arrive.
A
Sending
the
messages
over
network
is
actually
also
okay,
and
at
this
point
you
have
to
ask
yourself:
is
it
actually
possible
to
write
a
distributed
game
engine
based
on
that
and
again,
the
answer
seems
to
be
yes,
and
this
inevitably
leads
me
to
the
second
much
more
risky
demo.
Let's
get
started,
I
will
again
launch
city
bound
this
time.
You
see
some
IP
addresses
here
and
I
will
start
the
same
way.
First,
just
by
drawing
a
small
village.
A
A
Let's
just
dress
test
this
as
well.
I,
don't
know
how
well
it
will
work,
because
this
is
just
over
Wi-Fi,
but
let's
try
so
Veronica.
Could
you
please
create
the
grid
a
slightly
smaller
one,
just
with
less
lanes
actually,
and
can
you
build
it
please
and
yeah?
It
took
a
second
for
it
to
arrive,
but
now
this
grid
was
actually
kind
of
streamed
from
her
laptop
to
mine,
including,
like
all
the
lanes
and
traffic
lights
and
everything
and
yeah.
A
Why
don't
you
spawn
some
cars
there,
and
here
the
cars
are
I'm,
not
doing
anything,
and
we
can
see
them
with
slight
hiccups,
but
now
running
just
as
smoothly
as
before,
with
the
only
difference
being
that
they're
not
only
being
rendered
here
on
my
screen,
but
that
all
of
their
positions
and
everything
is
also
being
writing
to
her
laptop,
and
it
should
look
pretty
much
exactly
the
same
for
her
sore
here.
We
have
this
potentially
huge
city
here,
just
the
traffic
running
in
real-time
synchronization,
two
laptops.
A
Cool,
so
thank
you
very
much
Veronica
for
being
my
player
to
both
in
this
demo
and
in
real
life,
and
just
to
give
you
an
idea
of
how
well
all
the
different
parts
of
the
game
already
distributed,
because
even
though
everything
is
implemented
as
actors
I'm
still
used
to
like
the
traditional
kind
of
coding,
where
you
write
everything
very
centralized.
But,
for
example,
like
I
mentioned,
the
render
is
really
centralized.
The
traffic
simulation
part
funding
already
really
well
centralized
other
stuff
I
still
have
to
work
on
to
make
it
more
concrete.
A
A
To
give
you
just
a
quick
idea
in
the
end
about
what
this
looks
like
in
code.
I
want
to
show
you
two
iterations
of
my
API
design,
for
that.
Okay
is
something
really
specialized
that
I
really
only
write
for
myself,
but
I
should
be
even
nice
to
the
user.
Who
is
me
so
let
me
show
you
what
I
did
and
we
will
use
the
example
of
a
parrot.
We
will
implement
a
parrot.
A
A
A
greeting
has
a
greeter
which
is
the
other
bird
I
guess
which
sent
this
greeting
and
the
number
of
tweets
encoding
all
of
the
information
in
the
greeting,
as
is
normal
for
birds
and
then
for
the
parrot
to
be
able
to
understand
the
greeting.
We
implement
recipient
of
greeting
for
parrot.
It
has
this
receive
function
which
takes
the
state
of
the
parrot,
as
mutable
self
gets
a
reference
to
the
message,
and
then
a
third
parameter
called
word
world,
which
represents
the
worldview
of
this
actor
the
parrot
and
is
mainly
used
to
send
messages.
A
When
we
receive
such
such
a
message,
we
update
our
happiness
by
the
number
of
tweets
that
we
received,
and
we
add
the
greeter
to
our
list
of
friends
and,
of
course,
since
we
are
paired,
we
will
just
reply
with
exactly
the
same.
So
in
our
world,
we
send
to
the
greeting
dot
greeter
a
greeting
ourselves.
We
put
our
own
ideas,
the
greeter,
and
we
reply
with
the
same
number
of
tweets.
A
Finally,
in
the
bottom,
I
have
some
boilerplate,
which
I
need
to
register
the
parrot
with
the
actor
system
and
to
tell
the
actor
system
that
it
can
actually
handle
the
greeting.
So
there's
kind
of
lots
of
repetition
and
verbosity
here
and
in
this
example,
it's
still
kind
of
fine,
but
if
you
imagine
a
whole
code
base
that
gets
really
annoying
really
quickly.
Something
that's
really
cool
is
that
this
ID
can
refer
to
any
actor
of
any
kind
thanks
to
this
indirection.
Something
that's
not
cool
is
that
this
means
that
this
can
horribly
fail
at
runtime.
A
If
we
send
this
message
to
some
random
ID,
where
we
don't
know
if
this
actor
will
actually
be
able
to
understand
this
message
regarding
the
verbosity
I
tried
a
couple
iterations
that
are
really
similar
to
this
one.
That
just
got
a
little
shorter.
But
the
main
point
that
I
wanted
to
address
was
really
this
problem
here
and
to
invent
version.
2
of
the
syntax
I
had
to
involve
metaprogramming,
not
the
typical
meta
programming
for
rust
macros,
because
it
really
wasn't
enough,
but
the
lesser-known
one,
which
is
build
scripts
and
what
I
did
was
I
used.
A
The
very
amazing
sin,
in
quote
crates
which
respectively
parse
any
kind
of
rust
code
or
generate
any
kind
of
rust
code,
and
what
I
did
was
I
basically
write
this
kind
of
code,
which
I
will
explain
in
a
second.
This
gets
parsed
and
the
build
script
generates
additional
rust
code.
That
is
basically
what
I
all
the
annoying
stuff
that
I
did
by
hand
in
the
past.
So
let's
look
at
this
again
I
defined
a
parrot.
You
will
notice
that
it
has
a
parrot
Idina.
A
So
the
first
thing
the
build
script
does
is,
for
each
actor
type
that
automatically
generates
a
corresponding
typed
actor
ID,
which
can
only
refer
to
this
kind
of
actor.
Next
I
just
implement
parrot
itself
and
I
define
a
greet
function.
I
don't
have
to
create
a
struct
anymore
for
the
message:
I
just
define
a
function
takes
again
the
state,
here's,
my
parameters
and
the
world.
This
looks
the
same,
and
the
cool
thing
is
that
the
build
script
then
generates
for
the
ID
type,
a
corresponding
sending
function.
A
So
I
can,
for
example,
just
say,
greeter
dot
greet,
and
this
is
actually.
This
is
not
a
parrot
object
or
something
it's
just
an
ID,
but
what
this
internally
does
is
send
a
message
to
the
actor
system
using
this
world
reference
here
to
some
other
actor,
but
it
just
looks
like
a
normal
function
call
and
the
code
became
super
short
and
normal.
Looking
I
have
to
include
this
additional
like
auto-generated
module,
but
this
makes
all
of
this
possible
and
also
includes
automatically
all
the
boilerplate
for
registering
all
the
different
messages
and
actor
can
handle.
A
So
not
so
nice
is
that
greeter
can
now
only
refer
exactly
to
Paris,
but
at
least
we
can
be
sure,
and
the
type
system
ensures
that
the
ID
which
we
sent
this
message
to
the
actor
behind
that
can
actually
handle
this
message.
But
this
wasn't
enough
for
me,
because
I
really
didn't
want
to
give
up
on
this
dynamic
dispatch.
So
I
made
the
build
script,
a
little
smarter
that
it
can
also
understand
crates.
So,
let's
define
instead
a
trade
word
here
with
our
greet
function
and
it
takes
a
bird
ID.
A
So
the
build
script
now
also
creates
generic
typed
IDs
for
actor
traits,
and
if
our
actor
implements
the
trait,
then
it
makes
sure
that
our
actor
ID
implements
into
the
trade
ID.
So
now,
I
can
pass
the
ID
of
the
parrot
converted
into
a
generic
bird
ID
and
at
the
same
time,
this
creature
is
a
bird
ID
and
I,
don't
know
which
exact
type
it
will
be,
but
I
know
for
sure
that
it's
an
implementer
of
bird-
and
it
will
understand
my
message,
so
it
could
also
be
a
human
implements.
A
So
now
we
have
typesafe
distributed
message
passing
in
what
I
would
call
a
dialect
of
rust,
that's
still
very
close
to
idiomatic
rust
I.
Don't
have
to
create
any
kind
of
structures
for
message:
I
just
write
struts
for
my
actors:
I
can
have
trades
and
I
have
functions
to
handle
messages
I
want
to.
In
the
end,
tell
you
a
couple
lessons
learned,
maybe
from
the
most
specific
to
the
most
generic
using
three
different
languages,
I
had
different
feelings
about
them
and
being
a
programmer.
A
I
will
present
my
feelings
to
you
as
a
matrix
of
unicode
symbols.
Look
at
this
information
density.
I
will
not
go
through
it
in
detail.
I
think
you
can
understand
this
one
pretty
well
and
here
different
aspects
of
the
programming
languages
and
I
want
to
highlight
one
in
particular,
which
is
really
important
for
me.
Prototyping
speed
or
iteration
speed,
where
of
course
nothing
beats
a
dynamic
language
and
rust
compiler
is
still
kind
of
slow,
but
it's
getting
better.
So,
let's
give
it
a
poker
face.
A
Yeah
in
general
consider
active
systems
as
a
solution
to
your
problem.
If
it's
distributed
or
parallel
in
any
kind,
it
can
be
surprisingly
clean,
no
matter
if
you
use
a
high-level
actor
system
with
lots
of
fancy
stuff
or
like
a
low-level
really
fast,
one
consider
meta
programming
and
domain
specific
languages
or
if
you
want
something
less
extreme
domain-specific
dialects
and
something
that
I
really
had
to
learn.
Working
on
a
big
codebase
like
this
is
that
you
should
think
about
coding,
not
just
in
space
but
in
time.
A
Don't
just
think,
like
you
realize
all
this
is
a
really
ugly
architecture,
and
then
you
invent
like
your
ideal
vision,
but
always
keep
in
mind
two
steps
in
between
and
be
ready
to
take
compromises
like,
okay
I
will
write
part
of
my
code
in
the
new
architecture,
but
if
the
new
architecture
is
completely
backwards,
compatible
to
the
old
one,
I
can
just
slowly
readily
do
this
until
everything
is
in
the
new
style
and
then
remove
all
the
superfluous
stuff
which
I
don't
need
anymore
I.
Did
this
a
couple
times
in
city
bound?
A
This
is
such
an
amazing
community
and
if
you
like,
the
cool
stuff
which
I'm
building
check
out
city
bound
open
source
on
github-
maybe
not
today,
but
tomorrow,
because
then
I
can
actually
update
the
documentation
to
what
I
quickly
implemented.
The
last
days
look
at
city
burns,
simcom
check
out
the
awesome
community
and
read
it,
and
if
you
like
city
building
games
at
all
shameless
plug,
consider
becoming
a
patron.
Thank
you
all
very
much
for
your
attention.