Quoting woodruffw: > The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs be

Quoting woodruffw: > The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code. I think "refuse to integrate code until every conceivable thing is thought out and dealt with" is the right* approach when contributing unsafe code to Rust projects, especially to a foundational crate. Rust is designed around the separation of safe code (which allows non-expert programmers to write code with the speed of C and the safety of Java), and safe APIs around unsafe code (exposing a interface around dangerous primitives, constrained so non-expert programmers can't misuse the API to achieve undefined behavior, use-after-free, dereferencing wild pointers, reading uninitialized memory, etc.). To ensure that safe Rust is actually safe (can't achieve segfaults), third-party libraries which expose safe APIs around unsafe code (like nix) should be proven/provable to never use-after-free, write to wild pointers, expose uninitialized data, etc. This is a high bar to clear, and takes dedicated learning to develop the necessary expertise. But not doing so would expose users of the library to possible segfaults when users "hold the API wrong", which is the failure mode of C++ that Rust exists to avoid. Sadly, the compiler and standard library itself has some unsoundness bugs (described as the "worst kind of bug") which allow convoluted code constructions to result in segfaults despite not containing `unsafe` blocks . These are tracked at https://github.com/rust-lang/rust/issues?q=label%3AI-unsound https://github.com/rust-lang/rust/issues?q=label%3AI-unsound.) On the topic of application-level code quality (rather than foundational libraries), I believe that for native applications, code which can't be proven to be memory-safe (either because the program's author doesn't know C++ and the libraries well enough, or because they accept poorly written code from outside contributors) is a significant factor towards the instability of C++ apps I've used. I'm not sure how to best develop this knowledge; perhaps newbies creating/maintaining codebases could be mentored by more experienced developers (who hopefully have prior experience with the app or problem domain)? Perhaps managed/GC'd languages make it easier to write approximately-correct code, since they don't require global architectural knowledge and flawless reasoning to avoid segfaults. However it still takes global architectural knowledge and flawless reasoning to avoid race conditions. Even though I value code quality over velocity, and despite how incorrect memory-management and threading inevitably results in broken programs, I hate to admit that that gatekeeping code quality and user-facing experience (perhaps architectural design?) could result in more stress, less progress and contributors, and a worse end result.