4 ms·

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.

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.

privacyonsec 6y ago
I really don't understand the down votes :) yes I've been working on python applications and live patching code for emergency, our app was deployed and running on 64 different machines. I'm not talking about coding in production or whatever, of course once the workaround is done on production a proper solution is implemented and deployed. 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 :)
brobinson 6y ago
I've been writing Python for a few years now (at my job), and most of the situations where I've used breakpoint() to debug something would literally not have been possible in Rust because they would have been compile time errors instead of runtime errors.
jamil7 6y ago
This really only works in the case that you have one server running a python app that you can ssh into. Any deployments more complicated than that and it starts to break down.
chrismorgan 6y ago
I don’t think I’ve ever seen anyone try live-patching a Python server. Modifying the code and restarting the server, sure. Modifying Django templates and having the updates show immediately, sure.¹ But modifying the code and restarting the server is logically equivalent to modifying the Rust code, rebuilding it and restarting it. Any finer live-patching in Python is risky, largely only safe to do at defined boundaries. Modifying code is a hazardous operation, because it depends on how things use it. Patching module.function only helps places that import module and call module.function, for example, not places that use `from module import function`. So, simplifying drastically, you can mostly only really modify singletons, and singletons that have been designed to be modified in this way. 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.
- deleted 6y ago
  [deleted]
keypusher 6y ago
Debugging and hotfixing in production is not generally a good idea. Updating a site with significant traffic will usually involve pushing some type of artifact through a build system and deploying it to multiple servers, and that’s true whether it’s a python script or rust binary. As far as an actual debugger, I believe rust generally encourages gdb. If your concern is about Rust compile times, that’s a different but valid question.

privacyonsec 6y ago

I really don't understand the down votes :) yes I've been working on python applications and live patching code for emergency, our app was deployed and running on 64 different machines. I'm not talking about coding in production or whatever, of course once the workaround is done on production a proper solution is implemented and deployed. 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 :)

brobinson 6y ago

I've been writing Python for a few years now (at my job), and most of the situations where I've used breakpoint() to debug something would literally not have been possible in Rust because they would have been compile time errors instead of runtime errors.

jamil7 6y ago

This really only works in the case that you have one server running a python app that you can ssh into. Any deployments more complicated than that and it starts to break down.

chrismorgan 6y ago

I don’t think I’ve ever seen anyone try live-patching a Python server. Modifying the code and restarting the server, sure. Modifying Django templates and having the updates show immediately, sure.¹ But modifying the code and restarting the server is logically equivalent to modifying the Rust code, rebuilding it and restarting it. Any finer live-patching in Python is risky, largely only safe to do at defined boundaries. Modifying code is a hazardous operation, because it depends on how things use it. Patching module.function only helps places that import module and call module.function, for example, not places that use `from module import function`. So, simplifying drastically, you can mostly only really modify singletons, and singletons that have been designed to be modified in this way. 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.

deleted 6y ago
[deleted]

keypusher 6y ago

Debugging and hotfixing in production is not generally a good idea. Updating a site with significant traffic will usually involve pushing some type of artifact through a build system and deploying it to multiple servers, and that’s true whether it’s a python script or rust binary. As far as an actual debugger, I believe rust generally encourages gdb. If your concern is about Rust compile times, that’s a different but valid question.