what about server debugging ? python as an interpreted language have a real advantage here. you can easily patch on production for example to debug or hot fix. you would need to rebuild and upload binary in the case of rust.
In Rust, you can define such boundaries, and manipulate things like configuration when you’ve decided you want them to be modifiable, perhaps within a debugger, or more likely via some exposed API (maybe a web API).
To be sure, Rust is less flexible: all such extension points must be designed in, rather than often working by accident (though the Python way is very likely to blow up in your face from time to time).
But in the end I don’t think it’s such a big difference.
(On reflection, I suppose I have seen a debugger used in the scope of a particular request within Django, to give you a pdb prompt instead of just the 500 error page. But that’s then just used for inspecting what’s broken, and most such brokennesses would have been caught by the Rust compiler. Still, something equivalent to that could be nice to have in a Rust development web server; I don’t believe any such thing exists at present, but it could in theory and might be interesting to make. It would still definitely be more limited than pdb. Maybe when we have a Miri-powered REPL something interesting will happen in this space. It’s not a fundamentally impossible space.)
¹ If that works, by the way, you should set up the cached template loader, as it’ll speed template rendering up a lot. That used to be something you’d have to do manually, but now the default template loaders configuration includes caching if debug is False.
why restarting ? when you can reload the new code of the app while it's running ? no service interruption worked for us for years ! but yeah, I agree, better having 4 eyes while patching on prod :)