> 1) There are a lot of `-sys` crates which link to C libraries, so the "unsafe" code in these crates comes from the binding to C rather than some limitation of

> 1) There are a lot of `-sys` crates which link to C libraries, so the "unsafe" code in these crates comes from the binding to C rather than some limitation of Rust. Often there are 100% safe Rust alternatives to these C libraries as well. Sure... but it's still unsafe code ... with the the consequences of unsafe code. Also doesn't also explain the 30 % to 50 % vs 25 % in Java. My guess would be that java just care less about perf. I mean if blaming a language "unsafeness" on C is an options, i submit that a lot of the unsafe part of C++ where imported wholesale from C. > 2) Of the remaining crates which use "unsafe", the unsafe code is often contained to a tiny percentage of the code, so if we're looking at the overall amount of unsafe code, you're going from 100%, to a fraction of a percent. Three points : First, code volume is a good proxy only when the code samples are uniformly distributed : while the unsafe code might be a tiny percentage of the code base, they might represent a large percentage of runtime and/or a large part of the algorithmic complexity of the whole project. Second going from 100 % to tiny fraction implies that C++ is 100% percent unsafe... and that's not the case. There is safe subset somewhere deep in there. And third, "unsafe rust" is not safer than "regular C++" . Mixing those 3 factor makes the finally "safety" tabulation much more complicated than just counting number of unsafe regions