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

Async-std: an async port of the Rust standard library

async.rs

Post reply on HN
Print view View original

131–140 of 238 posts

Re: Async-std: an async port of the Rust standard library

#131

Post by lossolo »

pcwalton wrote: post #125
lossolo wrote: post #98

Earlier quoted context omitted.

> OS threads are not significantly different from goroutines in terms of efficiency This is not true for a use case with a lot of connections, additionally context switch cost a lot more now with all side channel attack mitigations on.

People are happily running Rust servers in production using thousands of concurrent threads per second.

I don't doubt that but apparently we have different definitions of a lot. Additionally latency and hardware also matters, I can say that C is doing n things a second while PHP is doing the same but C is running on EC2 micro instance and PHP is running on 2x Intel Xeon Platinum 9282 dedicated machine. C10K problem was not solved by 1:1 model and this is an old problem. C100K+ is what I see in some of production systems I work on.

Re: Async-std: an async port of the Rust standard library

#132

Post by MaxBarraclough »

Argorak wrote: post #108
MaxBarraclough wrote: post #91

Earlier quoted context omitted.

> I must be dumb Nope, async really isn't trivial. > I know .await != join_thread(), but doesn't execution of the current scope of code halt while it waits for the future we are `.await`-ing to complete? It doesn't, that's the charm of it. It's best to treat 'await' as syntactic sugar, and to dig in to the underlying concepts. I realise we're not talking C#/.Net, but that's what I know: in .Net, your function might d…

> It's best to treat 'await' as syntactic sugar, and to dig in to the underlying concepts. Slight word of warning: `async/await` is more than just sugar in Rust, it also enables borrowing over awaits, which was previously not possible.

Interesting, thanks.

Re: Async-std: an async port of the Rust standard library

#133

Post by pcwalton »

lossolo wrote: post #131
pcwalton wrote: post #125

Earlier quoted context omitted.

People are happily running Rust servers in production using thousands of concurrent threads per second.

I don't doubt that but apparently we have different definitions of a lot . Additionally latency and hardware also matters, I can say that C is doing n things a second while PHP is doing the same but C is running on EC2 micro instance and PHP is running on 2x Intel Xeon Platinum 9282 dedicated machine. C10K problem was not solved by 1:1 model and this is an old problem. C100K+ is what I see in some of production syste…

OK, but, I mean, we've done this experiment, and we found that M:N in Rust was slower than 1:1.

Re: Async-std: an async port of the Rust standard library

#134

Post by pcwalton »

jcrites wrote: post #110
wahern wrote: post #69

Earlier quoted context omitted.

The article explicitly admits that async/await is ergonomically much nicer than explicit futures/promises. But the color problem still remains, one consequence of which is duplication of code and interfaces. Arguing that the problem doesn't exist if you only stick to functions of a single color isn't a rebuttal, it's an admission! But the fact of the matter is async functions have real limitations and costs, which is…

I think the point is that "colored" functions only existed because Rust did not previously have async support. Now that it has async support, new code can be one color: async, while maintaining ergonomics. Maybe new code will be exclusively async and existing code will switch over.

Not all new code shouldn't be async. I write graphics code. There is no benefit to me, or any of my users, if all of my code is async. No system has 10,000 simultaneous GPUs to drive independently.

Re: Async-std: an async port of the Rust standard library

#135

Post by ori_b »

pcwalton wrote: post #125
lossolo wrote: post #98

Earlier quoted context omitted.

> OS threads are not significantly different from goroutines in terms of efficiency This is not true for a use case with a lot of connections, additionally context switch cost a lot more now with all side channel attack mitigations on.

People are happily running Rust servers in production using thousands of concurrent threads per second.

Thousands isn't much.

Re: Async-std: an async port of the Rust standard library

#136

Post by hu3 »

hathawsh wrote: post #81
rammy1234 wrote: post #58

Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?

Rust is very ambitious and unusually successful at reaching its ambitions. It's efficient like C/C++, but safer. It's modern like Go, but more expressive and open to metaprogramming. It's often as readable as a scripting language, but doesn't depend on garbage collection. It's a young rising star originating from a great company.

> often as readable as a scripting language

I beg to differ. If anything, Rust is often cited as being hard to read.

Re: Async-std: an async port of the Rust standard library

#137

Post by steveklabnik »

pcwalton wrote: post #125
lossolo wrote: post #98

Earlier quoted context omitted.

> OS threads are not significantly different from goroutines in terms of efficiency This is not true for a use case with a lot of connections, additionally context switch cost a lot more now with all side channel attack mitigations on.

People are happily running Rust servers in production using thousands of concurrent threads per second.

At the same time, many others do need more power; that’s why async/await is asked for so often.

Re: Async-std: an async port of the Rust standard library

#138

Post by exacube »

hathawsh wrote: post #81
rammy1234 wrote: post #58

Anything Rust gets the post to number 1 spot. What makes Rust special that other programming languages don't enjoy ?

Rust is very ambitious and unusually successful at reaching its ambitions. It's efficient like C/C++, but safer. It's modern like Go, but more expressive and open to metaprogramming. It's often as readable as a scripting language, but doesn't depend on garbage collection. It's a young rising star originating from a great company.

> It's often as readable as a scripting language IMO only if you're using doing simple things the standard library provides utilities for. i haven't found it to be very readable once code grows in complexity, but i'm also not very experienced.

Re: Async-std: an async port of the Rust standard library

#140

Post by jedisct1 »

Arnavion wrote: post #105
mintplant wrote: post #99

How does this relate to Tokio [0]? Why should I choose this new library instead? [0] https://github.com/tokio-rs/tokio

If all you needed from tokio was tokio::net, then async-std could work as a replacement for raw TCP stuff. If you needed the higher-level stuff from tokio like codecs then you'd not have those. Also, anything from the tokio ecosystem like hyper would not work with async-std. Edit: I originally had a first paragraph which was wrong. I mistakenly thought std::net::TcpListener is supposed to impl Read / Write.

Here's an extension trait to convert rust-std streams to tokio streams, so that they work with Hyper https://github.com/jedisct1/rust-async-std-tokio-compat
Post reply on HN