Replacing FastAPI with Rust: Part 5 - Rocket 0.5

[dbanty]

This discussion thread is a place for you to leave your questions, comments, suggestions, and emoji reactions to this blog post. It's also a great place to leave ideas about what you'd like to see in the rest of this series!

⚠️Correction⚠️

The blog post talks about using parking_lot::Mutex to solve the issue of mutating shared data. Both parking_lot::Mutex and std::sync::Mutex are dangerous in async contexts because they're blocking and can cause deadlocks! Consider this situation:

1. Future 1 locks the Mutex and begins working on editing the data. It hits a .await and yields control to the runtime.
2. Future 2 tries to lock the Mutex and blocks, waiting for it....
3. The runtime is now effectively deadlocked. It can't get back control because Future 2 will never.await. Future 1 will never finish working and drop the Mutex guard, so the Mutex will never unlock.

The solution, already implemented in my fork of rocket_lamb, is to use tokio::Mutex instead. The .lock() function there is a Future which can be .awaited.

[swilcox3]

It's exciting watching you work through these issues as a first timer to this sort of problem. It really illustrates to me the power of Rust: you're solving some extremely hard and risky problems in a way that's going to be safe at runtime. Even though you're definitely struggling to learn the concepts and make the compiler happy, the program you're producing at the end is going to be sound. That makes all that struggle good struggle, because it teaches you and helps you be a better programmer that understands threading better, without risking terrible results in something you've built.
Trying to do this in C++ would be a whole lot of bad struggle, because the compiler will happily let you build a server with shared, mutable, owned-from-multiple-threads state. That kind of state is OK in Python, because Python is single threaded and garbage collected, but in C++ that's really bad and nobody will tell you until your server starts crashing randomly. And I do mean randomly, it'll work fine for weeks, or just give you subtle bugs, then one day it'll blow up. Then you've got to dig through core dumps and debuggers and try to reproduce it, and in anything but a trivial application it's a straight up nightmare. At the end of the day (and by day I mean weeks), you'll understand what you did wrong, but only after hours and hours of frustration. Not to mention the customers who are filing bug reports and jumping all over you because your app sucks.
In short, this is exactly why Rust was made and it's awesome to see that purpose being borne out in your project.

[dbanty]

It really is fun to get to experiment with this stuff and have it work. Even with Python where this stuff is less dangerous it's still likely to break. Mostly I just avoid multithreading there altogether which is really unfortunate when trying to do things like multiple database queries.

I've never had to deal with this stuff in something like C++ and I'm very glad 😅

[dbanty]

Whoops, turns out my solution (while not dangerously unsafe) would have still potentially caused the program to seize up due to a deadlock. I posted a correction above, but I guess Rust can't catch all issues 😅.

[swilcox3]

True, Rust won't catch mutex deadlocks or infinite loops. That's getting up to the realm of program design though, not much you can do about those at the language level. There's still no substitute for a robust test suite and peer review. It's just that in Rust you can focus on actually interesting problems, like your async threading model, rather than stupid memory leaks.

[euan-reid]

Stumbled across this series as a fellow FastAPI fan exploring Rust alternatives and thoroughly enjoying it, thank you. Rocket 0.5 has, at last, been fully released as of a couple weeks ago - have you had an opportunity to tinker with it yet and see how it feels compared to the release candidate?

[dbanty]

I have played with it a little and it seems great! Very glad to have a stable Rocket release again, I think it's still the backend framework with the best developer experience right now. Now I just need an excuse to build something new with it (since most of my deployed stuff is Axum at the moment).