
Tokio: Runtime for writing reliable asynchronous applications with Rust - based2
https://github.com/tokio-rs/tokio
======
carllerche
Hi! Tokio maintainer here. I'm surprised (in a good way) to see this posted to
HN today. Nothing big is happening this week.

That said, I'm always happy to answer questions.

~~~
onei
One of the things that puts me off investing in Rust day-to-day is the lack of
v1 packages in areas like this. I notice I'm not alone based on the results of
the annual Rust survey. What do you imagine v1 will look like for Tokio
compared to today and when would you envisage it landing?

~~~
carllerche
We're aiming for 1.0 by Q3 2020. I wrote a bit about it here:
[https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-
to-1-0](https://tokio.rs/blog/2019-11-tokio-0-2/#a-roadmap-to-1-0) That said,
io_uring __may __end up impacting that target by a little bit.

I understand the sentiment re v1. In reality, Tokio v0.1 was pretty much 1.0.
We never cut 1.0 because async/await was in the works and it was unclear
__when __it would be released. Now that async /await is out, 0.2 was a __big
__change. We need some time to stabilize our APIs and collect user feedback.
This process is happening now and going well.

~~~
carlmr
As someone who has dabbled in Rust, I think the Rustaceans are just too
careful to bump something up to v1 before it's near perfect. In other
languages the package ecosystem looks more mature because people are less
careful in bumping up numbers.

~~~
naasking
I'm sure they look more mature, but they might leave a bad impression. Rust
already has "bad PR" with the borrow checker, so libraries being more
conservative before bumping versions might work in its favour. Otherwise you
might get a bad impression from the language _and_ apparently immature
libraries.

~~~
larntz
For me the borrow checker is what I find interesting about rust.

I wouldn't call it bad pr.

~~~
naasking
The people talking about it generally complain about it. Those comfortable
with it generally aren't talking about it. I don't know what else to call that
than bad PR. Just the nature of the beast.

------
cmckn
I'm a Rust noob, and I don't understand the relationship of Tokio and the
language's async/await syntax. Is there a "reference implementation" of the
runtime? Is Tokio or another runtime required for those keywords to do
anything?

I also found this blurb from the website to be confusing:

> Zero-cost abstractions Tokio's run-time model adds no overhead compared to
> an equivalent system written entirely by hand.

This sounds like Tokio's impl is comparable to other impl's of "the same"
system, but how does it compare to "naked Rust"?

~~~
mamcx
> and I don't understand the relationship of Tokio and the language's
> async/await syntax.

One of the surprising things with rust here, is that it define only the syntax
and some bare traits AND ALLOW TO PLUG ANY RUNTIME.

This mean you can "swap" runtime implementations and even build your own.

One recent example is:

[https://www.reddit.com/r/rust/comments/g917ad/smol_stjepang_...](https://www.reddit.com/r/rust/comments/g917ad/smol_stjepang_a_small_and_fast_async_runtime_for/)

This is in contrast with Go/Erlang/.NET, etc where the runtime for it is made
for you, but can't be changed. This is cool where things are mostly fine all
the time, but rust being a SYSTEM lang allow this is neat (example: Embebed
scenarios where a regular runtime is too heavy).

Note: This template show in other places, where for example you can swap the
allocator or the (default) hash function.

~~~
sdegutis
The main thing I don't understand about Rust's async/await situation is how
it's not very inefficient on the CPU given that it fundamentally uses polling?
[https://doc.rust-lang.org/std/future/trait.Future.html](https://doc.rust-
lang.org/std/future/trait.Future.html)

~~~
carllerche
The model is very similar to how epoll works. The executor does not poll
futures in a loop. Between polls, the executor waits for a readiness
notification.

If `Future::poll` returns Pending, once it becomes ready to do more work, it
notifies the executor, the executor then schedules the future to be polled
again.

------
anderspitman
How's async looking in Rust these days? About a year ago I wrote one service
that's in production. I ended up doing a lot of the futures stuff by hand.
Never really understood how the error mapping/conversions worked, and usually
just fiddled with them until it compiled. I remember the docs being decent,
but there wasn't a single book/site that had everything in a comprehensive and
approachable manner. In spite of all that, the service has chugged along
pretty nicely.

Ultimately I've just been more productive in Go for the time being, but I
remember definitely see the potential down the road for great things.

Has async/await permeated the ecosystem? Is the book more fleshed out?

~~~
tick_tock_tick
It's better but it suffers from the same poison aspect all async/await
implementations do.

[https://journal.stuffwithstuff.com/2015/02/01/what-color-
is-...](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/)

~~~
naasking
Can't say I find that argument all that compelling. Using the logic from that
article, functions that perform side-effects have a different colour from
those that don't, therefore we should prevent all functions with side-effects
to enable better interoperation? I suspect the author and most other
programmers might have some disagreements with their new monadic overlords.

The point is that "colour" is introduced to make _a meaningful distinction_ in
order to achieve a desirable property. He's enamored by Go which erases this
distinction, but it does so by giving up nearly all of the benefits of the
event-driven model: very small captured state for resuming the continuation.

~~~
lmm
> Using the logic from that article, functions that perform side-effects have
> a different colour from those that don't, therefore we should prevent all
> functions with side-effects to enable better interoperation?

The argument is the reverse: it's too hard to explicitly manage side effects,
so we should make our functions implicitly, pervasively side-effecting. E.g.
allowing any function to throw an exception without declaring this in their
signature is widely agreed to be a better approach than Java-style checked
exceptions; the argument goes that we should also allow any function to be
async without declaring this in its signature.

(I think there's some merit to the argument in languages that aren't powerful
enough to express functions that are polymorphic over async-ness. Personally I
use languages with higher-kinded types and then you get the best of both
worlds: you have an explicit distinction between async and not, but you can
write functions that work with both)

------
eximius
Was there a new release? Just raising awareness of it's existence?

------
fierro
legit name

------
jksmith
This assembly programmer wants to know what bare-metal performance means in a
HLL.

~~~
pjmlp
The same that an Assembly language that gets translated into CPU micro-ops and
executed via microcode.

~~~
cesarb
Just nitpicking, but that's not how a modern CPU works. The microcode does not
execute the micro-ops, the microcode is used to generate micro-ops to be
executed, and in fact most instructions don't even go through the microcode,
which is used only for complex or rarely used instructions. Simpler
instructions are decoded directly into micro-ops.

