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

Zero-cost futures in Rust

aturon.github.io

Post reply on HN
Print view View original

31–40 of 348 posts

Re: Zero-cost futures in Rust

#31

Post by kibwen »

losvedir wrote: post #27

I dabbled with rust in the past and was really fascinated with it, but haven't played around lately. One thing caught my eye in the post: fn get_row(id: i32) -> impl Future ; That return type looks odd to me. What does it mean to return an "impl", and is that a new feature in rust, or just something advanced that I missed in my exploration before?

It's an upcoming feature, AFAIK the syntax is still being decided upon. What it means is that the `get_row` function returns some type that implements the `Future` trait, but we refrain from saying exactly which type that is. This is useful for various reasons, and in this case it's probably just being used because typing out the concrete type for some of these deeply-nested and combined types quickly starts to resemble C++ template hell.

Re: Zero-cost futures in Rust

#32

Post by masklinn »

soulbadguy wrote: post #4

Finally a nice async/io interface for rust, always felt that it was a big missing piece, couple of questions for peps familiar with async in other languages : 1 - Isn't the state machine approach the same as C#/.net async/await is using ? But the with the added convenience of the syntactic sugar ? 2 - no allocation : , does'nt the lambda closure need to be allocated somewhere ? 3 - I would have love some comparison (…

> 2 - no allocation : , does'nt the lambda closure need to be allocated somewhere ?

I expect it is embedded in the state machine structure. In Rust (and C++) lambdas/closures are "value types".

Re: Zero-cost futures in Rust

#33

Post by aturon »

losvedir wrote: post #27

I dabbled with rust in the past and was really fascinated with it, but haven't played around lately. One thing caught my eye in the post: fn get_row(id: i32) -> impl Future ; That return type looks odd to me. What does it mean to return an "impl", and is that a new feature in rust, or just something advanced that I missed in my exploration before?

This is an exciting upcoming feature in Rust, which you can read more about in a couple places:

- http://aturon.github.io/blog/2015/09/28/impl-trait/ - https://github.com/rust-lang/rfcs/pull/1522

This feature allows you to return any struct that implements the trait, without having to type the name of the struct (which can sometimes be quite big). It also means that clients only know what traits are implemented; the concrete type is invisible to them. The above links have a bunch more detail.

(And this feature is set to land in nightly Rust very soon! Shoutout to eddyb :)

Re: Zero-cost futures in Rust

#34

Post by kibwen »

pcwalton wrote: post #30
losvedir wrote: post #27

I dabbled with rust in the past and was really fascinated with it, but haven't played around lately. One thing caught my eye in the post: fn get_row(id: i32) -> impl Future ; That return type looks odd to me. What does it mean to return an "impl", and is that a new feature in rust, or just something advanced that I missed in my exploration before?

It's a new feature (hopefully to be merged this week). Here are the gory details: https://github.com/rust-lang/rfcs/blob/master/text/1522-cons...

Worth noting that by "hopefully to be merged this week" we mean that this initial prototype implementation will land in nightly: https://github.com/rust-lang/rust/pull/35091 . It's not being stabilized this week.

Re: Zero-cost futures in Rust

#35

Post by vvanders »

alexcrichton wrote: post #19
vvanders wrote: post #7

Not sure if I missed this in the post, does this depend on any unstabilized features or can we use this today on 1.10.0 stable? Awesome stuff btw, love the iterator inspiration.

You can indeed use this on stable Rust today! Right now 1.9.0 is the minimum supported version due to the usage of `catch_panic` in a few places. I'd recommend a beta compiler for now though to compile some of the examples. There's a bug in the stable compiler which causes them to take up to 8x longer to compile, but beta/nightly are both speedy!

That's so awesome. I was hoping that was the case.

Serious Kudos, it feels like a lot of the promises of Rust are really paying off here.

Re: Zero-cost futures in Rust

#36

Post by tomdale »

The recent flurry of activity around async IO in Rust has been really exciting; to me, it indicates that the core team's decision to stabilize the language was a smart bet that is paying off in rapid ecosystem growth.

One quibble I have with this post is that it talks about futures as a zero-cost abstraction. That might be true (or close to true) from a performance perspective, but in my (admittedly inexperienced) opinion, it seems to have a significant ergonomic cost that is not accounted for.

While futures help us deal with multi-threaded coordination of data from multiple sources, that overhead isn't necessary for situations where you're running in a single thread dedicated to doing IO operations.

Dealing with futures in your code is not non-trivial. Browsing through the futures version of the HTTP server, I had a hard time following along:

https://github.com/alexcrichton/futures-rs/blob/master/futur...

And it requires a bunch of helper code to go with it:

https://github.com/alexcrichton/futures-rs/blob/master/futur...

The blog post mentions Tokio, another high-level abstraction on top of mio (by the same author). Because it doesn't require the futures abstraction from top-to-bottom, it offers similar (maybe even a little better) performance with what, to my eyes, is far simpler code:

https://github.com/tokio-rs/tokio-minihttp/blob/master/src/l...

I'm still learning Rust and spend most of my time in JavaScript. The analogy I'd use is: imagine if in the Node programming model, every API required you to use JS Promises, even at the very lowest level. Even if you could reduce the cost of creating new Promise objects, interacting with them over simple values could make the code you write more verbose. In Rust, that problem is exacerbated by the much stricter type system and the fact that you have to do cross-thread coordination.

I'm a total beginner to systems programming, and a lot of this stuff is above my pay grade. However this shakes out in the community, I'm very happy to see Rust on the way to becoming the fastest, most productive way to write high-performance web services.

Re: Zero-cost futures in Rust

#37

Post by aturon »

tomdale wrote: post #36

The recent flurry of activity around async IO in Rust has been really exciting; to me, it indicates that the core team's decision to stabilize the language was a smart bet that is paying off in rapid ecosystem growth. One quibble I have with this post is that it talks about futures as a zero-cost abstraction. That might be true (or close to true) from a performance perspective, but in my (admittedly inexperienced) op…

Thanks for the thoughtful reply!

I'm a little confused about the snippet you're pointing out. It's not actually using futures at all! In fact, that code is just part of setting up threads for the server. The reason it's more complicated than the version in Tokio is that minihttp supports multiple event loop threads (which gives some performance benefits), and this code is handling that setup.

At a broader level, Tokio's services -- the main thing users write -- are based on futures, in exactly the same way as minihttp. So for people writing actual servers, the ergonomics should be the same.

Now, stepping back, it's definitely true that ergonomics are a cost to be aware of, and it's one we've thought carefully about in the design of futures. We've had a lot of experience and success in Rust with iterators, which share a lot of the same API design philosophy.

That said, I do anticipate that over time we'll want to layer sugar on top of futures. As I mention a couple times in the blog post, async/await (or something like it) is the obvious way to do it, and there's plenty of prior art. But I think we should walk before we run -- let's make sure we've got the core abstraction right, and then we can sprinkle some sugar where it's needed.

Re: Zero-cost futures in Rust

#40

Post by yoshuaw »

alexcrichton wrote: post #19
vvanders wrote: post #7

Not sure if I missed this in the post, does this depend on any unstabilized features or can we use this today on 1.10.0 stable? Awesome stuff btw, love the iterator inspiration.

You can indeed use this on stable Rust today! Right now 1.9.0 is the minimum supported version due to the usage of `catch_panic` in a few places. I'd recommend a beta compiler for now though to compile some of the examples. There's a bug in the stable compiler which causes them to take up to 8x longer to compile, but beta/nightly are both speedy!

How do futures deal with panics? - should they even?
Post reply on HN