Tokio 1.0 – async runtime for Rust • Hacker News Board

Re: Tokio 1.0 – async runtime for Rust

#161

Post by Yoric » Wed, Dec 23, 2020, 10:52 PM UTC

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

> Unless you actually think that async code is more expressive and easy to read and write than basic event loops but then you must be a lot smarter than I am because I have to take an aspirin every time I need to dig into async-heavy code.

I don't know about the end of this sentence, but yeah, I'm the kind of person who enjoys very much writing async code and finds that it (sometimes) models the problem much better than sync code and much, much, much better than event-driven/polling programming.

But then, I'm also the kind of person who enjoys coding with CML channels (aka Rust mpsc channels aka Go channels aka Erlang mailboxes aka pi-calculus channels etc.), so I guess I might be a mutant.

Re: Tokio 1.0 – async runtime for Rust

#162

Post by platinumrad » Wed, Dec 23, 2020, 10:53 PM UTC

austinshea wrote: post #132

sanxiyn wrote: post #127

Earlier quoted context omitted.

Most people are not writing the next nginx. They are writing web application servers behind nginx.

This, merely, means that the web application code will hold back what Nginx is capable of serving.

Any web application will already be "holding back" Nginx because Nginx doesn't have to do things like database queries...

Re: Tokio 1.0 – async runtime for Rust

#163

Post by [deleted] » Wed, Dec 23, 2020, 10:53 PM UTC

WhatIsDukkha wrote: post #52

rossmohax wrote: post #37

It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.

https://github.com/stjepang?tab=overview&from=2020-12-01&to=... """smol (likely discontinued, since author left rust)""" doesn't seem well supported and smol is used by async-rs these days iirc.

[deleted]

Re: Tokio 1.0 – async runtime for Rust

#164

Post by maccam94 » Wed, Dec 23, 2020, 10:53 PM UTC

sanxiyn wrote: post #101

ibraheemdev wrote: post #93

Earlier quoted context omitted.

> when you have a huge number of very small tasks running concurrently because that's generally where OS-driven parallelism tends to suffer but is it such a common scenario Web servers are all about I/O and handling small tasks (requests), and are a perfect use case for asynchronous programming. > That sounds like premature optimization in many situations IMO Maybe in some cases... but then just don't use futures. Ru…

You may want async if you are writing the next nginx, but for most web application servers threading is perfectly fine.

But nginx is usually just a proxy for connecting to app servers, and your app servers still need to handle all of those requests.

Re: Tokio 1.0 – async runtime for Rust

#165

Post by simias » Wed, Dec 23, 2020, 10:54 PM UTC

tijsvd wrote: post #146

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

I had the same thing initially. The upside of async over a simple event loop is, in my experience, when things become less simple, and you end up with hard-to-read little state machines all over the place. With async, you can have your event loop, but the state machines are handled by the compiler. Code is like threaded code. That can be very convenient. Threads, obviously, accomplish the same thing, and arguably mor…

>Threads, obviously, accomplish the same thing, and arguably more easily. But threads have a performance problem when they must interact heavily. Cross-thread communication is expensive.

I didn't know that cross "async" communication was cheaper, that does seem like a good selling point, but what exactly makes it cheaper? After all threads share the same address space, so you can just pass pointers around the same way you would within the same thread. I expected the overhead to be roughly similar.

Things can get cache-expensive if the code is running on different cores, but then again using all the hardware resources available is generally something you want to do if you care about performance.

Re: Tokio 1.0 – async runtime for Rust

#166

Post by Yoric » Wed, Dec 23, 2020, 10:54 PM UTC

novocaine wrote: post #158

varajelle wrote: post #114

Earlier quoted context omitted.

> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a lot of memory for all the stacks

Pending async waits have stacks to preserve too

In some languges, that's true. In Rust, however, that pseudo-stack is typically tiny.

Re: Tokio 1.0 – async runtime for Rust

#167

Post by steveklabnik » Wed, Dec 23, 2020, 10:54 PM UTC

novocaine wrote: post #158

varajelle wrote: post #114

Earlier quoted context omitted.

> Considering a normal-sized Linux server can handle a million threads without much trouble, it really seems like misplaced effort Seems like that would use a lot of memory for all the stacks

Pending async waits have stacks to preserve too

The difference, at least in the way this is built in Rust, is that when you create a task, you get a single allocation that's exactly sized. There's no resizing, which means that you aren't getting stacks that are too big or too small, with all of the other runtime shenanigans that that entails.

Re: Tokio 1.0 – async runtime for Rust

#168

Post by Yoric » Wed, Dec 23, 2020, 10:56 PM UTC

10000truths wrote: post #105

sanxiyn wrote: post #90

Earlier quoted context omitted.

Yes, but why would you want that? Using OS threads is better in most cases.

OS threads are preemptive and their scheduling is beyond your control, which introduces potential data races. Green threads allow for cooperative scheduling, which is much harder to mess up.

In my experience, past some level of code complexity, you get the pretty much same kind of races with cooperative scheduling as with preemptive scheduling – with the added risk that you did not expect a race with preemptive scheduling.

Still a fan of async programming, but that's a false benefit in my books :)

Re: Tokio 1.0 – async runtime for Rust

#169

Post by Xevi » Wed, Dec 23, 2020, 10:59 PM UTC

rossmohax wrote: post #37

It is unfortunate, that libraries have to be coded against specific runtime and not generically. There is tokio and there is smol (likely discontinued, since author left rust), maybe other runtimes will emerge, but whole ecosystem is already tied to tokio.

Woah, I didn't know about that. Does this mean Rust only has one maintained runtime now? Namely Tokio.

Re: Tokio 1.0 – async runtime for Rust

#170

Post by pvorb » Wed, Dec 23, 2020, 11:00 PM UTC

akvadrako wrote: post #94

simias wrote: post #77

I don't really get these modern async APIs. In languages like Javascript I thought they only made sense because JS interpreters are (historically) single-threaded, so you really have no choice but async to express some concepts. Fine. But in Rust you can just spawn threads, share data through channels or mutexes, use OS-provided async IO primitives to poll file descriptors and do event-driven programming etc... I tri…

There are some pretty bad usability problems with most async APIs too. One is they make your functions colored; async functions world best with other async functions while normal blocking functions work best with other blocking functions. They also introduce a lot of noise; putting async/await everywhere doesn't tell you anything interesting. Considering a normal-sized Linux server can handle a million threads withou…

In the Java world, project Loom[1] is hopefully going to end this situation of async code that is hard to use with blocking code. They introduce a concept called Virtual Threads (previously called Fibers, but they are still looking for the perfect name). This will allow for seamless interoperability between blocking and non-blocking code as everything in Java runs on a Thread and Virtual Threads are just a specialization of the concept that doesn't boil down to OS threads.

I haven't used it yet, so I can only repeat the advertising copy, but nevertheless wanted to give some perspective from other ecosystems.

[1]: https://wiki.openjdk.java.net/display/loom/Main