►
From YouTube: Curl with Rust - Daniel Stenberg - EuroRust 2022
Description
Daniel Stenberg
Curl Master at wolfsSSL
Daniel shares how curl is adopting Rust under the hood.
A
Hello:
everyone
I
I,
yes,
I
am
Daniel,
so
I
I
do
curl
full-time
I
started
curl
soon,
25
years
ago.
Actually,
I
work
on
Carl
full
time
all
day
and
I
do
that
for
the
company
wolf
as
well.
We
sell
care
support
companies,
so
today,
I
wanted
to
tell
you
a
little
bit
about
well
curl
and
the
journey
with
rust
inside
of
it,
but
curl
is
see.
There's
a
stable
API,
an
API.
A
There
are
lots
of
back-ends
and
we
have
inserted
rust
into
this
and
that's
sort
of
why
I'm
here
today
right
and
there
are
some
challenges
with
this,
but
we're
at
some
sort
of
point
right
now
that
I'm
going
to
tell
you
about
maybe
something
about
the
future
where
to
go
next.
Will
it
be
more
rust
or
or
wounded,
and
there's
going
to
be
a
q
a
session
after
this
so
hang
around
and
ask
me
anything:
you
know
I'm
here
remotely
so
I
getting
questions
in
the
middle
is
really
tricky.
A
So
let's
avoid
that
but
I'll
be
around
and
ask
answer
any
questions
afterwards,
as
many
as
you
can
possibly
have.
So,
let's
start
out
with
the
fact
that
curl
is
C
right.
This
picture
is
from
around
the
time
when
we
created
a
curl
that
was
back
in
1998
then
and
back
when
we
started
Carl.
There
really
was
no
choice
about
which
language
to
use.
A
You
know
how
to
do
things
in
a
different
way,
so
things
have
developed
a
little
bit,
but
I
just
want
to
emphasize
that
seeing
curl
is
not
for
the
language,
it's
actually
for
the
client.
That's
how
I
actually
came
up
with
the
word.
You
know
silly
word
anyway,
so
Carl
and
lip
curl
is
relying
and
relay
is
one
of
the
biggest
sales
pitches
or
or
sort
of
one
of
the
biggest
reasons
for
Carl
for
its
existence
for
its
popularity.
Why
it's
everywhere
is
that
we
have
a
rock
solid,
API
and
API.
A
A
So
we
do
things
forward
compatible,
but
it
means
that
whatever
you
build
today
with
lib
curl
is
going
to
remain
functional
even
tomorrow
in
two
years
in
10
years,
in
most
cases
actually
for
20
years
by
now,
so
we
don't
break
the
API
ever
we
haven't
broken
it
since
2006,
at
least
so
that
that's
not
ever
that's
just
16
years
or
17,
but
anyway,
so
curl
is
everywhere.
Lib
call
them
particularly
Library.
So
we
still
sort
of
need
to
make
sure
that
this
front
this
thing
we
provide
for
applications.
A
We
don't
break
that,
and
thanks
to
this,
we
now
have
curl
or
lib
curl,
actually,
most
in
most
cases
in
in
more
than
10
billion
installations
worldwide,
and
it's
really
everywhere
in
all
your
devices,
so
we're
in
servers.
You
know
cars,
printers
fridges,
light
bulbs,
game
consoles.
You
know
robots
drones,
well,
whatever
printers
music
instruments,
all
the
apps
portable
mobile
mobile
operating
systems-
you
name
it
curl-
is
there,
so
we
need-
or
rather
our
users
expect
us
to
provide
a
solid
front.
So
we
don't
break
that.
A
But
apart
from
that,
then
we
can
change
everything
inside
right
and
the
downside,
of
course,
with
curl
having
been
written
in
C,
is
that
yeah
that
might
have
been
a
few
vulnerabilities
over
time.
Of
course,
doing
it
in
another
language
wouldn't
have
sort
of
removed
all
of
them,
but
my
assessment
says
that
roughly
50
of
them
that
we
have
done
so
far
and
actually
keep
doing,
are
basically
due
to
what
I
call
C
mistakes.
A
Of
course
that's
based
on
my
assessment,
what
I
sort
of
consider
being
mistakes
you
to
see
so
changing
that
into
another
language
could
have
helped
and
removed.
Some
of
those
mistakes
or
vulnerabilities
than
making
a
more
safer,
secure
world
and
I
mean
we're
going
into
a
world
with
even
more
Internet
connected
devices
right
everything
is
getting
power
and
network
connections,
internet
connectivity
and
I.
A
My
prediction
says
that
we're
going
to
have
many
more
curl
installations
in
the
future,
so
getting
a
better
safer
curl
is
big
benefit
for
for
a
lot
of
users,
basically
for
the
society
So.
Currently,
it's
created
with
a
lot
of
backends
and
and
you
build
curl
with
a
lot
of
third
parties
when
you
create
that
binary
blog
that
runs
in
in
your
tools
and
devices
and
back
ends
in
Carlton,
is
basically
a
selectable
alternative
implementation.
A
I,
don't
know
why
we
call
the
back
end
more
of
a
puzzle
piece.
So
you,
when
you
build
curl,
you
select,
which
kind
of
combinations
of
stuff
do
you
want
to
do
get
into
your
call,
and
most
people
are
familiar
with
the
curl
command
line
tool
right.
So
then
you
get
it
in
your
Linux
distribution
or
you
get
it
with
your
Mac
or
Windows
or
whatever,
and
in
that
case
those
who
built
it
for
those
distributions
they've.
A
They
selected
that
particular
backend
combination
that
they
want
to
provide
in
their
bills,
but
when
you
build
curl
yourself,
there's
a
well
there's,
actually
a
whole
plethora
of
combinations
or
different
things.
You
can
select
and
enable
disable
when
you
build
curl.
So
basically,
we
provide
backends
to
to
give
the
Builders
of
curl
that
power
to
select
what
kind
of
features
do
you
want,
depending
on
what
kind
of
third-party
libraries
do.
You
think
are
okay
licenses,
implementations
features
and
you
know
maturity
and
they
those
different
third-party
libraries.
A
They
can
very
well
be
written
in
different
languages
right
as
long
as
we
can
build
with
them
or
link
with
them
and
get
them
in
the
final
run
time.
It
doesn't
matter
if
if
they
are
and
of
course
we
have
a
lot
of
internal
apis
to
handle
this
and
I'll
show
you
more
about
that,
but
it
doesn't
really
matter
for
the
outside
as
long
as
they're
internal,
we
can
modify
them
and
play
with
them
as
much
as
we
want.
A
So
basically,
we
have
a
lot
of
internal
different
back
ends,
then,
so
that
allows
us
to
pick
and
choose
whatever
we
want
to
do.
For
example,
we
have
content
encoding
for
for
HTTP
stuff.
We
have
different
resolvers
solutions,
we
have
IBN,
which
is
international
domain
names
for,
for
you
know,
in
the
URLs,
for
example,
we
have
SSH
backends,
we
have
TLS
backends,
we
have
HTTP
3
and
we
have
HTTP
backends
and
in
all
of
those
we
have
well
not
in
all
of
those.
A
In
some
of
those
we
have
rust
Solutions
and
those
are
the
things
I'm
going
to
talk
about
to
you
a
little
bit
more
right
now.
So
we
actually
well
a
year
or
two
ago
we
started
into
the
fun
adventure
of
creating
a
new
HTTP
back-end
to
allow
us
to
build
curl
with
a
huge
chunk
of
the
Native
C
code,
replaced
by
code
written
in
a
separate
language
and
sorry
in
a
separate
Library,
namely
hyper
written
in
Rust.
So
basically,
what
we
did
were
I
did
we
have
this
previous
setup.
A
When
you
know
we
have
an
API,
we
have
the
common
logic
to
do
things
in
Carl.
You
know,
connections
and
resolving
things
and
and
generic
trance
range
and
how
to
do
things
transfer
stuff,
potentially
many
transfers
in
parallel,
and
we
have
this
HTTP
blob,
speaking
HP
and
we'll,
of
course,
you
know
with
kernel,
supports
26
different
protocols.
So
we
have
many
different
protocol
implementations,
but
we
have
one
we
had
one
for
ATP,
so
basically,
HP
then
involves
a
lot
of
things
like
authentication,
setting,
headers
proxy
stuff.
A
You
know
content
headers
and
we
have
transfer
headers
that
sort
of
intermixed
in
HP,
and
it's
not
always
that
clear
to
users
which
are
rich
but
anyway,
and
those
both
HTTP
1
and
HTTP.
2
Transmissions
I'm,
leaving
out
hp3
for
now
make
lots
of
reasons
but
never
mind
and
then,
of
course,
hyper
was
introduced
into
this
mix
and
in
Hyper's
case
they
that's
the
library,
that's
written
in
rusted.
It
supports
HTTP
and
HTTP
2,
but
it
doesn't
support
all
the
HTTP
stuff
that
curl
supports.
A
It's
currently
supports
more
HTTP
or
stuff
built
with
the
HTTP
or
in
association
with
HTTP.
Not
necessarily
you
know
core
is
to
be
stuff
like
authentication
or
proxy
stuff
which
isn't
really
how
to
use
HP.
So
basically
we
introduce
support
to
use
hyper
for
some
of
the
HTTP
stuff.
So
what
I
did
then
was
yeah
made
I
had
to
re
redo
each
Carl's
implementation,
so
we
could
do
a
high
level
HTTP
and
we
could
do
it
with
a
low
level,
low
level
HP
and
one
of
those
low
level.
Hp
implementations
is
now
hyper.
A
Hyper
is
written
in
Rust,
and
that
was
just
one
way.
So
that
was
the
new
thing.
We
did
that
so
a
new
internal
backend
to
do
to
select
HTTP
implementation,
but
we
already
since
before
had
another
way
to
do
a
optional,
TLS,
implementations
and
wow
in
in
comes
Russell's,
then
written
in
in
a
language
you
might
know.
So
this
was
yep
another
TLS
back
and
we
started
to
supporting
Carl
and
yeah
Russell's.
A
Is
they
support
an
sc
API
thanks
to
this
Russell's,
ffi
and
sure
curl
already
supported
a
large
variety
of
different
TLS
libraries?
So
this
was
just
another
piece
in
that
setup,
which
made
it
easier
for
us
to
introduce
a
new
TLS
library,
because
we
already
had
this
system
set
up.
So
it
was
basic
only
a
matter
of
adjusting
writing
glue
code
to
make
sure
that
we
could
use
Brussels.
A
A
I
didn't
do
that
work
myself,
but
Jacob
did
an
excellent
job,
and-
and
now
you
can
build
curl
to
do
that
and
I
just
want
to
emphasize
that
this,
both
the
hyper
work
and
the
Russell's
the
work
was
actually
supported
or
sponsored
by
isrj
and
thanks
to
their
prostheimer
project,
which
made
that
possible
I'll
get
into
some
details
about
how
it
works
or
doesn't
work
just
yet
right,
and
then
we
have
this
third
back-end.
Also
a
rust
written
Library
called
quiche
quiche
being
an
HTTP
3
in
quick
back
end.
A
So
yes,
they
too
provide
a
c
API.
You
see
a
patterning,
so
they
all
provide
C
apis,
mostly
through
their
SFI
system
in
in
Rust,
and
thanks
to
that,
we
just
glue
that
Library
into
curl
and
we
can
use
those
rust
things
to
build
and
run
call
so
yeah.
Basically,
then
we
have
all
these
different
backends
and
when
you
talk
to
Carl
well,
an
application
uses
the
API.
A
That's
the
yellow
box,
yellow
Cloud
up
here.
They
of
course
go
through
the
public
API
and
the
public
API
Remains,
the
Same.
It
doesn't
really
matter
what
kind
of
internal
backends
we
build
with.
So
that's
the
key
to
success
here
right.
So
that's
the
solid
foundation,
the
API
and
API
that
we
don't
fiddle
with
That
Remains,
the
Same.
That's
the
public
white
API
here
at
the
top,
and
then
you
know
we
provide
stuff
like
different
content,
encoding,
different
resolvers,
different
ID
and
solutions,
different
SSH
Solutions.
We
do
different
HTTP
back-ends.
A
Now
then,
one
of
them
being
hyper,
the
rust
Library
we
have
different
HTTP
3
Solutions,
one
of
them
being
key
is
the
rust
library
and
we
have
a
lot
of
different
TLS
Solutions,
of
course,
than
one
of
them
being
the
rust
option
there.
So
we
have
rust
solutions
for
those
three
different
backends
and
you
can
see
there
are
a
few
back-ends
without
rust,
Solutions.
Yet
so
the
process
to
do
this
actually
well,
there
have
been
a
few
challenges
to
do
this
in
Carl
and
I.
A
A
I
started
the
project
to
to
make
sure
that
curl
could
use
hyper
for
doing
HTTP
right
and
HTTP
is
one
of
the
oldest
protocols
we
support
in
curl,
it's
actually
the
oldest
the
protocol.
I
started
I
the
precursor
to
curl
precursor,
to
the
precursor
to
curl.
Actually,
it
was
called
HTTP
get
I
started
that
in
1996
with
HTTP
that
was
300
lines
of
code.
I
wanted
to
do
some
basic
HTTP
transfers.
So
that's
the
origin
of
the
HTTP
code
in
curl.
A
It
has
been
around
for
a
ridiculous
a
long
time,
but
it
also
then
has
matured.
It
has
been
stable,
it
has
provided,
and,
as
I
mentioned,
it
has
supported
a
world
of
devices
and
tools
and
services.
So
it
was
important
when
switching
to
hyper
that
we
can
actually
insert
hyper
into
this
mix
and
without
it
being
noticeable
at
all
to
the
outside
right.
That
means
a
byte
per
byte
and
exactness,
or
you
know
how
the
protocols
are
sent
and
seen
to
the
outside
world.
A
We
can't
tolerate
that
we
do
things
differently
or
that
we
don't
cannot
provide
the
same
features
set
with
Hyper,
so
that
started
an
adventure,
an
adventure
I
think
for
both
of
our
projects,
I
think
well.
First
of
all,
we
were
the
first
user
of
the
hyper
C
API,
which
of
course,
it's
always
good
to
be
the
first.
A
If,
then,
you
get
the
experience,
all
the
fun,
both
ups
and
downs,
of
course,
and
I
think
we
we
couldn't
help
hyper
to
develop
a
better
C,
API
and,
in
some
instances,
actually
a
better
API
in
general,
because
I
think
it
affected
their
rust
API
several
times
as
well.
But
it
also
caused
us
to
reconsider
a
few
things
of
our
internal.
A
It's
a
challenge
right:
the
headers
only
and
no
documentation
for
the
C
side
of
things
and
being
Ami
being
a
CE
developer
and
and
a
really
I'm
here
talking
at
the
rust
conference,
but
I'm
a
rust,
rookie
I,
don't
know
rust
at
all.
Actually
so
I'm,
not
the
person
to
ask
about
specifics,
but
but
it
also
then
brings
a
particular
kind
of
challenge,
because
all
the
documentation
is
for
the
rust
API
and
not
for
the
C
API.
So
how
do
I
actually
figure
out
exactly
how
it
works
from
a
c
point
of
view?
A
And
not
you
know,
the
translation
is
not
always
clear
to
mere
users
such
as
me,
and,
of
course
it
took
some
thinking
to
do
to
split
how
to
support
the
upper
layer
of
HTTP
and
the
lower
layer
or
HP
pluggable
like
this,
but
I
think
in
general,
I'm
My
Hope
was
already
from
the
beginning
that
it
would
benefit
us
to
make
sure
that
to
do
this
separation
it
could
be
a
better
way
to
abstract
the
protocol.
Implementation
inside
of
curl
and
I
think
it
has
it
was.
A
It
is
a
challenge
to
you,
know,
keep
up
with
different
API,
behaviors
and
paradigms
in
the
different
languages.
How
we
do
things
in
in
Rust
generally
actually
affects
the
the
C
API
in
a
way,
so
it
it
becomes
a
c
API.
That
is
a
little
bit,
maybe
unusual,
to
see
programmer,
not
I
mean
it's
not
the
impossible
or
or
totally
weird.
A
It
just
takes
some
adjustments
and
getting
used
to
the
way
of
thinking
so
how
to
do
things,
for
example,
and
when
then
we
found
memory
leagues,
because
we
forgot
to
do
something
in
the
C
API.
It
could
be
really
tricky
to
figure
out
exactly
what
went
wrong
and
why
and
what?
What
we're
supposed
to
do
previously
to
avoid
it.
But
otherwise,
that's
mostly
seamless
I
mean
the
fact
that
it
is
rust.
A
Underneath
it's
rarely
a
concern
for
us,
because
it's
not
really
noticeable
and
that's
the
same
thing
actually
goes
for
using
Russell's
too
again
here
that
they
build
their
c
c
API
with
ffi
the
Russell,
the
CFI
thing,
but
again
espec
spariously
with
documentation.
So
it's
a
bit
hard,
sometimes
to
figure
out
exactly
how
it
works,
but
in
in
this
case
I
didn't
do
much
of
the
Russell's
integration.
A
So
I
also
avoided
a
lot
of
those
produce
personally,
but
I
saw
the
excellent
results
from
mostly
Jacob
at
the
isrg
who
did
most
of
this
work,
but
also
then
the
hours
situation,
how
we
did
how
we
do
TLS
backends
was
fairly
mature
already
at
the
time
they
started
this,
so
it
I
mean
before
they
did
this
work.
We
had
support
for
12
different
TLS
libraries,
so
this
became
the
13th
TLS
Library.
A
Annoyingly
not
quite
feature
completely.
I'll
mentioned
a
little
bit
more
about
that
in
a
second
so
and
then
the
third
rust
Library,
exactly
following
the
same
pattern
here
and
and
I'll
highlighted
for
you
in
yellow
here,
yes,
no
documentations
for
this
e
API.
So
this
is
the
third
library,
then,
with
the
Capi
for
the
rust
Library
without
documentation
for
a
c
program
how
to
use
it,
which
again
makes
it
difficult.
You
know
the
corner
cases
what's
exactly
supposed
to
happen
in
this
particular
scenario.
Yes,
but
but
using
quiche
in
general
is
not
a
problem.
A
Quiche
is
it
then,
as
I
mentioned,
it's
it's
for
quick
and
HTTP
3
and
if
you're
I
mean,
if
you're
not
into
quick
or
HTTP
3
details.
This
is
completely
strange
and
unfamiliar
territory,
but
the
TLs
situation
is
really
weird
there
and
the
two
less
Library
situation.
So
so
is
the
situation
about
using
quiche
in
production.
So
that's
not
the
fault
of
keys,
really
that's
more
of
a
fault
of
them.
A
Yeah
I'll
save
that
for
another
talk,
so
yeah
and
that's
the
implementation
here
is
not
yet
feature
complete
either,
but
more
of
a
Carl
side
because
doing
things
HTTP,
3
and
stuff.
It
takes
a
little
bit
more
fiddling
and
so
we're
we're
going
to
get
into
that.
Hopefully
soon
and
what's
interesting
here.
That
Keisha
is
a
library
that
provides
HTTP,
3
and
I
know
that
hyper
is
also
working
on
on
its
hp3
support.
A
I
mentioned
already
before
that
that
hyper
supports
HTTP,
1
and
HTTP
2
and
I
know
that
they
are
working
on
hp3,
so
we
are
going
to
into
a
future.
What
is
going
to
be
some
interesting
challenges
to
add
support
for
H3
through
hyper,
as
well
as
a
sort
of
applicable
approach.
H3
is
quite
different
than
H2
in
in
my
in
many
ways.
So
it's
it's
a
interesting
times
so
anyway,
using
rust
in
curl
is
really
working
apart.
A
Well,
first
of
all,
the
my
first,
the
first
few
emails
back
and
forth
when
I
talked
about
this
years
ago.
Now,
when
we
run
out
of
memory,
we
don't
panic
right,
we
don't
abort,
we
don't
it's
a
panic
inside
the
rust
library
and
it
makes
an
abort
and
we
do
not
do
a
boards
in
system
libraries
right.
We
return
an
error
and
I.
Don't
know
the
situation
for
this
right
now
in
Rust,
but
back
then
it
was
an
issue.
I
hope.
A
One
by
one
and
I
could
totally
see
curl
replacing
more
of
these
components
over
time,
I
mean
given
that
people
want
this
and
that
we
have
a
competitive
and
good
alternatives
to
do
this,
with
there's,
of
course,
that
pattern
of
a
bit
of
a
lack
of
documentation
in
that
corner
space.
You
know
between
the
Sea
and
the
rust
world
as
a
c
project
such
as
curling
has
to
use
the
curve,
the
rust
stuff.
So
exactly
in
that
borderline,
that's
that's
turned
out
to
be
a
challenge.
A
So,
but
okay,
that's
a
little
bit
how
the
journey
here,
so
the
current
status
is
that
well,
things
are
actually
working
pretty
good.
So,
basically,
in
hyper,
we
can
do
this.
You
can
build
curl
today
with
Hyper.
It's
it's,
we
label
it
experimental
you
actually
have
to
enable
by.
So
at
will
so
you
have
to
yes,
I
want
to
build
with
Hyper,
and
if
you
do
that,
you
will
see
that
curl
works
pretty
much
the
same
and
I.
It's
rarely
that
anyone
will
ever
notice
any
difference
anywhere.
A
So
it's
totally
agnostic
to
the
https
T
lesson,
so
you
can
actually
build
them
with.
You
can
build
curl
with
Hyper
and
maybe
Russell's
if
you
want
to
go
with
the
rusty
last,
but
you
can
also
go
with
another
TLS
library,
because
they're
totally
independent,
so
you
can
go
with
whatever
solution
and
it
works
just
fine
and
transparently.
A
Six,
six
account
is
16
yesterday
that
are
still
disabled
when,
when
hyper,
when
built
with
Hyper,
because
we
haven't
really
adjusted
those
final
edge
cases,
yeah
really
annoying,
but
still
a
fact,
and
that's
the
primary
reason
why
we
still
label
it
experimental
because
we're
not
quite
there
yet,
and
you
know
how
it
is
with
the
project.
You
know
90
99
done
so
there's
only
99
of
the
work
left
to
get
that
final
few
once
fixed
some
of
them
pretty
tricky,
but
we're
going
there
eventually
I
know
girls
in
in
Russell's
land.
A
That's
also
called
considered,
experimental
and
mopped
in
and
primarily
then,
because
we
have
12
test
cases
disabled,
you
know,
even
if
fewer
than
for
hyper
and
for
example,
Russell's
doesn't
support
IP
addresses
in
the
certificate,
which
is
a
feature
that
you
really
need
to
do
to
be
feature
complete
with
curl,
so
we're
we're
still
hoping
so
there's
both
features
missing
in
Russell's
and
some
maybe
some
integration
part
left
in
crawl
and
in
in
the
key
side
of
things.
Hp3
then
pretty
much
the
same
state
where
in
curls
land
there
we're
more
of
an
immature
status.
A
We
haven't
really
gotten
around
to
do
everything
correctly,
we're
starting
our
project
right
now,
so
we
I
hope
that,
within
within
the
next
six
months,
we
will
be
in
a
much
better
place.
Carl,
wise
and
I.
Think
quiche
is
a
in
a
pretty
good
place
too.
So
that
might
so
there's
a
little
bit
of
a
competition
here
which
of
these
rustles
based
Solutions
or
rust,
based
solutions
that
we
will
so
now
remove
the
experimental
tag
from
first
but
I
think
they're
all
in
a
pretty
good
position.
A
So
this
this
is
an
interesting
race
to
see
where
we
go
on
this,
so
in
total,
and
you
could
say
that
we
we
are
going
to
see
more
Russells
in
that
curl
binary.
And
you
know
that's
that's
the
rusting
curl
here
and
that's
the
sort
of
the
takeaway
here.
We
don't
actually
rewrite
anything
in
curl
in
Rust,
but
we
replace
the
components
that
curl
can
use
with
rust,
provided
Solutions
and
it
works
really
well
really
smooth
it's
transparent
and
we
don't
really
any
users
don't
really
have
to
care
about
it.
A
We
I
mean
we're
old,
but
we're
not
big
and
we're
not
that
many
developers
working
on
it
day
to
day
so
any
help
will
be
appreciated,
and
you
know,
and
and
of
course
it's
a
really
tricky
land
to
be
in
that
Borderland
between
sea
and
rust,
so
there's
a
special
kind
of
person
who's.
Who
can
do
this,
of
course,
but
everyone
can
do
a
little
bit
and
we
need
your
help
there
so
going
forward.
A
Instead
of
the
other
backends
and
I'm,
taking
sort
of
the
back
seat
position
here
and
say
that's
up
to
the
users
or
the
ones
who
build
Carl
to
bank
test
selection,
I'll
sort
of
let
that
be
a
market
decision.
If
you
want
to
go
that
way
to
go
that
way.
If
you
want
to
go
the
other
way,
go
the
other
way
and
I
see
what
everyone
wants.
If
this
is
what
everyone
wants,
we
go
there
and
if
we,
if,
if
we
go
there,
we
might
do
it
even
more.
A
That
could
be
I
mean
that
were
written
in
Rust
that
we
could
possibly
consider
using
possibly
others
for
the
already
existing
back-ends,
and
maybe
we
could
do
more.
Back-Ends,
like
I,
did
for
the
HTTP
one
with
Hyper
to
provide
more
rust,
written
power
into
curl
without
ruining
or
sort
of
alarming
the
API
or
API.