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

Rocket, Rust Web Framework, v0.2: Managed State and More

rocket.rs

Post reply on HN
Print view View original

51–60 of 62 posts

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#51

Post by mixedCase »

onmobiletemp wrote: post #46
eknkc wrote: post #5

Just curious, I really want to like Rust but take a look at the State API documentation for managed state feature: https://api.rocket.rs/rocket/struct.State.html (screenshot: http://c.ekin.io/3c2q112x1p0y ) Is this readable to Rust people? I mean, can you look at this and say, "ah ok, I'm gonna call this and that then I'll have the state" directly? I'm lost but I have zero Rust knowledge so this is a sincere question…

Im so tired of people who dont know rust complaining about rust. Learn rust and then complain. And yes it makes perfect sense ... if you know rust.

There are many languages I don't/didn't have to learn before I could read and/or patch code written in it. I hacked on C and C++ code long before I understood their basics. Go would've been the same if I hadn't bothered to spend a couple days learning it shortly after first exposure.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#52

Post by Daishiman »

I have to say, the end user API for Rocket is pretty nice.

But damn, there's a lot of compiler magic in order to simplify the request and response signatures.

It would be great to see more documentation on how to deal with naked Request/Response objects that can be constructed by hand. I'd love to use Rocket to develop some API on top of it, but that means I want more access to the underlying objects below.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#53

Post by riquito »

steveklabnik wrote: post #21
vvanders wrote: post #16

Earlier quoted context omitted.

The +/- button will do that for you. It's one of the first things I do once I read the top example.

We've discussed flipping the defaults; it was decided before I started writing so many docs and examples. Very different today!

Maybe you could add a responsive right bar with the list of methods, visible when the screen is large enough. My 24'' monitor has 30% wasted space right now.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#54

Post by cmrdporcupine »

eknkc wrote: post #5

Just curious, I really want to like Rust but take a look at the State API documentation for managed state feature: https://api.rocket.rs/rocket/struct.State.html (screenshot: http://c.ekin.io/3c2q112x1p0y ) Is this readable to Rust people? I mean, can you look at this and say, "ah ok, I'm gonna call this and that then I'll have the state" directly? I'm lost but I have zero Rust knowledge so this is a sincere question…

The font sizes are dubious, as it is drawing more attention to type signatures than the actual function name and description. Once you draw your eye to the right place it seems pretty reasonable to me.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#56

Post by steveklabnik »

riquito wrote: post #53
steveklabnik wrote: post #21

Earlier quoted context omitted.

We've discussed flipping the defaults; it was decided before I started writing so many docs and examples. Very different today!

Maybe you could add a responsive right bar with the list of methods, visible when the screen is large enough. My 24'' monitor has 30% wasted space right now.

Yes, something like this would be very useful too.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#57

Post by e12e »

dozzie wrote: post #45
RussianCow wrote: post #43

Earlier quoted context omitted.

> It's not a matter of nginx. It's a matter of what assumptions are hardcoded in the application. You haven't actually given any good examples for what makes HTTP reverse proxying bad. Things like dealing with the Host header are two-minute fixes that you only have to deal with once, but they really shouldn't even be issues in the first place. HTTP is well supported, well understood, easy to implement, and easy to sc…

> You haven't actually given any good examples for what makes HTTP reverse proxying bad. Try running anything that generates absolute URLs in its HTML. And then try to make it running under two different domains, for example. A clear cookie/URL disaster, and it's all for web protocols from 2002, without talking about HSTS or CORS yet. > Things like dealing with the Host header are two-minute fixes that you only have…

> What exactly is the benefit of running HTTP between frontend HTTP server and application's backend?

For some applications (those that fit within the constraints of REST - and, no, that's not all Web "apps") - you can sometimes get easy caching by dropping something like varnish somewhere between the user and the app.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#58

Post by caconym_ »

moosingin3space wrote: post #50
caconym_ wrote: post #28

Earlier quoted context omitted.

The "traits" feature of Rust's type system provides a lot of nice polymorphism and general ergonomics, but one consequence of its existence is that you see a lot of trait-related noise in the docs and it's maybe emphasized more than it should be by the styling. If you know Rust, it's pretty easy to cut through it if you know what you're looking for, and sometimes it's actually useful.

I wonder if it would be useful if the docs offered a "what functions should my type have" hint for trait-heavy functions. That way all the required functions are in the same place. Paging steveklabnik, what do you think?

What exactly do you mean by this? Could you provide an example?

Personally I think some big gains in documentation clarity could be made by sorting the methods differently, possibly more compactly; I remember when I was first starting with Rust it was easy to overlook trait impls, e.g. a useful `Deref` implementation because they tend to show up further down in the docs.

I might also have benefited from a clearer overview of all the core traits in one place, especially the ones having to do with taking references. IIRC `Deref`, `Borrow`, and `AsRef` are all different traits and the differences between them (and how to idiomatically use them in common patterns) are not totally clear. But maybe I just skipped a chapter of "the book" or something.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#59

Post by rspeer »

caconym_ wrote: post #28
eknkc wrote: post #5

Just curious, I really want to like Rust but take a look at the State API documentation for managed state feature: https://api.rocket.rs/rocket/struct.State.html (screenshot: http://c.ekin.io/3c2q112x1p0y ) Is this readable to Rust people? I mean, can you look at this and say, "ah ok, I'm gonna call this and that then I'll have the state" directly? I'm lost but I have zero Rust knowledge so this is a sincere question…

The "traits" feature of Rust's type system provides a lot of nice polymorphism and general ergonomics, but one consequence of its existence is that you see a lot of trait-related noise in the docs and it's maybe emphasized more than it should be by the styling. If you know Rust, it's pretty easy to cut through it if you know what you're looking for, and sometimes it's actually useful.

One thing I've noticed is that the answer to "how do I use this library?" is often hidden away in a sub-page about one of the traits it defines.

Many libraries are made of boring top-level code and then interesting trait implementations. Structuring the documentation like the code doesn't work out very well in that case.

Re: Rocket, Rust Web Framework, v0.2: Managed State and More

#60

Post by krzyk »

dozzie wrote: post #35
k__ wrote: post #30

Earlier quoted context omitted.

Interesting. I only met FastCGI in PHP. All NodeJS apps I saw used HTTP. Is there any benefit of doing it that way? How does it work with WebSockets?

> I only met FastCGI in PHP. All NodeJS apps I saw used HTTP. And I met FastCGI in Python, Perl, Ruby, and Erlang (though I haven't used the last one yet). Oh, and uWSGI can expose anything it runs through FastCGI. My personal opinion is that web crowd (most of JavaScript programmers fall in here) just doesn't want to learn from anybody else. > Is there any benefit of doing it that way? Compared to running the tiny w…

> My personal opinion is that web crowd (most of JavaScript programmers fall in here) just doesn't want to learn from anybody else.

Where would you put Java programmers? I haven't seen FastCGI there.

> No idea. I don't develop web applications. So why do you talk about FastCGI? It is strictly for web stuff.

Post reply on HN