Hacker News Reader

Comment by hermanradtke | Hacker News Reader

Once rocket makes it to stable, I think it will be the go to choice for web development in Rust. The focus on creating a great developer story makes rocket a joy to use.

I am shocked that Sergio maintained rocket alone for so long. I would have figured there was a team of 3-4 people working on rocket. Glad to see he is getting help!

View on HN

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".

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.

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)

> 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...

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

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

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

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/.

Does it make any sense to use this with FaaS?

I would assume so. At a high level, not much different than node with express (Edit: for FaaS).

Lambda just announced native support for Rust last week.

Sure thing, but does it make any sense to use Rocket on it?

Rocket specifically? Lots of people like it. Rust generally? Stuff like https://andre.arko.net/2018/10/25/parsing-logs-230x-faster-w... is one success story we’ve already seen.

gp is asking abt rocket inside lambda.

I don't personally think that there's anything inherently specific to Rocket that makes it better for lambdas than any other Rust web framework.

That's just my opinion, of course.

Ah okay.

I wasn't sure if bare-bones Rust+Lamba-Rust-Runtime was already enough.

Speaking as the co-author AWS's Rust Lambda Runtime: there's no fundamental impediment for us supporting Rocket (or any other web framework), but I suspect there'd need to be changes made in Rocket to support how Lambda expects input. Namely, Lambda functions don't see raw HTTP requests, but instead, fully parsed JSON. This blog post shows how Lambda expects data to be formatted: https://aws.amazon.com/blogs/networking-and-content-delivery...

If you're not trying to run a website on lambda, sure that's enough and there's no need for rocket.

Are ther plans to get to stable?

The plan was always to get on stable[1]. Sergio just wasn't willing to compromise on the API to make it happen sooner and I appreciate that since it's a motivation to stabilize the things Rocket depends on. The release notes being discussed here mention that Rocket should be on stable with the next major (Rocket) release.

[1] https://github.com/SergioBenitez/Rocket/issues/19

edit: specify Rocket release, not Rust release

To be clear, it means the next major release of Rocket, not Rust (I misinterpreted your comment and had to go look, so I thought I'd save others time if they also misinterpreted your comment.)

Yes, progress is tracked here: https://github.com/SergioBenitez/Rocket/issues/19

Reply on news.ycombinator.com