A Rust development tool that enables live code reloading without restarting the application, for faster feedback cycles.
hot-lib-reloader-rs is a Rust development tool that enables live code reloading by allowing developers to modify and reload functions in a running Rust program without restarting it. It works by isolating hot-reloadable code into a Rust dynamic library (dylib) and using the libloading crate to swap implementations at runtime. This significantly speeds up development iteration by providing immediate feedback on code changes.
Rust developers working on applications with long startup times or interactive feedback loops, such as game engines (Bevy), GUI frameworks (egui, Iced), or simulation tools. It's particularly useful for developers who want to experiment with code changes in real-time during development.
Developers choose hot-lib-reloader-rs because it provides a practical, Rust-safe approach to hot-reloading that integrates with existing Rust workflows and frameworks. Unlike full-restart approaches, it offers configurable file watching, event-driven reload notifications, and feature-flag switching between hot-reloadable and statically linked versions.
Reload Rust code without app restarts. For faster feedback cycles.
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Enables instant feedback by reloading dynamic libraries without restarting the application, as demonstrated in the demo GIF and usage examples for rapid iteration.
Provides LibReloadObserver hooks to serialize state or manage application flow before and after reloads, shown in the reload-events example for robust state handling.
Works seamlessly with popular Rust frameworks like Bevy, egui, and Iced, with dedicated examples showing hot-reloading of system functions and UI logic.
Allows toggling between hot-reloadable and statically linked versions using Cargo features, enabling easy transitions from development to production builds.
Modifying function signatures or type layouts without serialization leads to crashes, as the README explicitly warns this causes mismatches between executable and library expectations.
Hot-reloadable functions cannot be generic due to no_mangle attribute limitations, restricting code design flexibility and forcing workarounds for polymorphic logic.
Managing global state after reloads is challenging, especially with dependencies using TypeId (like some ECS systems), requiring careful serialization or reinitialization that can break workflows.