Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tokio 1.0 – async runtime for Rust

tokio.rs

Post reply on HN
Print view View original

301–310 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#301

Post by lmm »

sanxiyn wrote: post #103
akvadrako wrote: post #94

Earlier quoted context omitted.

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…

Zig's "colorblind" async is very exciting for this reason: https://kristoff.it/blog/zig-colorblind-async-await/

Sounds like a horribly complex special case. I'd far rather just have higher-kinded types and be able to write sometimes-async code using normal polymorphism (like I do in Scala all the time).

Re: Tokio 1.0 – async runtime for Rust

#302

Post by sanxiyn »

hombre_fatal wrote: post #277
sanxiyn wrote: post #226

Earlier quoted context omitted.

Eh, so Rust is not for me? I seem to have heard Rust being inclusive and empowering everyone blah blah. I must have misheard.

It's clear this is one of your hobby horses. Every comment thread here is encumbered with you pointing out that you wouldn't like it if async were the default, fair enough. In fact, you don't seem to like the idea in general. ctrl-f "sanxiyn" yields 28 instances, most of them restating in every subtree the same point about how you think threads > async. Since I think most of us tend to read the comments section top t…

You may want to contribute something concrete. I did learn some new advantages of async over threading from replies, besides tired C10K. Yes, async is useful for C10K. No, I am not solving C10K problem.

1. If you use async in single thread mode, you can save thread synchronization.

2. async works better for idle connections and slow connections, even when the absolute number of connections is not large.

3. async task is easier to cancel than thread.

I still won't use async since thread synchronization hasn't been slow for me, thread cancellation hasn't been problematic for me, and I use nginx to handle idle connections and slow connections, but it's useful to know in case I need.

Re: Tokio 1.0 – async runtime for Rust

#303

Post by lallysingh »

nchi3 wrote: post #211
pvorb wrote: post #181

Earlier quoted context omitted.

And once you get to a limit, the alternative to rewriting everything in non-blocking code might be to put multiple instances of your blocking app on multiple VMs/k8s/whatever behind a load balancer.

Or, you just take the initial leap and write async from the start. For languages with decent abstractions such as async/await, it really isn't hard when you've done it for a while, and I'd make the same argument as one of the parent posters in that it's great "documentation". K8s is brings way more complexity and headache, so it's kind of funny that you suggest that before using async/await.

Setting up k8s once solves the problem for all your apps. In contrast, the additional software complexity of async/await is duplicated across all of them.

If your planning to scale up, k8s is likely something you'll want later. Additional complexity in your apps is not.

Re: Tokio 1.0 – async runtime for Rust

#305

Post by eropple »

therein wrote: post #268
eropple wrote: post #243

Earlier quoted context omitted.

Can you explain exactly what that library using Tokio internally exposes to you that's a problem? Because, as written, this sounds like a religious argument.

If you need to use (for the sake of the example) Rusoto, since it is based on tokio, you'll need to set up the Tokio executor or at least add a macro to your main for this to be done for you. I believe Rusoto actually would take care of this for you if you haven't done it yourself however friction arises when you were already using a different version of tokio and Rusoto is built against another. Basically, it isn't…

Gotcha, makes sense. Thanks!

Re: Tokio 1.0 – async runtime for Rust

#306

Post by lmm »

ldng wrote: post #282
jgilias wrote: post #193

Earlier quoted context omitted.

Can you elaborate a bit what it is that you find difficult or undesirable about Tokio? Or async/await + some runtime in general? So, I can relate to not wanting to pull in the dependency. But otherwise it seems pretty straightforward to me. You just macro-decorate the main function, sprinkle some async/await around, maybe add a join or a mutex somewhere, and then pretty much forget all about event loops, messaging, t…

I also don't get the async hype. Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise. And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover…

> Maybe it is undesirable because that often times plain mono-thread synchronous is fast enough, easier to read, easier to debug and safe to handle to a junior ? Not everybody in a team has the same level of expertise.

Shared-memory concurrency is pretty much always buggy, IME, even if your team thinks they're experts.

> And Rust is not an interpreted language. IMHO, interpreted languages should just drop to a compiled one to keep it KISS. Instead of going the async road, just to discover in production, it is unstable because back-pressure was not taken into account.

WTF? Switching to a compiled language doesn't magically make your threads nonblocking. Maybe you can serve 10x more users with a compiled language, but if we're talking about slow network requests then async can make your throughput thousands of times higher.

Re: Tokio 1.0 – async runtime for Rust

#307

Post by ibraheemdev »

ben0x539 wrote: post #290
octoberfranklin wrote: post #276

Earlier quoted context omitted.

> tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures The standard futures library does not have an AsyncRead or AsyncWrite: https://doc.rust-lang.org/std/future/index.html

Probably in reference to https://docs.rs/futures/0.3.8/futures/io/trait.AsyncRead.htm... vs https://docs.rs/tokio/1.0.0/tokio/io/trait.AsyncRead.html

Yup, that is what I was referring to.

Re: Tokio 1.0 – async runtime for Rust

#308

Post by [deleted] »

octoberfranklin wrote: post #276
ibraheemdev wrote: post #81

Earlier quoted context omitted.

Here is an example: https://github.com/async-rs/async-std-hyper/blob/master/READ... You do have to write a ~50 loc compat layer. However, most of the compat layer is due to the fact that tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures crate, which may change in the future [0]. After that, you just have to implement `hyper::Executor` for async-std's `spawn`, and `hyper::Accept` for async-s…

> tokio's `AsyncRead` and `AsyncWrite` are different from the standard futures The standard futures library does not have an AsyncRead or AsyncWrite: https://doc.rust-lang.org/std/future/index.html

[deleted]

Re: Tokio 1.0 – async runtime for Rust

#309

Post by jeff-davis »

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…

Async seperates the concurrency from the runtime completely. You have code that returns a Future, and creates more Futures along the way. None of this imposes any constraint on the runtime, except that you need some runtime to evaluate the future. But that runtime could be quite simple and execute in the current process/thread (cf. the CurrentThread runtime), meaning you don't need support for threads at all.

Contrast this with the thread model, where the runtime needs to create and destroy threads where the code asks for it. In other words, your program logic is mixed up with runtime considerations.

For a practical example, let's say you want to use rust to extend some C code to create a network client that calls back into the C code. What if the C code is not thread-safe? With async, no problem, just use the CurrentThread runtime. This is my use case, anyway.

Re: Tokio 1.0 – async runtime for Rust

#310

Post by darthrupert »

sanxiyn wrote: post #200
btrask wrote: post #191

Earlier quoted context omitted.

Whether it's kernel threads or green threads, the same patterns (locks, etc) are possible. Locks are supposed to be the borrow checker's bread and butter, because it can guarantee they are held before accessing shared state. But now you're saying "the borrow checker makes writing code without [async/await] difficult, inefficient, and unergonomic." I'm not saying locks are better than async/await (although they are[1]…

Yes. There are some difficult technical issues. In practice, borrow checker works less well on async code than threaded code. This is partly why I prefer threading over async in Rust. Look, we went through some enormous effort to make threading good and fun again. Why wouldn't you use threading?

Because you cannot win artificial benchmarks with threading.
Post reply on HN