Cargo Watch is too slow for development #3835
Description
I think actix had an attempt before at implementing hot reload, but deferred to using the default cargo watch instead. But, seriously, it's a bit unbearable how long it takes to compile, especially when you add more features to your server, ie. essentially a monolith-like server with job schedulers, etc. For now, I feel it's best to keep servers small and distributed, like microservices, since hot reloading takes forever when multiple features are on a single server. And, maybe rust actix servers shouldn't be built this way, and should just push compiling to multiple executables and rely on bash to fork execution of each server/services (for monolith, atleast, which also works when pivoting to microservices since the executables would already be separated). The only unfortunate downside is that each server, if run in a monolith, would have an independent Pool Connection Manager... I'm guessing there wouldn't be a way to communicate with each individual executable if the other executable is being starved or monopolized by another executable (honestly, Idk, how it would behave, just guessing what might be an issue if the connection manager isn't centralized to one executable while running monolith)
Most of the time, the sink is just on the bootstrap or server.start() op. It'd be nice if it only restarted the affected region of the code... but I don't know how to do that with Rust without investing a massive amount of time researching it. I don't really understand how Cargo Watch compiles, or how Rust compiles in debug mode/development environment... but if it had a DLL-like compilation where you can compile a certain section of the code, then replace only that section - that would be great. Then ofc use static build for prod.