Utilizing third-party open source libraries is fundamental to modern software development because it can enhance productivity and software quality. However, libraries may cease maintenance and become deprecated, negatively impacting the projects that rely on them. Promptly identifying and addressing deprecated libraries can help developers mitigate potential risks within their projects. As a programming language known for its emphasis on safety, Rust’s package manager currently does not provide a direct mechanism for deprecation. Nevertheless, Rust developers can still declare deprecation using certain methods offered by GitHub and the official Rust package registry, crates.io. However, the current usage of these deprecation mechanisms in the Rust ecosystem, as well as their effectiveness, remains underexplored. This paper addresses this gap by empirically studying the prevalence of deprecation declarations in Rust libraries, the effectiveness of different ways of declarations, and the reasons for using deprecated libraries to understand how deprecation information is disseminated and perceived in the current Rust ecosystem. We found that: 1) Among the 13,289 inactive libraries in the Rust ecosystem, only 11% of them indicate their deprecated status; 2) Among the packages that released a new version after their dependent library declared deprecation, 38.9% still chose to use the deprecated library in their new releases; 3) Despite developers being able to actively or passively discover deprecated libraries within their projects through various means, unawareness of library deprecation is a significant reason for developers using deprecated libraries. Based on these findings, we discuss practice insights to help improve the deprecation mechanism and mitigate software dependency risks.