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

41–50 of 62 posts

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

#41

Post by timClicks »

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…

It is, but I think people accept that these are automatically generated outputs from compiler-created code.

Like any notation, once you understand how to break it apart and you learn what symbols mean, it becomes easier to interpret large fragments like this.

One pretty significant issue for newcomers is that rustdoc emphasises traits, rather than methods. Sometimes there is more indirections. It takes more insider knowledge to know that fmt() is actually called by the println!() macro, so you're unlikely to encounter that method unless you're digging into the internals.

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

#42

Post by mike-cardwell »

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 documentation is not easy to read, and it often lacks important descriptive context about how to use a library. I started learning Rust about a month ago, and I feel like the documentation has made my life more difficult than it needed to.

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

#43

Post by RussianCow »

dozzie wrote: post #39
RussianCow wrote: post #36

Earlier quoted context omitted.

Practically every company I've worked with uses an HTTP reverse proxy. When you use something like nginx, it's really not hard at all to get right. Support for HTTP is more widespread than support for FastCGI these days, especially with more obscure tech stacks. Edit: You can run multiple apps on separate ports, so that shouldn't be an issue.

> Practically every company I've worked with uses an HTTP reverse proxy. Well, there are people who can say the same about Node.js or RoR. Not that it makes a majority. > When you use something like nginx, it's really not hard at all to get right. It's not a matter of nginx. It's a matter of what assumptions are hardcoded in the application. > Edit: You can run multiple apps on separate ports, so that shouldn't be an…

> 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 scale. On the flip side, you might waste a lot of time trying to get your tech stack working with FastCGI if there isn't already existing support, and you don't benefit from any HTTP support you already have.

> Such a deployment looks terrible at best.

Again, "looks terrible" is not a valid argument against it.

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

#44

Post by bigdubs »

nilved wrote: post #6
rshm wrote: post #3

Still without ssl. Nice to see lots of stars and forks.

SSL is really not the responsibility of the web framework.

There are deployments where the traffic from the LB => app instances needs to be encrypted, so it would be the requirement of the server.

Source; I build secure financial services software day to day.

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

#45

Post by dozzie »

RussianCow wrote: post #43
dozzie wrote: post #39

Earlier quoted context omitted.

> Practically every company I've worked with uses an HTTP reverse proxy. Well, there are people who can say the same about Node.js or RoR. Not that it makes a majority. > When you use something like nginx, it's really not hard at all to get right. It's not a matter of nginx. It's a matter of what assumptions are hardcoded in the application. > Edit: You can run multiple apps on separate ports, so that shouldn't be an…

> 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 to deal with once,

For every f&ckin' application.

> but they really shouldn't even be issues in the first place.

They shouldn't be, I agree, in that sense that it should be impossible to get it wrong. With HTTP you don't have this and you need to deploy workarounds.

> On the flip side, you might waste a lot of time trying to get your tech stack working with FastCGI if there isn't already existing support,

Node.js may be the only offender here (I didn't bother to check). Virtually everything else that is used for web applications supports FastCGI.

> and you don't benefit from any HTTP support you already have.

Like what? What exactly is the benefit of running HTTP between frontend HTTP server and application's backend? Because the trouble with passing information about the request is a clear downside.

>> Such a deployment looks terrible at best.

> Again, "looks terrible" is not a valid argument against it.

Oh, quite the contrary. Inelegant systems or deployments usually give a death by a thousand cuts. Too many exceptions and rules and guesses to work with them.

Just as we can judge the elegance of source code, we can judge the elegance of deployments.

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

#46

Post by onmobiletemp »

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.

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

#47

Post by crzwdjk »

vvanders wrote: post #16
IshKebab wrote: post #15

Earlier quoted context omitted.

It is readable, but you are right it is terribly formatted with a lot of not-very-important information in huge fonts. I think rustdoc needs quite a lot of work in general. For example it doesn't even give a list of methods at the start of each type's page. Want to know which methods you can call on a `String`? Enjoy scrolling... https://doc.rust-lang.org/std/string/struct.String.html

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

Wait, that thing is a button? I never knew that. I guess you can tell because when you hover over it, the status bar on your browser says "javascript:void(0)". I feel like this bit of design might just be a little bit too flat.

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

#49

Post by moosingin3space »

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.

Once you understand traits, those trait bounds really aren't bad. Now if this were some macro-heavy library, I could understand the complaints, but this is just constraining the type of the generic type.

I find it readable, it's saying that the "inner" function returns a reference to the value the State object is containing (which must be of a type that implements Send and Sync), and that reference cannot outlive the State object the value was returned from.

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

#50

Post by moosingin3space »

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.

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?

Post reply on HN