[vhakulinen]

I'm really eager to push for use of rocket (and thus rust) at work, but while rocket being on version 0.x it probably is a tough sell. The benefits rocket (at least seems to) bring feels obvious and I notice every now and then at work that "hey, this would be so easy to do with rocket".

[grayrest]

As a whole, Rust developers see 1.0 as a stability commitment and to my knowledge, everybody (well, not Rouille) wants to be async and depend on Futures 1.0. I believe Futures 0.3 is most of the way to where the Futures team wants 1.0 to be and the initial roadmap was trying for 1.0 in 2018 so my uninformed guess is that we'll see Futures 1.0 in the first half of 2019. I expect the whole Rust network server ecosystem to shift around over the coming months as Futures and async/await come online in the next few months.

[steveklabnik]

So, Futures are moving into the standard library; there’s been a last minute procedural issue over one name, and then they’ll be in. So “futures 1.0” isn’t as important, the futures library mostly provides extra utilities, not the core of futures themselves. It’s likely this means they’ll be in 1.33, February 28 (if my math is right)

[Matthias247]

> So, Futures are moving into the standard library; there’s been a last minute procedural issue over one name, and then they’ll be in.

That's just the open issue around pinning.

There are however a few open discussions around the futures/task/waker parts, from the other RFC. I just wrote down a list of the open points here: https://github.com/aturon/rfcs/pull/15#issuecomment-44549238...

[steveklabnik]

Oh right, I forgot about that but, thank you!

[dominotw]

> benefits rocket (at least seems to) bring feels obvious

Sorry I am not a webdev. Curious what these are compared to something like RoR.

[vhakulinen]

I'm not familiar with RoR, but with rocket, to know which requirements needs to be met in order for a handler to run, you just look at the function definition while in other web framework you usually need to know which middlewares are present etc.

Here are couple of examples (didn't test them, but they should illustrate the point):

    // Simple with admin user.

    #[get("/admin")]
    fn admin(user: AdminUser) -> String {
        // Request is made as admin user.
        format!("Allowed.")
    }

    #[get("/admin"), rank = 2]
    fn admin(user: User) -> String {
        // Request is made as a normal user.
        format!("Not allowed!")
    }

    #[get("/admin"), rank = 3]
    fn admin(user: AnonymousUser) -> String {
        // Request is made as a anonymous user.
        format!("Please login.")
    }


    // More flexable, with permissions.

    #[get("/article/<id>/edit")]
    fn aritcle_edit(permission: PermissionEditContent, article_id: u64) -> String {
        // Request is made with a user that has the correct permission.
        format!("Allowed.")
    }

    #[get("/article/<id>/edit"), rank = 2]
    fn aritcle_edit(article_id: u64) -> String {
        // Request is made with a user that doesn't have the correct permission.
        format!("Not allowed!")
    }

    // Or in single handler.

    #[get("/article/<id>/edit")]
    fn aritcle_edit(permission: Option<PermissionEditContent>, article_id: u64) -> String {
        if permissions.is_some() {
            format!("Allowed.")
        } else {
            format!("Not allowed!")
        }
    }

This is just one of the nice things that rocket brings. To know more, the guide is really good source: https://rocket.rs/v0.4/guide/.