Hacker News Reader

Comment by anonyfox | Hacker News Reader

Yes, I got that. So to build a "small" web framework like express.js, one could build a routing layer based on macros (like Phoenix/Elixir or rocket.rs do), plus JSON-serialization (Serde might do it) and a compile-time HTML-templating-engine, all of those leveraging zero-cost abstractions once Macros 1.1 land in stable, right?

Then stuff like spinning up 1 OS-thread for every CPU core and scheduling requests in round-robin (?) style, and then wrap it all up into a developer-ergonomic thing.

Since you probably have a way better insight into rust-dev and the ecosystem, can we stay tuned that this eventually will happen or are there still showstoppers somewhere?

View on HN

Yup! So for the next step up, see this example of using hyper with tokio: https://github.com/hyperium/hyper/blob/tokio/examples/server...

You could see how that match block functions as a router...

I was literally playing around with this last night. There's a lot of experimentation going on in the server-side Rust web framework space right now, and I expect it to heat up even more now that tokio has had a release.

> once Macros 1.1 land in stable, right?

So to be clear, macros 1.1 gets you custom Derive, which is Serde/Diesel. It'll be stable in the next release in ~3 weeks. It won't get you the full ability to use any custom attribute, like https://rocket.rs/ uses.

> Then stuff like spinning up 1 OS-thread for every CPU core

This is not implemented in tokio yet, but in my understanding, it's coming.

> a lot of experimentation going on in the server-side Rust web framework space

This alone are awesome news! Having worked with literally dozens of web frameworks, I have a sincere interest to see what emerges from the rust space. I can't pinpoint or prove it, but many developers seem to care about doing stuff "the right way" instead of getting something out the door that works maybe Ok. I really wait for the "this is it"/"we couldn't possibly solve this better" moments that might arise from such experimentations.

> macros 1.1 gets you custom Derive, which is Serde/Diesel

... basic building blocks for all things web I'd say. Looks like the next stable release will arrive just-in-time for things to emerge.

And then there might be the next wave of rust-users/developers that want to built upon such rock-solid foundations, like me. Really, I'm excited like I haven't been in many years!

Really minor thing, but I for instance like how in Hyper.rs types are used to enforce (at compile time) that one does not try to write headers after having started or sent the body of a response. http://hyper.rs/hyper/v0.10.0/hyper/server/index.html#an-asi... Good sign that we are starting to leverage the compiler to verify such invariants.

> > Then stuff like spinning up 1 OS-thread for every CPU core

> This is not implemented in tokio yet, but in my understanding, it's coming.

I just started full-time work on something like that (waiting out a noncompete) but more similar to the LMAX disruptor than a round-robin scheduler. That sort of heavyweight pinned actor architecture has a lot of performance and simplicity benefits especially for something like Rust which already has a solid handle on good memory use.

What does rocket.rs use that makes it different from serde as far as custom derivations go?

Custom derive:

    #[derive(Serialize)] <- you can write anything inside the ()s

Full on procedural macros, attribute style:

    #[get("/hello/<name>/<age>")] <- you can write anything inside the []s

Can rocket use `#[derive(get("/hello/<name>/<age>"))]` instead of `#[get("/hello/<name>/<age>")]`?

No, because its creator is not willing to compromise on ergonomics in order to get on stable. I would imagine that they would reject this on these grounds alone.

Reply on news.ycombinator.com