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

231–240 of 422 posts

Re: Tokio 1.0 – async runtime for Rust

#231

Post by pvorb »

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.

You probably shouldn't introduce K8s just to solve that problem. I'm just saying if you're already on k8s, scaling horizontally becomes easy.

Re: Tokio 1.0 – async runtime for Rust

#232

Post by sanxiyn »

jen20 wrote: post #218
sanxiyn wrote: post #200

Earlier quoted context omitted.

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?

> Why wouldn't you use threading? Because the C10^nK problem where n increases periodically is still a thing?

I am not solving C10K problem.

Re: Tokio 1.0 – async runtime for Rust

#233

Post by pvorb »

nicoburns wrote: post #195
pvorb wrote: post #156

Earlier quoted context omitted.

If you know that there will be 10k concurrent users in your application, go ahead and use async right from the start. But for the rest of us, simple, blocking code will do just fine and save us a few headaches.

Alternatively use async everywhere from the start and your headaches go away too. It's mixing blocking code with async code that causes issues.

Just do it if everyone in your team is comfortable with it. I'm just not as productive with async code.

Re: Tokio 1.0 – async runtime for Rust

#234

Post by lumost »

mleo wrote: post #201
sanxiyn wrote: post #159

Earlier quoted context omitted.

> A non-async function is "regular logic", it must complete without blocking. Maybe one can enforce this convention in the particular project, but there's no ecosystem-wide consensus on this, and in fact I don't want this to be consensus. I write blocking non-async functions every day. Why am I wrong to do so?

I believe the idea is that within a project that uses async functionality, you should only use non-async functions when the logic does not call blocking functionality. If you are mixing async functionality and synchronous functions with/blocking I would consider the latter a defect unless it is handled properly within an asynchronous context.

I really don't understand the logic of this on a multi-threaded system. The vast majority of functions I write are best executed synchronously, the remainder is usually composed of logic wrapping heavy computations which can be executed in parallel or logic surrounding I/O which can be executed concurrently.

An async system which poisons the rest of my code to force async usage doesn't seem like it will scale to code leveraging multiple libraries and will likely fail at the first lib where the author decided not to bother. The beauty of coroutines in go and Java(soon) is that the async functionality remains local to the code that can make use of it - everyone else just sees a thread-like API.

Re: Tokio 1.0 – async runtime for Rust

#235

Post by afavour »

sanxiyn wrote: post #174
simias wrote: post #165

Earlier quoted context omitted.

>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 wa…

I think the point is that you can omit atomics in async case, if you are always using async in single thread mode.

Rust also lets you avoid atomics by using structs that implement Send. Having an async function return such a struct is a lot easier to map mentally (for me, at least)

Re: Tokio 1.0 – async runtime for Rust

#236

Post by afavour »

sanxiyn wrote: post #196
josephg wrote: post #192

Earlier quoted context omitted.

There is consensus in some ecosystems. Javascript absolutely maintains that invariant. There are (almost) no blocking functions in the javascript / node standard libraries and we work hard to keep it that way. Go maintains similar discipline at the OS syscall level. I feel like the "what color is your function" thing is incomplete. There are arguably 3 types of functions: - Functions which do all their work synchrono…

We are talking about Rust. There is no consensus in Rust.

I think the OP was using examples from a different ecosystems to demonstrate how such a consensus could be reached, if people wished for it.

Re: Tokio 1.0 – async runtime for Rust

#237

Post by sanxiyn »

johnnycerberus wrote: post #230
sanxiyn wrote: post #178

Earlier quoted context omitted.

Programmers cannot get threading right, but Rust can.

Rust won't magically make your threaded code blocks right. It can just provide you tools to ensure that memory won't leak. It's just 1/10 of the solution.

Rust solves threading-specific problems. Yes it's partial, but other problems happen in both threaded code and async code, so that's not a reason to choose one over another.

Re: Tokio 1.0 – async runtime for Rust

#238

Post by steveklabnik »

johnnycerberus wrote: post #230
sanxiyn wrote: post #178

Earlier quoted context omitted.

Programmers cannot get threading right, but Rust can.

Rust won't magically make your threaded code blocks right. It can just provide you tools to ensure that memory won't leak. It's just 1/10 of the solution.

Rust does not ensure that your code is free of memory leaks, to be clear.

Re: Tokio 1.0 – async runtime for Rust

#239

Post by sanxiyn »

afavour wrote: post #236
sanxiyn wrote: post #196

Earlier quoted context omitted.

We are talking about Rust. There is no consensus in Rust.

I think the OP was using examples from a different ecosystems to demonstrate how such a consensus could be reached, if people wished for it.

I don't wish it. That sounds terrible to me.

Re: Tokio 1.0 – async runtime for Rust

#240

Post by lumost »

nicoburns wrote: post #195
pvorb wrote: post #156

Earlier quoted context omitted.

If you know that there will be 10k concurrent users in your application, go ahead and use async right from the start. But for the rest of us, simple, blocking code will do just fine and save us a few headaches.

Alternatively use async everywhere from the start and your headaches go away too. It's mixing blocking code with async code that causes issues.

won't this just bifurcate the rust ecosystem between async and non-async rust libraries?
Post reply on HN