►
From YouTube: Taking Elixir to the Metal with Rust - Sonny Scroggin
Description
Elixir is a great choice for most applications. It's powered by the battle-tested Erlang VM know as the BEAM. It allows programmers to build incredibly fast, efficient, scalable, and fault-tolerant distributed systems.
As it turns out, Elixir isn't the fastest kid on the block. And while raw CPU speed matters little for most applications, there does exist a couple reasons you might want want to reach for tools that give you access to native power.
In this talk we're going to discuss Native Implemented Functions (NIFs) - Erlang's Foreign Function Interface (FFI).
NIFs are normally implemented in C and are considered dangerous. But we're going explore writing safer NIFs in Rust - a new systems programming language developed by Mozilla, that focuses on memory safety.
We'll talk about the pitfalls with writing NIFs and how Rust can make this process easier and safer.
NDC Conferences
https://ndc-london.com
https://ndcconferences.com
A
So
welcome
everyone.
Thank
you
so
much
for
joining
us
today.
This
is
a
talk
called
taking
elixir
to
the
metal
with
rust.
My
name
is
Sonny
Skagen,
an
elixir
developer,
also
erling
as
well.
Obviously,
but
I'm
really
excited
to
talk
today
about
this,
because
it's
been
something
there's
a
project
that
I've
been
working
on
to
kind
of
integrate
the
two
together
so
that
you
can
take
advantage
of
the
wonderful
things
that
each
of
these
languages
provide,
and
so
for
those
of
you
are
not
familiar
with
elixir.
A
It's
a
dynamic,
functional
language,
it
runs
on
the
Erlang
p.m.
and
it's
a
fascinating
language
because
of
the
fact
that
it's
got
this
Erlang
VM
and
it
has
been
around
for
thirty
years.
You
know
and
it's
been
known
for
building
scalable
fault,
tolerant
applications,
and
so
you
kind
of
have
this
holy
trinity
of
these
three
things
of
concurrency
fault,
tolerance
and
distribution,
that
our
length
provides.
A
That
kind
of
allows
you
to
build
systems
that
don't
go
down
and
if
processes
crash
and
things
like
that,
you
will
have
something
that
actually
restarts
these
things
and
and
allows
you
to
keep
your
systems
running
for
long
many
many
years
at
a
time.
So
but
one
thing
that
I
think
that
people
who
aren't
familiar
with
about
Erlang
is
that
it's
really
an
integration
platform.
And
earlier
this
this
week,
Brian
Hunter
was
speaking
about
Interop
between
f-sharp
and
elixir
and
and
how
the
Erlang
VM
really
provides
a
lot
of
ways
for
doing
that.
A
And
so
you
know
you
can
use
things
like
ports
which
are
essentially
like
pipes
where
you
talk
to
other
programs
via
standard
and
standard
out,
and
you
also
have
something
called
Earle
interface
and
Earle
interface
is
a
C
API
exposed
by
the
Erlang
VM.
That
allows
you
to
kind
of
talk
to
external
programs
with
erlangs
distribution
protocol,
and
that
opens
you
up
to
be
able
to
do
all
kinds
of
interesting
things
so
see.
Nodes
are
a
version
of
that
where
you
have
a
C
program
that
uses
url'
interface
and
so
from
the
Erlang
VM.
A
You
can
actually
talk
to
a
c
program
like
it
would
like
it's
actually
an
Earling,
node,
so
really
interesting,
stuff,
there's
also
stuff
like
port
drivers,
which
the
files
like.
If
you
want
need
to
talk
to
the
file
system.
It
goes
through
a
port
driver,
and
so
those
are
all
implemented
in
C,
so
they're
all
kind
of
native
functions.
They
have,
you
know
really
fast
execution
and
stuff
like
that,
and
then
we
also
have
native
implemented
functions
or
NIF's
for
short
and
those
simply
are
native
functions
that
you
can
call
so
some
integration
examples.
A
A
So
this
talk
is
going
to
focus
on
writing.
Nif's
and
knits
are,
as
I
said
before.
Native
implemented
functions
is
the
acronym
and
they
are
usually
implemented
in
C
or
C++,
and
obviously,
with
that
there's
a
lot
of
unsafe
things
that
can
happen,
and
so
it
is
a
feature
that
is
reserved
for
Wizards
people
who
know
what
they're
doing
and
are
going
to
to
not
do
you
know
things
like
null
point,
out-of-bounds
checks
and
stuff
like
that
and
crashed
crash,
your
VM.
A
A
If
you
write
an
if
that
crashes
or
causes
a
seg
fault,
you
will
crash
the
entire
Erlang
virtual
machine
and
then
obviously
is
a
big
problem
when
you
are
writing
fault,
tolerant
applications
who
you
can't
guarantee
fault
tolerance
anymore,
because
you
have
some
C
program
that
actually
takes
your
whole,
which
takes
your
whole
program
down
so
NIF's
they
can
be
called
just
like
any
other
Erlang
or
elixir
function.
So
you
have
a
module
that
has
functions
inside
of
it
and
anytime.
You
call
a
function
on
that
module.
A
That
is
an
if
then
it
gets
the
native
code
gets
executed,
and
so
NIF's
live
in
a
dynamically
loaded
library,
so
I
shared
object
or
a
DLL
for
Windows
I
think
is
what
that
is
usually
I'm,
not
familiar
with
Windows
stuff
so
but
NIF's
when
the
module
is
loaded
actually
ends
up,
replacing
the
bytecode.
That
would
normally
be
written
in
an
earlier
line
module
and
replaces
it
with
native
native
code,
so
the
NIF
functionality
itself
there's
an
API
that
allows
you
to
read
and
write
Erlang
terms.
You
can
have
there.
A
That
was
like
some
special
operations
for
doing
binaries.
There's
also,
these
things
called
resource
objects
that
we'll
talk
about,
and
it
also
has
some
functions
for
doing
threads
and
other
concurrency
features
so
to
get
started.
If
we
were
to
kind
of
create
something
like
a
JSON
module,
we
could
have
this
onload
module
attributes
when
Erlang
loads
is
load.
This
module.
A
It's
going
to
hit
this
attribute
here
and
it's
going
to
say,
hey
I,
want
you
to
call
the
init
function
when
I'm,
when
I'm
loading
when
you're
loading
me,
and
so
this
an
it
function,
is
now
going
to
find
the
path
to
our
dynamic
library
and
then
call
Erlang
load
NIF
with
the
dynamic
library.
And
then
these
are
the
functions
that
you
would
you'd
put
them
in
your
module
still
so
in
code
and
decode,
but
you
can
just
simply
throw
an
error
or
something
if
it
was
ever
to
be
called
in.
A
The
NIF
is
not
loaded
for
some
reason,
and
these
are
well
actually
are
the
functions
that
will
be
replaced
by
the
native
code.
So
why
would
you
write
an
if
they
seem
unsafe
right?
So,
but
really
you
know,
Erlang
was
not
designed
for
sheer
raw
CPU
speed.
It
was
done
designed
so
that
you
could
have
a
nice
consistent
run
time
where
everything
performed.
A
You
know
pretty
linearly.
If
the
more
processes
that
are
in
the
system,
you
can
understand
how
how
the
system's
going
to
perform
at
scale
a
lot
easier,
and
so
you
know
if
you
need
to
talk
directly
to
hardware,
there's
no
other
way
to
do
it,
then
to
use
kind
of
native
code.
If
you
have
like
you
need
to
interrupt
with
some
graphics
library.
A
You'd
want
to
do
that
in
some
native
code,
and
you
know
maybe
the
functionality
that
you
need
already
exists,
and
maybe
it
doesn't
already
exist
in
an
ER,
Lang
or
an
elixir
library,
but
it
exists
in
some
C
library,
and
you
just
want
to
use
that
functionality
because
rewriting
it
in
Erlang
would
be.
You
know
too
costly
or
whatnot.
So
so,
let's
take
a
look
at
the
structure
of
an
if
in
C
generally
you're
going
to
include
the
Earle
NIF
API.
So
all
that
from
the
header
file
and
all
nips
have
this
signature.
A
So
it
takes.
The
first
argument
is
a
pointer
to
an
illness
environment
type.
It's
got
an
integer
which
says
this
is
how
many
arguments
I
I
take,
and
then
you
have
an
array
of
of
NIF
terms
that
are
going
to
be
of
the
length
of
that
is
going
to
be
the
count
of
the
integer
of
the
arc
C
and
then
the
function
itself
just
needs
to
return
an
earnest
term.
A
So
this
NIF
environment
is
essentially
what
what,
when
you
call
an
if
this
NIF
environment
is
a
it's
essentially
the
like
the
environment
of
the
calling
process,
and
so
it
represents
the
the
calling
process
itself.
It's
got
some
transient
information
that
you
would
never
really
interact
with
itself,
but
it's
it's
an
opaque
type
and
it
allows
you
to
essentially
create
terms
and
decode
and
encode
and
stuff
using
this
environment
and
the
erlan.
A
A
Is
it
a
boolean,
you
can
have
just
different
functions
that
will
test
those
things
and
such
like
that
and
there's
one
thing:
that's
interesting
too,
when
you
read
the
documentation,
the
documentation
actually
talks
clearly
about
the
lifetime
of
terms
and
an
environment,
so
terms
cannot
live
longer
than
an
environment
that
they're
that
they're
bound
to
and
we'll
see
how
that
plays
out
in
rust
later
so
the
next
thing
in
an,
if
is
you're
going
to
say,
hey.
These
are
the
functions
that
I
export
and
you
provide
this.
A
If
you're
not
familiar
when
you
create
a
module
in
elixir,
even
though
I
created
a
JSON
module
called
JSON
when
it
actually
compiles
into
the
beam
code,
that
module
name
is
elixir
dot
JSON.
So
that's
why
we
have
that
there
alright.
So
but
I
don't
know
about
you,
but
I
am
NOT
a
C
programmer
I,
don't
know
how
to
do
any
of
C
programs.
A
I
would
not
trust
myself
if
my
life
depended
on
it
to
write
a
safe
C
program,
but
rust
is
here
and
promises
a
lot
of
great
things
to
help
us
along
the
compiler
is
absolutely
amazing.
It
essentially
will
not
let
you
write
a
program
that
will
cause
dangling
pointers
or
you
know
unbound
checks
and
things
like
that,
and
so
it's
really
fast
and
it
keeps
you
safe.
So
it
causes
the
compiler.
Will
not
let
you
compile
a
broken
program.
A
A
So
this
project
is
really
really
fun
and
it's
now
allowing
us
to
to
build
niffs
in
rust,
which
is
nice
so
Ressler
itself
is,
you
know,
obviously
a
library
for
writing
rolling
this
in
rust,
but
it
provides
facilities
for
generating
boilerplate
and
things
like
that.
That
makes
it
nice
to
to
get
up
and
running
and
get
started
really
quickly.
So
it
handles
encoding
and
decoding
terms
from
from
Erlang
terms
to
rust
types
and
rust
types
back
into
Erlang,
with
just
a
simple
function,
call
which
is
really
nice.
A
It
catches
any
rust
panics
that
might
happen
for
unhandled
things
where
you
actually
say
in
the
code
that
I
don't
know
what
to
do
here.
So
I'm
just
going
to
panic.
If
you
do
panic
in
your
in
your
Russ
code,
it
will
catch
those
before
it
unwinds
back
into
C,
causing
a
seg
fault
and
blowing
up
to
the
M.
And
so
the
goal
really
is.
Is
that
the
the
code
that
you
write
in
a
rust
NIF
should
never
crash
the
Erlang
VM
so
to
get
started?
A
You
just
simply
create
a
new
elixir
project
with
mix
so
mix
new,
and
then
your
project
name,
you
install
or
you
add,
the
rustler
dependency
right
now
this
is
going
to
be
the
next
version.
That's
that's
published
0.12,
but
for
now
what
you
can
do
is
you
can
use
master.
You
can
just
pass
in
github
and
the
kind
of
user
name
and
repository
there
and
then
because
this
project
in
has
both
the
rust
code
and
the
elixir
code,
all
in
one
repo.
A
You
can
use
this
parse
option
to
specify
the
path
to
the
to
the
actual
directory
where
the
elixir
project
is
so,
then
you
affect
your
dependencies
mix,
a
depth
socket
and
then
Ruster
provides
this
Rustler
new
tasks
and
it'll
just
kind
of
prompt
you
through,
like
hey.
What's
the
name
of
the
module
and
what
is
the
name
of
your
rust
library
that
you
want
to
create?
A
A
The
rust
rustler
compiler
essentially
is
a
compiler,
that's
written
in
in
elixir
that
keeps
track
of
where
the
files
should
go
and
invokes
the
the
rust
compiler
with
the
right
flags,
and
things
like
that,
so
which
is
nice,
and
then
we
just
set
up
this
option
here
for
called
rustic
crates,
which
we
call
this
function
here,
and
this
function
just
sets
up
some
configuration
for
the
crates
themselves
and
that's
what
you
call
a
rust
library.
They
call
it
a
crate.
A
So
this
just
shows
you
know
the
path
and
also
the
mode
in
which
we
want
to
invoke
the
rust
compiler.
So
if
we're
running
in
the
like
dev
mode
in
a
lick,
sir,
we'll
probably
just
want
to
compile
the
rust
code
with
the
debug
mode
so
that
it's
a
faster
compile
time.
But
if
we're
running
in
production,
we
want
to
release
it
with
the
release
mode
so
that
it's
better
optimized
and
and
all
that
stuff,
but
it
the
compiling
step,
is
takes
a
little
bit
longer.
A
So
if
we
go
back
to
our
code,
this
is
what
we
had
before
and
with
Ressler.
It
becomes
this
here.
So
you
just
say:
use
rustler,
give
it
the
name
of
your
location
and
then
it
can
go
ahead
and
find
the
crate
that
you
intend
to
use.
You
could
also,
with
with
a
project,
have
multiple
crates
within
your
project,
and
so
in
that
case
you
can
also
specify
a
crate
name
that
you
want
to
use
and
it
will
go
ahead
and
find
that.
So
you
know
we
go
from
this
to
to
this
so
much
nicer.
A
Alright.
So
let's
take
a
look
at
some
Russ
code,
so
the
main
files
live
RS
and
in
here
we're
just
using
extern,
hey
I'm,
going
to
use
an
external
library,
so
we're
calling
rustler
and
another
one
called
lazy
static,
which
is
for
like
creating
our
atoms
and
stuff
like
that
and
right
here,
we're
using
also
the
JSON
crate,
which
is
an
external
crates
from
from
the
Russ
community
that
does
JSON,
parsing
and
and
stuff
like
that.
So
right
here
we're
just
taking
advantage
of
a
library
that
already
exists.
A
I,
don't
have
to
go
and
write
a
JSON
parser,
which
is
nice
right
here.
We
have
a
couple
of
other
modules
in
our
project,
so
the
decoder
for
calling
the
decoding,
and
then
we
just
export.
So
we
have
this
macro
called
Wrestler
export
niffs
and
you
provide
the
name
of
the
module.
You
provide
the
kind
of
exports
themselves
very
similar
to
the
the
scene.
A
If
so,
we
have
the
function
in
the
module
for
your
Earling
module
or
elixir
module,
you
have
the
arity,
and
then
you
have
the
rust
function
that
you're
going
to
call,
and
then
this
nun
down
here.
That
is,
if
you
have
additional
things
that
you
need
to
do
when
the
NIF
is
loaded,
you
can
do
it
in
another
function
and
you
can
provide
so
this
nun
if
you're
not
familiar,
is
kind
of
a
monadic
type,
where
it's
it's
an
option
type.
So
it
has
it's
either
something
or
it's
nothing.
A
So
this
in
this
case
it's
nothing,
but
if
it
was,
if
we
did
want
to
provide
a
function,
we
could
just
call
some
and
then
passing
the
function
that
we
want
to
call
and
I
will
see.
The
example
later
on
that
that
so
the
simple
approach
or
the
naive
approach,
is
simply
just
use
existing
rust
jsonparser
that
we
don't
have
to
do
any
extra
work.
A
You
know
we're
going
to
take
in
a
string
or
binary
from
from
Erlang
side
and
we'll
convert
that
into
rust
types
and
then
we'll
convert
the
rust
types
back
into
Erlang
terms.
So
this
is
the
decoder
and
all
NIST
NIF
terms.
This
is
the
the
decode
function.
Here
is
the
this
is
the
signature
here,
so
it
takes
the
environment
right
here.
It
also
takes
a
vector
of
NIF
terms
as
arguments,
and
then
it
returns
what's
called
an
if
result,
which
of
NIF
terms
and
you'll,
see
these
tick
a
things
in
there.
A
Something
can
outlast
the
other
thing,
and
so
all
of
these
things
are
kind
of
bound
to
the
same
lifetime
across
the
board.
So
alright,
so
the
next
thing
is
we
just
grabbed
out
the
first
argument
from
the
vector,
so
we
can
say
args,
0,
dot,
decode
and
that
will
return
us
the
actual
binary
itself.
And
then
we
can
use
pattern
matching
when
we're
calling
this
json.parse
function,
we
pass
in
the
data
and
then
we
will
either
get
so.
It
returns
a
result.
A
A
So,
let's
time
our
NIF.
So
if
you
get,
if
you,
if
you
run
this
on,
like
really
small
inputs,
it's
going
to
be
fast
and
it's
going
to
be
performant
and
nice.
But
when
you
get
some
like
big
data,
you
know
you
have
some
big
JSON
file.
This
one
here
is
like
eight
megabytes
and
you
run
it
and
you
time
it.
A
Then
we
get
something
like
this,
which
is
really
bad
because
it
it
actually
only
it
took
almost
1.5
seconds
so
1.5
seconds
of
CPU,
of
blocking
the
CPU
blocking
the
scheduler
in
Erlang
is
a
bad
thing.
But
why
is
that?
So?
In
order
to
really
understand
why
that's
bad?
Let's
take
a
look
at
the
warnings,
a
little
closer
that
you
get
here.
So
a
native
function
doing
new
lengthly
work.
A
It
doesn't
really
specify
which,
how
long
that
is,
but
before
before
returning
degrades
the
responsiveness
of
the
VM
and
it
can
cause
miscellaneous
strange
behaviors.
This
is
actually
verbatim
out
of
the
out
of
the
docs.
So
such
strange
behaviors
include
but
are
not
limited
to
extreme
memory
usage
and
bad
load
balancing
between
schedulers.
A
A
It
gives
each
process
what
are
called
reductions
and
you
get
2,000
reductions
and
then
you're
talking
stick
is
taken
away
until
the
next
time
you're
scheduled
so
and
this
essentially,
a
reduction
is
roughly
equivalent
to
a
function.
Call
it's
not
exact
oops,
so
one
thing
that's
interesting
is
that
the
schedulers
actually
use
this
thing
called
thread
progress
and
there's
a
really
interesting
article
or
markdown
document
in
the
the
Erlang
repo
that
you
can
read
here
and
and
thread.
Progress
is
quite
an
interesting
thing.
Instead
of
using.
A
You
know
that,
while
the
schedulers
themselves,
they
share
some
data
structures,
and
so
when
you
have
shared
data,
you
have
you
know
definite
problems
of
race
conditions
and
corrupting
memory,
and
things
like
that.
So,
instead
of
protecting
them
with
locks
or
ref
counts,
which
don't
scale
very
well,
instead,
they
actually
frequently
kind
of
give
a
progress
report
out
to
all
of
the
different
schedulers.
A
And
so
what
that
does
is
it
allows
the
schedulers
to
understand
what
work
has
been
done,
what
data
structures
are
still
being
used
and
when
it's
okay
and
when
it's
safe
to
actually
like
get
rid
of
stuff?
And
so,
if
you
block
the
scheduler,
that's
really
really
bad.
Because
now
you
block
thread
progress
and
it
makes
all
of
the
other
schedulers
wait.
So
if
you
block
even
just
one
scheduler,
you
can
now
cause
the
other
schedulers
to
have
to
wait
around
to
ensure
that
memory
safety
is
happening
within
the
VM
and
also
the
another.
A
Big
problem
is
that
if
you
block
scheduler
all
the
other
processes
that
are
in
that
same
scheduler
can't
run
so
an
if
should
never
take
longer
should
never
block
the
scheduler.
For
for
more
than
one
millisecond
is
what
the
documentation
says
now,
one
millisecond
in
CPU
time
is
like
an
eternity,
so
even
that
feels
really
really
long.
So
so,
when
you're
writing
this,
you
should
also
count
reductions
and
there's
a
way
to
do
that,
but
a
lot
of
people
don't
actually
do
it
because
it's
been
introduced
quite
recently.
A
So
so
one
way
we
can
count
reductions
in
our
in
our
code.
Just
to
like
test
to
see
how
our
NIF
is
performing.
We
can
write
this
function
here.
We
just
basically
send
send
ourself
a
message
in
the
end.
We
we
get
our
start
time.
We
calculate
we
prop
were
responding
a
new
process
to
actually
run
run
the
calculation
or
run
run
the
computation,
and
we
get
the
reductions,
the
starting
reductions
for
that
process.
We
run
the
function
with
the
data
we
get
a
time
difference.
A
We
get
the
reductions
afterwards
after
running
it,
and
then
we
send
the
parent
process
a
message
that
just
basically
shows
us
the
time
and
and
and
all
that
data
there
so
and
then
we
just
wait
for
the
message
there.
The
actual
result
here
so
when
we
do
this
with
our
big
data,
we
can
see
it
took
two
seconds
we
started
at
six
reductions.
A
You
can
keep
kind
of
chunking
it
and
calling
it
recursively,
and
then
that
way,
when
you
are
returning
on
the
erlang
side,
the
Erlang
scheduler
now
can
preempt
the
process
in
the
middle
of
what
it's
doing
and
then
you
get
kind
of
much
more
better
behavior
out
of
it.
So
in
order
to
do
that,
though,
we
can't
use
that
JSON
crate.
So
we
have
to
actually
do
some
work.
A
We
have
to
build
a
parser,
so
so
this
this
way
here
we're
going
to
have
to
do
is
we're
going
to
have
to
NIF's
we're
going
to
have
to
one
that
initializes
and
then
and
then
calls
the
second
one
and
then
can
allow
us
to
actually
call
this
this
iterative
NIF
over
and
over
and
over
again.
So
what
we
do
here
is
we
have
our
decode
in
it
and
decode
it
err
and
right
here
in
decode.
A
So
this
is
going
to
require
us
to
learn
about
something
else,
though,
which
is
pretty
cool.
It's
called
an
if
resource
object
and
resource
objects
are
essentially
like
a
safe
pointer,
and
so
it's
a
safe
way
to
return
pointers
to
native
data
structures
within
rust
or
or
C
or
whatever
from
anis,
and
it
can
be
stored.
It
can
be
passed
around
to
any.
It
can
actually
be
passed
from
process
to
process.
It
can
be
passed
and
shared
amongst
processes.
A
A
We
do
the
same
thing
as
before.
We
get
the
source
we
create
this
resource,
and
this
I
wish
rust
had
the
pipe
operator
that
would
be
really
cool.
Because
then
you
could
write
this
much
much
nicer,
so
reading
it
inside
out
we're
creating
a
new
parser
from
the
source,
wrapping
that
in
the
mutex
putting
that
into
the
parser
resource.
Struct
and
then
we're
creating
this
resource
self
that
comes
from
rustler,
and
then
we
create
a
new
empty
vector
and
we
send
it
in
to
decode
it
err,
which
is
that
which
is
another
miss.
A
A
So
we
create
this
sink
so
that
we
can
stick
our
terms
in.
We
have
to
get
a
lock
on
the
mutex
for
the
for
the
parser,
and
then
we
use
this
thing
called
consume
time
slice
so
consume
time.
Slice
allows
us
to
report
reductions
kind
of
to
the
to
the
VM.
Every
time
we
call
it.
The
is
going
to
tell
us
whether
or
not
we're
up
like
our
times
up.
A
So
if
it
returns
false,
then
it
will
go
in
and
it
will
actually
parse
it'll
do
some
work,
so
it'll
call
parts
on
the
parser
and
if
it
returns,
ok
true,
then
we
return
the
results
of
the
end
of
it.
If
it
returns
false.
That
means
it's
not
done.
Parsing,
there's
still
more
stuff
to
do
so,
return
continue
and
then,
if
there's
an
error
return
the
error.
If
we
end
up
getting
we're
consumed
time,
slice
returns.
True.
That
means
your
time
is
up.
You're
done.
A
A
So
the
result
of
this
is
much
different
oops.
So
we
now
have
a
diff
here
where
we
actually
are
doing
11300
reductions,
which
is
much
much
better.
We
didn't
block
the
scheduler
and
what
probably
didn't
block
scheduler,
but
this
is
definitely
much
more
on
track.
It
still
took
a
long
time,
but
we
were
a
good
citizen
of
the
beam
which
is
nice,
so
there's
also
a
way
that
you
can
do
what's
called
rescheduling
or
yet
they
called
yielding
and
there's
a
function
in
the
NIF.
A
Api
called
eNOS
schedule
NIF,
but-
and
you
can,
if
you
were
to
combine
it
with
the
consume
time
slice
it
allows
you
to.
Instead
of
having
to
return
back
to
Erlang
or
or
elixir,
you
can
simply
just
reschedule
another
niffle
internally.
So
instead
of
chunking
from
the
outside,
where
you
have
to
call
the
NIF
from
Erlang
over
and
over
again,
you
can
actually
do
that
within
the
nests
and
have
the
NIF
rescheduled
likewise.
A
So,
unfortunately,
right
now
it's
not
available
in
rustler
and
simply
because
it's
unsafe
to
do
so
right
now,
one
of
the
goals
of
Rustler
is
to
make
sure
that
you
can't
do
things
that
are
unsafe
and
cause
crashes
and
cause
bad
things
to
happen.
And
so
until
we
can
find
a
way
to
support
this
in
rustler,
we've
got
to
kind
of
do
some
other
stuff,
but
I'm
sure
eventually
we'll
be
able
to
get
it
in.
A
A
We
call
this
thread
spawn
from
the
rustler
crate,
and
it
takes
this.
This
trait
called
a
thread
spawner
you
pass
in
the
caller.
So
if
you
notice
up
at
the
top
the
NIF
environment,
I've,
it's
still
an
if
environment,
but
I've
named
it
caller
to
specify
just
so
that
we
have,
because
we
also
have
an
invariable,
that's
passed
into
this
closure
over
here
and
so
to
keep
the
two
kind
of
distinct
I
use
the
caller
as
the
variable.
A
So
this
passes
in
the
caller
and
the
caller
is
an
environment
for
the
calling
process
and
we
can
just
get
the
pid'
or
the
process.
Id
of
the
calling
process
so
that
we
can
actually
send
a
message
to
it
from
what's
returned
in
in
our
value
here,
so
we
can
just
call
json.parse
on
that.
We
get
the
value,
that's
returned
there
and
in
internally,
underneath
it's
going
to
send
that
value
to
the
process
directly
and
then
here
we're
just
returning
immediately
after
this
thread
spawned.
So
we
returned
back
to
the
caller.
A
Just
an
okay
tuple
to
say:
okay,
I
did
the
the
thing.
Now
you
can
go
ahead
and
wait,
and
this
would
be
the
elixir
code
that
you
would
write
in
order
to
do
that.
So
you'd
have
your
decode,
you
would
have
you'd
call
decode
threaded
and
then
you
would
just
wait
in
a
receive
block
for
the
result.
If
you
get
okay
results
and
you're
good,
you
return
that
if
you
can
narrow
return
that
and
if
it
if
it
takes
like
longer
than
five
seconds,
then
just
throw
a
timeout
or
something.
A
All
right,
so
another
option
is
call
is,
is
dirtiness
and
dirty.
Nif's
are
a
way
to
basically
never
block
the
normal
schedulers,
because
you
can
actually
compile
Erlang
with
this
enable
dirty
schedulers
option.
It's
currently
an
experimental
feature,
but
they
are
working
on
it
with
Erlang
OTP
20
version
20,
and
it
should
be
pretty
much
stable
by
then
I
think
they're
going
to
try
and
make
it
stable,
so
it'll
it'll
just
be
there.
A
You
won't
have
to
compile
it
specially,
which
is
nice,
but
essentially
it
allows
you
to
call
NIF's
without
worrying
about
blocking
the
normal
schedulers,
because
in
addition
to
the,
if
you
have
an
eight-core
machine
as
an
example
I
had
if
you
have
an
eight-core
machine
and
then
you,
if
you
have
dirty
schedulers
enabled
now
you
have
eight
more
threads
that
are
completely
separate
from
the
normal
way
of
scheduling
processes.
So
normal
processes
are
just
not
even
scheduled
on
dirty
schedulers.
A
A
A
One
is
the
creator
of
Rustler
Hans,
Josephson
and
also
Jason
Orndorff
who's,
a
good
friend
of
mine
and
he's
been
mentoring.
Me
and
rusts
he's
actually
currently
writing
the
O'reilly
rust
book
co-authoring
for
that
and
he's
just
an
amazing
guy.
Both
of
these
guys
have
been
really
really
helpful
in
this
process
and
I'm
really
excited
about
what
we've
been
doing,
and
so
with
that
I'm
done.
Thank
you.
C
So
I'll
ask
you
I'll:
ask
you
later
about
the
safety
concerns
with
the
yields,
because
I'm
curious
about
that
by
I,
suppose
that's
longer,
but
a
shorter
question
was:
do
you
get
into
any
sort
of
interesting
troubles
where
the
fact
that
in
Erlang,
when
you
have
the
reference
to
safe
references,
they
can
be
sort
of
copied
around
and
stuff?
Does
it
interrupt
in
any
funny
way
with
the
with
the
rust
sort
of
ownership
checking
or
does
it
what
caused
any
troubles
there?
So.
A
The
the
resource
itself
is
is
stored
in
such
a
way
that
the
lifetimes
it's
not
dependent
on
the
lifetimes,
and
so
it
can
essentially
be
a
data
structure.
That's
in
memory!
That's
actually
in
the
VM,
that's
that's
there,
and
so
the
Erlang
VM
will
keep
keep
a
hold
of
it
inside
until
there's
no
more,
nothing
else,
actually
using
it
and
they'll
just
get
D
out
D
allocated.
So
that
answer
your
question.
Okay,
cool.