Whats everyones experiance with Rocket?


#1

I’m a Ruby on Rails dev and I have been exploring alternative web frameworks in search of something lighter and safer. I tried Yesod but found it too hard to find help/docs for bits and the community was pretty sparse for finding answers.

Looking at Rocket, it seems quite promising. The getting started page docs seem very complete.

Who is using Rocket now? How have you found it?


#2

Hey there! I used to work on Rails before coming to Rust. Welcome!

Rocket has great docs, and is generally regarded as a good framework. It uses code generation heavily, which should feel familiar to you from Rails :slight_smile: The downside is, it still requires nightly Rust at the moment; that won’t be forever, but for now it’s a thing. It’s used in production by at least one company that I know of, so it’s got that going for it as well!

Actix Web is an up-and-coming framework I’ve heard a lot of good things about, you may want to check it out.

In general, there’s no Rails equivalent today; the Rust ecosystem seems to favor either Sinatra-like libraries, or something a bit bigger, but still much smaller than Rails.


#3

Using nightly is my biggest Rust “paper cut”. It seems to be broken very often and Rocket (or one of its dependency) force you to update your nightly so you hit those broken nightlies more often.


#4

I think this could be documented more prominently: If you have a file called rust-toolchain in the root of your project, then rustup will install the specified toolchain automatically the next time you invoke cargo (rustup docs). For example, right now I have a project using rocket where the contents of rust-toolchain is nightly-2018-05-13. I use this mechanism at work to make life easier for both my coworkers and the CI machine.

To answer the original question - I’ve only used Rocket for small projects, but I’ve enjoyed it a lot. I can get something up an running really quickly.


#5

I have written a personal web server using Rocket, Diesel and SQLite.
Had to figure a few things out with integration but nothing too difficult, and overall it was quite a pleasant development experience.
Also important to note is that Rocket-based systems are synchronous, and thus are somewhat limited in scale. as you likely want async capabilities when dealing with lots of connections / users simultaneously.

That date is suspiciously familiar, are you perhaps avoiding some kind of LLVM code generation bug? :slight_smile:
Also, I didn’t know about this pretty useful feature, so thanks!


#6

I found it alright. I was used to a Rails environment and I came to Rust because I wanted less implicit behavior and less “magic” over all. Rocket is cool, but it does rely on a lot of code generation, and sometimes I feel myself not understanding exactly what is going on under the hood. It’s certainly not bad, but I’d also consider Actix.

Things are still quite early for Rust and the web, and I hypothesize that it will mature once all the async stuff matures.


#7

Steve already mentioned it, but it needs to be mentioned again: actix-web. Last week I wrote an article Migrating to Actix Web from Rocket for Stability. I had become disheartened by the project failing to compile every other week due to a nightly compiler update, and I found that when I migrated to actix-web so I could code on stable – I only had to touch a few lines of code. Pinning has been mentioned as a workaround for nightly breakage, but (afaik) a pinned nightly won’t be able to utilize the latest and greatest clippy and rustfmt.


#8

The use of nightly rust is a little worrying but it seems like it’s on the way to using stable https://github.com/SergioBenitez/Rocket/issues/19. By the time I have it fully worked out and start making something serious it will probably be stable.


#9

It’s perhaps slightly off-topic, but I don’t understand why Actix even uses the actor model.
It’s not something I’d necessarily want in a web server, especially in a language like rust.


#10

I’m not sure. Whenever I encounter something that won’t compile on nightly, I just jump back a few days to see if it works before digging through github issues.


#11

Yeah I’m not sure I want to learn whatever the actor model is to be able to contribute to Actix.

Could you elaborate on this? I guess it adds complexity while working with futures is already complex enough.


#12

Could you elaborate on this? I guess it adds complexity while working with futures is already complex enough.

What I mean is that in Rust, with its relatively safe multithreading, personally I’d prefer easy to use libraries that let me compose a proper solution using existing primitives if/when I need it.
Instead, Actix uses something called the actor model, which is a fancy name for having multiple agents that work independently, but communicate with each other through message passing.

The thing of it is, when I want multiple independent things to be done, in Rust there are safe and easy to use threads available, that also support message passing through channels. Therefore I wonder why it was necessary to 1. seemingly re-invent the wheel and 2. accepting that it is a part of Actix, why it has to be baked in rather than being some optional middleware.

There is the possibility that this was done for performance / scalability reasons (thousands of Rust/pthreads level threads do not scale nicely), but making an n:m scheduler (golang and Erlang/BeamVM have something like this) with actual good performance is no trivial task.


#13

I have been using Rocket for months and love it. You can do really cool things with all the guards and other features it’s code generation gives you. I feel like it allows you to write more complex programs easier and organize it nicely. The biggest down side is using nightlies, but that’s not so bad, the only thing you really have to worry about is updating your nightlies when using newer versions of Rocket. The Releases page on Rocket’s GitHub have a link to the changelog which will tell you what nightly version you should use for each Rocket version. I’ve never had any stability problems, and I’ve been using it constantly for about 6-7 months. Its also fast.


#14

The actor model is very useful any time you’re dealing with asynchronous concurrency, especially with tokio. Even in a language like Rust! Even though it may seem that “actors” are a heavy-weight feature based on how they’re used in other languages, Actix implements them very efficiently. It basically just gives you a much nicer API to use instead of manually managing your own message queues. I’ve found working with Actix way nicer than trying to go it alone with Tokio, when dealing with any sort of shared resources.

All that said, using actix-web doesn’t require you to mess with actors hardly at all; it can very comfortably act as a super-simple REST web server that just has a bunch of nice features. You just define your routes and handlers.


#15

Quick plug for gotham which I’ve not yet seen mentioned here, and which sounds like it might tick several of your boxes, including this, async, and targetting stable.


#16

I’ve built two http servers in rust so far, one with rocket, and one with the latest tokio + master branch of hyper.

Hyper is intended to be much lower level, so you end up doing a lot yourself, and async io is in a weird state. My thought is that the async/hyper approach is suitable for targeted microservices, while Rocket is a good choice for more general API servers which might have many routes, and thus the boilerplate of a hyper server would be too much to deal with.

As others have mentioned, locking your nightly rust version is super important. If you don’t do it from the start, and then something breaks, you won’t know which version it worked on.

Very happy with both hyper and rocket.


#17

Relevant to this, https://gotham.rs/blog/2018/05/31/the-state-of-gotham.html


#18

Not working on stable rust is dealbreaker for me, so I choose Actix (Unfortunatelly Iron is not maintained anymore).


#19

I’ve been working on a daily basis with Rocket for about 6 months. I haven’t found the nightly issue particularly troubling. Rustup is easy to work with so its easy to download a new nightly, set it to default, compile, and if there is a problem just to go back to the original nightly, wait a few days, rinse, and repeat. Rocket’s core design has a kind of Zen simplicity to it, most notably Rocket’s strongly typed validation - which is more about authentication than validation in the sense of ‘form validation’.The documentation is very good and complete but the learning process isn’t trivial.


#20

By the way, actix can also do validation. Actix's Extractors are the equivalent of Rocket's Request guards.