►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Thank
you
everyone.
So
this
was
a
very
impromptu
talk,
as
you
know,
Emperor
as
it
could
be
like
it
was
like
an
hour
before
that
I
said
to
Bastian.
Maybe
I
can
do
a
talk,
because
our
regular,
the
the
scheduled
presenter
was
not
feeling
well
so
yeah.
You
have
to
do.
Let
me
it's
not
a
great
talk
as
I
said
impromptu
and
expect,
spelling
mistakes
and
other
mistakes
so
yeah,
that's
fine!
A
First
of
all,
who
am
I
I,
don't
see
my
slider,
so
I'll
have
to
keep
doing
this
for
your
entertainment.
Well,
my
name
is
ishan
Ali
and
hopefully
soon
I'll
be
have
a
new
cool
cooler.
Last
name,
which
is
my
actual
last
name,
there's
a
whole
new
story.
I
can
do
another
talk
about
why
it's
not
on
documents
but
suffices
to
say
is
my
father
didn't
put
it
in
the
documents
for
some
reasons.
B
A
Anyway,
I
I
submitted
the
application
actually
today
to
change
my
name
to
what
it's
supposed
to
be
because
I'm
expecting
a
son
and
I
want
my
son
to
have
the
proper
last
name
and
also
in
Germany.
You
can
get
in
a
lot
of
trouble
if
you
have
a
last
name
is
Ali,
because
many
Germans
refuse
to
accept
that
as
your
name
and
they
say
it
can't
be
your
last
name.
You
must
be
wrong,
so
they
correct
it
for
you
and
you
get
into
a
lot
of
fun
trouble.
A
So
I
don't
want
him
to
go
through
the
same
yes
and
I've
been
to
have
lived
in
many
countries
and
I'm
a
bit
of
a
nomad,
but
I've
been
here
for
five
years
now
and
let's
see
maybe
I'll
stay
here
for
long
and
yeah,
just
another
software
engineer
and
I've
been
into
Falls
for
a
very
long
time
and
did
work
on
many
levels
of
false,
well
Linux
operating
system
and
engine
and
I'm
into
flying.
A
If
you
want
to
overfly
with
me,
let
me
know
if
I
can
I
can
take
you
for
a
ride
about
Berlin.
It's
really
cool
and
I
have
I'm
a
the
Creator
and
maintainer
of
zebus,
and
all
the
rest
I
know
is
because
of
this
project.
I
went
through
a
lot
of
like
it.
Somehow
this
project
ended
up
touching
all
the
aspects,
almost
all
the
aspects
of
rust
and
it
really
tested
the
rust
language
and
my
patients
in
turn.
A
So
I
learned
a
lot
with
it
because
of
that
and
yeah
it's
like,
as
I
said,
it's
an
improper
call,
a
talk,
so
I
just
thought
like
our
base
it
on
something
that
I
can
already
find
and
I
knew
of
this
something
about
the
misconceptions
like
a
blog
post
from
from
Carol
and
yeah.
It's
based
on
that
some
of
it
so
just
wanted
to
give
the
credit.
A
So,
let's
get
to
it
so
first,
starting
with
some
misconceptions
like
just
two
and
first
of
all,
it's
like
this.
This
thing
right
like
when
you
are
looking
at
an
API,
a
public
API,
especially-
and
it
says
this
thing-
T
requires
type
T
is
being
a
generic
type
and
it
requires
a
static
lifetime.
A
Everyone
starts
thinking,
especially
the
beginners,
that
oh
no,
this
requires
that
the
type
to
be
the
actual
type
that
will
you
will
pass
to
that
function
or
whatever
it
is
to
be
where
to
be
around
the
instance
to
be
around
for
the
entirety
of
the
whole
program
right,
but
that's
not
true.
A
It's
more
usually
the
static
lifetime
requirements
just
means
that
it
has
to
be
around
long
enough
to
outlive
or
have
the
same
lifetime
as
all
the
other
lifetimes
in
that
context,
so
it
cannot
be
like
it
cannot
go
away
like
the
thing
you're
passing.
It
cannot
go
away
before
all
the
other
things
around
I'm
being
wig
but
yeah.
A
If
you,
if
you
play
with
lifetimes
a
bit,
then
you
will
realize
what
I'm
talking
about
so
I'm,
sorry
for
the
beginners
here,
and
so
that's
there's
an
example
right
and
this
function
is
just
generating
a
random
string.
Basically,
and
that
is
saying,
like
I'm
returning
a
static
string,
but
that
string
would
not
necessarily
be
around
it
could
be
around
for
the
entirety
of
the
lifetime.
It
depends
really
on
the
caller.
They
can
keep
it
around
forever
and
it
they
can.
A
You
know,
call
it
in
the
from
the
beginning
of
the
program
and
keep
it
till
the
end
of
the
main
function,
but
they
don't
have
to,
and
the
reason
is
that
it
doesn't
have
to
be
kept
around
and
it
it
just.
It
just
means
that
that
their
lifetime
is
not
dependent
on
any
of
them
in
in
here,
I'm,
not
sure.
A
It's
a
very
good
example,
because
there
is
no
input
parameters
to
this
one,
but
if
there
were
any
the
return
value
would
not
depend
on
the
lifetime
of
the
input
values,
for
example,
if
it
was
taking
a
string
reference
here,
so
it
just
just
means
that
so
that's
the
base.
This
is
a
basic
conception,
especially
between
beginners
I'm,
talking
of
lifetimes
many
people
think
like
they
have
been
programming
for
for
a
month
or
so
and
they're
like
okay.
A
My
program
doesn't
have
lifetimes
and
that's
why
I'm
not
in
getting
into
trouble
and
maybe
I
can
just
keep
programming
like
this
and
I
will
never
have
to
deal
with
lifetimes
ever
I'm.
Sorry,
but
that's
wrong.
You
will
have
to
deal
with
lifetimes
at
some
point,
and
the
reason
you
have
so
far
not
dealt
with
lifetimes
is
because
you
have
been
lucky
and
or
you
have
done
only
simple
stuff,
because
there
are
always
lifetimes.
A
If
you
have
a
reference,
especially
around
for
anything
and
SDR
being
the
most
common
example,
you
will,
it
has
a
lifetime.
It's
just
that
rust.
Compiler
is
trying
to
be
helpful
and
it's
Allied.
It
aligns
lifetimes
when
it
can
for
you,
so
you
don't
have
to
specify
it
or
you
don't
even
have
to
see
it.
A
So
this
is
an
example
for
for
in
here,
like
you
have
a
function
that
just
takes
a
string,
probably
prints
it
and
in
reality
there
is
a
lifetime
and
the
compiler
would
do
something
like
that
for
you
and
it
expands
it
for
you
and
it's
similarly.
In
the
second
example,
it's
like
take,
it
takes
a
string,
gives
a
string
and
they
have
they're
supposed
to
have
the
same
Lifetime
and
that's
assumed
when
you,
you
know,
have
input
and
output,
and
it's
assumed
that
the
lifetimes
are
are
the
same.
So.
B
A
It
depends
on
on
case
to
case,
but
usually
it's
it's
a
fair
assumption
by
the
compiler
and
and
you
will
get
an
error
usually
when,
when
that
happens,
that
the
lifetimes
are
not
correlated
and
compiler
assumes
that
so
you'll
get
an
error,
and
then
you
have
to
specify
the
lifetimes
specifically
that
yeah,
it's
not
related
now
the
interesting
part
that
I
wanted
to
talk
about
and
because
of
which
I
I
thought
I
should
do
this
talk
and
that's
like
cows,
I
love,
cows,
the
real
cows
and
I
love.
A
Also,
the
cows
in
in
Rust
and
many
people
when
they
look
at
cow,
also
like
the
documentation,
doesn't
do
justice.
So
it's
like
it
says
copy
on
on
right,
which
is
correct.
A
It
is
a
type
that
implements
copy
and
write,
but
it's
it's
so
much
more
than
that
and
it's
so
so
cool
and
it
helps
you
so
much
it's
more
awesome
than
you
think.
Right.
So,
let's
say
this:
this
function
right.
It
takes
a
string
again
and
it's
a
texture
by
reference,
which
is
it's
it's
it's
it's
it's
the
it's
really
good.
It's
like
you
cannot
do
it
better.
A
You
don't
need
to
keep
the
ownership.
You
don't
need
to
take
the
string
by
ownership
by
value.
So
you
just
say:
okay,
just
give
me
a
reference
to
a
string,
I'll
just
print
it
and
that's
the
end
of
the
story
right.
You
don't
need
to
keep
the
string
around
or
anything,
and
this
is
perfect.
However,
what
if
you
need
to
keep
the
string
around?
What
what
do
you
do?
Then?
A
You
can
still
do
it,
you
let's
say
we
have
a
type,
keep
Str
and
it
keeps
a
string
and
you
it
has
a
Constructor,
it's
a
new
function
and
it
you
just
take
the
string.
It
has
a
lifetime,
a
string
reference
actually
and
then
you
keep
it
around,
and
then
you
return
that.
But
if
you,
if
you
use
that
as
a
you
know,
let's
say
this
method
is
provided
by
library
and
you
are
the
user
and
you're
dealing
with
you
know
you
want
to
keep
the
keepest.
A
You
want
to
keep
keep
SDR
around
and
you
want
to
pass
it
around
and
when
you
create
it,
you
pass
it
a
string
right,
a
reference,
and
now
the
lifetime
of
keep
Str
is
associated
with
the
lifetime
of
the
string
that
you
pass
to
create
it.
And
what,
if
you
don't
want
to
keep
that
string
around
you
just
want
to
keep
keep
Str?
What
do
you
do
then?
A
So
you're
in
trouble
and
a
lot
of
people,
especially
in
the
beginning,
and
it's
it's
valid
in
in
some
ways,
but
I'll
talk
about
limitation
later
and
you
say
yeah
keep
it
can't
outlive.
So
why
don't
you
use
string,
which
is
valid
and
I
use
it
all
the
time
as
all,
and
it
would
be
something
like
this.
It's
it's
it's
fine!
It's
it
the
string!
You
passed,
it
took
its
value
and
it
kept
it
and
keep
pstr
and
gave
it
back
to
you
now.
A
The
keep
Str
doesn't
have
a
lifetimes
associated
with
anything
else.
It's
it's
completely
independent.
You
can
actually
this.
This
has
static
static
lifetime.
Now,
although
that
you
don't
have
to
specify
a
lifetime
anywhere,
but
this
is
a
example
of
aesthetic
lifetime
problem
solved,
most
definitely
the
problem
that
we're
going
to
solve
that
is
solved.
But
now
you
are
forcing
your
caller,
your
user,
to
your
forcing
allocation
you're,
forcing
also
possibly
cloning.
A
What
if
your
type
needs
to
clone
and
keep
it
keep
the
string
in
another
place,
then
you
are
you're
just
forcing
it
on
on
the
caller
right,
but
what
if
the
caller,
doesn't
really
want
that
and
they're?
Okay,
with
the
first
case
that
I
showed
they
were
like
yeah,
why
don't
you
just
take
a
reference
and
I
will
just
assign
it?
You
know
static,
strings
or
whatever,
and
it
will
be
all
fine
and
I
don't
have
to
do
any
allocation
or
or
cloning
whatsoever.
So
how
do
we?
How
do
we
achieve
this?
A
And
can
we
have
both?
Yes,
it's
that's
where
the
cow
gets
it.
It
comes
comes
in
it's
a
cow
to
the
rescue,
and
how
does
that
work?
A
Wait
there
you
go
so
instead
of
reference,
keeping
the
reference
directly
in
your
type,
you
keep
a
cow
with
the
type
you
specify
the
type
of
the
borrowed
thing.
A
Whatever
you
want
to
keep
and
and
lifetime,
you
just
give
it
a
lifetime,
and
it
might
look
like
what's
the
difference
between
like
we
might
ask,
what's
the
difference
between
the
first
example,
I
showed
right,
which
was
taking
a
reference
and
keeping
a
reference
that
the
difference
being
is
that
you
can
now
give
it.
You
can
now
create
a
cow
from
string
like
a
capital,
S
string
like
a
allocated
string,
and
you
can
pass
it
that
and
then
the
keepest
here
will
have
the
the
S
lifetime.
A
It
will
become
Static
lifetime
in
that
case,
so
you
can
use
it
just
like
you,
you
use
the
previous
example
right
very
low.
There's
many
slides
between
like
this,
you
can
keep.
You
can
use
it
exactly
like
this.
You
just
have
to
create,
say,
cow
colon,
colon
from
and
then
give
it
the
string
that
you
were
going
to
pass
and
that's
it
where
we
go
there,
we
go
yeah.
And
how
do
you
use
it
like
this
cow
new?
A
You?
You
can
pass
it
string
reference
or
or
like
a
string,
I
look
at
a
string,
but
you
just
have
to
do
color
from
and
and
that's
it
and
now
you
you
can
have
both
and
you
don't
force
your
caller
or
the
user
to
have
allocation
or
cloning
or
anything,
and
they
can
use
whichever
kind
of
string
they
want.
A
We
can
use
generics
to
our
rescue
and
and
then
it
makes
it
even
better
for
for
your
caller,
like
it
gets
a
bit
yeah,
you
know
the
it's,
not
it's,
not
so
friendly,
looking
at
the
function
anymore
for
at
least
for
beginners,
but
once
you
have
gone
through
a
lot
of
rust
apis
trust
me.
This
is
very
normal,
so
and-
and
you
just
say
that
any
give
me
anything
that
I
can
convert
into
a
cow
Str
and
then
the
color
doesn't
need
to
deal
with
cows
at
all.
A
They
can
just
pass
directly
a
string
reference
or
or
allocated
string,
and
that's
it
and
it's
it's
not
limited
to
Strings.
Only
this
the
examples
I
showed
like
commonly
used
for
Strings,
but
it
could
be
any
type
or
any
reference
type
that
implements
two-owned
trait,
and
then
you
can
use
it
with
that,
because
when
you
it's
a
as
a
name
of
the
type
says
copy
and
write.
A
So
when
you
do,
you
know
clone
it
will
have
to
allocate,
it
will
have
to
to
own
it,
and
then
it
calls
200
and
then
it
it
becomes
yeah
it.
It
has
to.
It
needs
that
straight
in
essence,
but
like
I
mentioned
like
this
tree,
this
crate
that
I
wrote
zbus
part
of
that
is
called
Z
variant,
which
is
the
encoding
with
like
the
lower
level
part
of
it.
A
But
it's
available
as
a
separate
crate
and
that
one
has
a
type
called
SDR
and,
as
I
said,
like
cow
is
very
generic,
so
it
can
take
any
type
that
implements
to
Owned,
but
this
type
is
specific
to
Strings.
So
since
it's
specific
to
Strings,
we
it's
even
better,
because
it's
if
you
give
it
a
static
string,
if
you
create
it
with
a
static
string,
type
string
literal
as
it's
called,
then
it
even
when
you
say
two
owned
it
will
not
clone.
It
will
keep
the
original
reference,
which
is
because
it's
it's.
A
It
has
static
Lifetime
right,
so
it
doesn't
need
to
actually
clone
or
or
cop
allocate
or
anything
like
that.
So
it's
even
a
bit
better
and
you
can
do
it.
The
same
way
like
you
know,
don't
want
to
use
zavering
just
for
Str,
because
it
has
a
lot
more
than
just
SDR,
but
you
can
have
a
look
at
the
code
and
you
might
want
to
use
it
for
your.
You
know,
code
I.
Actually,
that's
that's
it
from
me
because,
as
I
said,
this
is
very
impromptu.
A
So
this
is
all
I
could
come
up
with,
but
we
can
take
some
time
to
to
get
some
mix
to.
If
you
can
have
you
have
some
questions
or
especially
beginner
level.
Rest
questions.
That's
I
can
try
to
answer
and
but
before
I
finish
off
with
this
I
wanted
to
give
a
note
for
beginners
and
that's
like
there's
a
really
awesome
very
like
it's
not
long.
A
It's
a
short
blog
post
called
learning
mindset
and
expectations
if
you
are
new
to
rest
or
if
you
find,
if
you
talk
to
someone
who
is
who
are
just
starting
up,
especially
coming
from
Dynamic
languages,
JavaScript
especially
tell
them
to
read
this
first
before
you
do
anything
read
this
first
make
sure
you
understand
it
fully.
Otherwise
you
will
have
some
troubles
that
that
you
can
avoid
just
by
reading
this
and
understanding
what
it
says.
A
Yeah.
That's
it
for
me
very
short,
talk
I
know,
but.
B
A
Zebas,
no,
actually
it's
the
other
way
around,
because
I
was
writing
some
divas,
you
know
so.
Divas
is
a
IPC
protocol,
very
famous
in
Linux
and
I
needed
to
implement
a
debuff
service,
and
there
was
only
one
crater.
At
the
time
available,
it
was
called
debus
RS
and
it's
just
a
wrapper
around
a
crappy
C
library,
so
the
I
I
just
couldn't
figure
it
out.
A
Also
it
was
because
I
was
a
beginner
at
that
time,
so
that
added
to
my
frustration
and
I
was
like
how
about
I
just
start
a
new
one
from
from
scratch,
which
is
purely
written
in
Rust
and
turns
out,
it
was
hard,
but
Dimitri
I
made
it
so
yeah.
That's
that's
how
I
so
so
I
had
to
do
it
in
Rust,
because
I
needed
it
for
rest.
C
And
yeah.
A
And
and
then
when
Russ
came
along,
I
was
like
wow.
This
is
this
is
everything
I
was
I've
ever
dreamed
of
so
and
then
I
started,
writing
rust
and
I
realized.
This
is
because.
A
I
that
that
blog
post
I
mentioned
that
wasn't
there
at
that
time
and
I,
just
yeah
I
was
doing
just
shooting
in
the
dark,
but
yeah
there
were
some
people
who
helped
me
out
and
then
I
realized
I
got
it
at
some
point.
Yeah
now
I
get
it.
It's
awesome.
Actually
I.
B
Agree
to
to
have
a
few
more
questions:
okay,
yeah
I,
wasn't
expecting
your
background
and
see
because
I
was
going
to
ask.
How
would
you
would
recommend
maybe
teaching
it
like?
You
were
talking
about
more
Dynamic
languages
if
you're,
like
maybe
teams
coming
from
that
background
or
because
with
C
I,
can
imagine,
there's
a
lot
of
things
in
Rust
that
would
attract
you
right
memory,
management
and
everything.
So
that's
you
get
a
bit
of
the
more
modern
programming
features
right.
A
Well,
I
I
think
there
is
also
like
from
other
programming
languages.
There's
like
the
safety
is
like
on
a
completely
different
level
right.
So
if
you,
if
you
care
about
safety,
and
not
just
in
terms
of
like
safety
itself,
right
like
you,
you
you
you
want
to
create
a
service,
you
want
to
create
any
solution
that
is
used
by
users.
You
wanted
to
not
just
break
down
at
some
random
point
because
of
silly
null
pointer
reference
or
something
which
is
very
much
possible
even
in
high
level
languages.
A
Many
of
them
well
actually
most
of
them.
So
you
don't
want
that
so
that
I
think
that
that's
something
safety
is
something
that
that
should
attract
people
from
all
over,
not
just
from
low-level
programming
language.
C
C
I
was
wondering
like
what's
your:
what's
your
personal
take
essentially
because
I
see
people
taking
different
approaches,
someone
would
say:
okay,
I
only
do
synchronous,
rastans
and
I.
Don't
have
to
deal
with
like
80
percent
of
the
problems
and
and
then
I
get
80
of
the
benefits
and,
like
some
people
would
say
now
you
need
to
go
in
and
then
all
you
call
this
asynchronous
all
your
libraries
I
think
synchronous.
A
So
I,
finally,
you
ask
because
I
I
did
some
talks
here
about
I.
Think
I
did
two
talks
here
about
async,
at
least
because.
C
A
The
things
that
I
mentioned,
like
I
I,
that
zebras
hit
all
the
problems
that
I
that
it
could
and
one
of
the
big
one
was
async.
So
the
first
version
of
zebras
it
was
completely
blocking.
It
was
synchronous,
but
it's
an
it's
more
like
an
inter-process
communication
thing,
so
everybody
was
asking
for.
When
would
you
provide
async
and
the
problem
was
that
which
runtime
should
we
depend
on?
A
And
if
we
depend
on
one
runtime,
then
the
other
people
are
alienated,
so
I
I
should
should
I
short
myself
in
the
foot
and
I
said:
okay,
I
will
have
a
async
agnostic,
runtime
agnostic
library,
and
that
was
a
pain
but
I
more
or
less
succeeded
anyway.
To
come
to
your
question.
A
Well,
basically,
like
it's
the
same
thing
that
I
learned
from
before
I
I
was
introduced
to
rust.
If
you
are
doing
IPC,
you
are
doing
networking
anything
that
can
potentially
block
you.
Ideally,
you
should
be
doing
async.
You
should
be
using
a
async
await
in
Rust
now
and
I
know
that
there's
a
there's
quite
a
few
pain
points
still
but
I
think
as
an
application
developer.
You,
don't
you,
don't
have
a
lot
of
them.
Actually,
it's
it's
mostly
smooth
sailing
nowadays,
especially
because,
as
an
application,
you
can
just
choose
a
runtime.
A
There's,
not
a
it's
completely
up
to
you
and
most
people
choose
Tokyo
and
I.
Wouldn't
blame
you
if
you
do
the
same,
because
it's
easier
and
it's
like
they
have
this
batteries
included
approach.
So
it
has
a
lot
of.
They
have
a
lot
of
apis
and
they
have
also
these.
They
are
most
of
their
apis
feature
gated.
A
So
you
can
disable
everything
that
you
don't
need
and
only
enable
the
things
that
you
need,
and
that
makes
it
super
small
as
well,
but
there
are
use
cases
where
you
cannot
use
Tokyo
and
some
of
them
like,
for
example,
embedded
use
case
where
you,
for
example.
Let's
say
you
don't
have
an
allocator
even
and
yeah
you
Tokyo
is
not
currently
at
least
it's
not
possible
to
use
it.
So
you
might
need
another
runtime
yeah,
what
else
yeah
and
about
Tokyo.
A
It's
awesome
for
application
developers,
but
it's
like
they
make
it
super
easy
for
for
their
own
users,
but
at
the
cost
of
making.
It
really
really
painful
for
libraries
that
don't
want
to
depend,
have
a
hard
dependency
on
Tokyo,
so
yeah.