Rocket, Rust Web Framework, v0.2: Managed State and More
1–10 of 62 posts
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#2I'm very excited about this. I've been looking for a good open-source statically-typed web stack for a long time, and the Rust community delivered.
Now, when this works on stable, it'll be awesome!
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#3Still without ssl. Nice to see lots of stars and forks.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#4I've been using the framework to practice rust and it's really pleasant. I would compare this to "flask" from Python. I've got an experimental static site cms (for my clients eventually) where the administration back end is a dynamic library so I can update the back-end without stopping the serving of the website to the public. Really fun learning experiment and crazy fast server overall. For now, I still use Go, but Rust's meta features are so much more advanced that I'm working on switching.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#5Just 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, does this mess make sense when you get into it?
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#6Still without ssl. Nice to see lots of stars and forks.
SSL is really not the responsibility of the web framework.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#7Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#8Just 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…
With a couple of weeks of Rust experience, that seems pretty clear to me, but the State type isn't the whole explanation. Check https://api.rocket.rs/rocket/struct.Rocket.html#method.manag... too.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#9Just 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…
Given the description of State, the fact that it only has two methods to get at the inner value (.inner() and Deref::deref()), and each returns a different lifetime (one is 'r which is longer than or equal to the lifetime of the State, the other the lifetime of the State), it should be reasonably obvious to people who've coded Rust for a while. The example helps, obviously.
Re: Rocket, Rust Web Framework, v0.2: Managed State and More
#10Just 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…
I'm not a rust guy, don't know it at all... and to me it's not too much different than interface/type definitions for the .Net framework in C#.
It's often easier to work from examples though, but I do know that you often see interesting ways to do things when you look at API docs.
OT: the framework looks interesting... routing as attributes is pretty cool, would be nice if one of the examples on the main page used a route variable though. I am curious how this compares in terms of requests/second of hello world vs. alternates... I would imagine the memory overhead would be much lower, but curious on throughput for the underlying model.