Zero-cost futures in Rust

Post by saynsedit » Fri, Aug 12, 2016, 2:30 PM UTC

fmap wrote: post #310

pcwalton wrote: post #230

Earlier quoted context omitted.

It would require higher order control flow analysis like k-CFA, which would certainly fail to produce a bounded stack size on any nontrivial program. The futures library is the control flow analysis. Because it uses the type system instead of higher order control flow analysis, it actually achieves precision.

Are you sure about that? First, many higher-order constructs boil down to simple first-order control flow after partial evaluation (see e.g. AnyDSL https://anydsl.github.io/#publications ). Inferring stack size bounds in the presence of higher-order programming features is also possible, and was implemented (as the "static region optimization") in MLkit. But the main point is that code in a high-level programming lan…

Post by kibwen » Fri, Aug 12, 2016, 2:46 PM UTC

gravypod wrote: post #305

pcwalton wrote: post #134

Earlier quoted context omitted.

> Being able to express your code in a sequential manor and still gain the performance offered by implicit fiber,goroutine,w/e scheduling is pretty awesome. You don't gain as much performance. On Linux, you don't actually gain that much if anything over 1:1 threading. Most of the benefits of goroutines actually comes from the small stacks, which don't have anything to do with M:N and 1:1 to begin with—they're a featu…

> Why would you write networking code in C in 2016, when there are better alternatives available (like this one)? As someone who's done a bit of game development in the past I can easily say that you'll fall flat on your face in some fields if you don't write your own protocols. There are simply no protocols that operate well in every use case and there are also use-cases without standardized protocols. For extremely…

Post by Manishearth » Fri, Aug 12, 2016, 2:58 PM UTC

dan00 wrote: post #289

Manishearth wrote: post #266

Earlier quoted context omitted.

Gankro gave an example, but here's a better way to think about associated types: Think about them the same way you think of a method. Methods are "associated functions". If you implement a trait on a type, it can only have one version of a trait method, not two. Similarly, it can have one associated type, not multiple. With a generic trait the trait itself is generic; there are multiple "versions" of this trait so yo…

> Of course, Rust doesn't forbid having it the other way around -- we could make Output a generic parameter too, and have overloaded functions which can have different output types for the same input (and need type annotations to choose). But we don't want FnOnce to work that way, so we don't have it like that. Can you please explain why FnOnce shouldn't work this way?

Post by steveklabnik » Fri, Aug 12, 2016, 3:52 PM UTC

ridiculous_fish wrote: post #272

steveklabnik wrote: post #210

Earlier quoted context omitted.

And I can't believe I missed this, but the other way is to make the struct generic over a type implementing Future.

Does this work though? How do you create an instance of the struct without an instance of the Future?

    trait Future {}
    
    struct DynamicFoo {
        text:String,
        validating: Option>
    }
    
    struct StaticFoo {
        text:String,
        validating: Option
    }

    impl Future for i32 {}
    impl Future for f64 {}
    
    fn main() {
        let d = DynamicFoo {
            text: String::from("foo"),
            validating: Some(Box::new(5) as Box),
        };
        
        let s1 = StaticFoo {
            text: String::from("foo"),
            validating: Some(5),
        };
        
        let s2 = StaticFoo {
            text: String::from("foo"),
            validating: Some(5.0),
        };
    }

Post by pcwalton » Fri, Aug 12, 2016, 3:53 PM UTC

gravypod wrote: post #305

pcwalton wrote: post #134

Earlier quoted context omitted.

> Being able to express your code in a sequential manor and still gain the performance offered by implicit fiber,goroutine,w/e scheduling is pretty awesome. You don't gain as much performance. On Linux, you don't actually gain that much if anything over 1:1 threading. Most of the benefits of goroutines actually comes from the small stacks, which don't have anything to do with M:N and 1:1 to begin with—they're a featu…

> Why would you write networking code in C in 2016, when there are better alternatives available (like this one)? As someone who's done a bit of game development in the past I can easily say that you'll fall flat on your face in some fields if you don't write your own protocols. There are simply no protocols that operate well in every use case and there are also use-cases without standardized protocols. For extremely…