Thanks! This convinced me. I'll stick to C for low-level, C++ for CUDA stuff, and C# for everything else.
For my line of work. I rather use what is available out of the box in SDK installers and respective IDEs, no need to add extra complexity.
Now in general, I think Rust's sweet spot is on kernel, drivers and maybe composition engine, anything else GC languages with low level features, e.g. Swift, D, Nim, Crystal, .NET Native, Java (after Panama/Vahlala), Go (assuming 2020 generics get in) are a much more productive way to tackle problems.
EDIT: Just like with FP, I am a firm believer that eventually all mainstream languages will have some form of affine types, and Rust will have played the role of a stepping stone into the adoption of Cyclone and ATS ideas for low level coding.
Also should be noted that Rust lacks the necessary certifications.
If a bug could kill someone, you should (to the greatest extent possible) have a proof that such bugs are impossible.
The thrust of the article is, from the abstract, that Rust should consider altering the compiler and the crates ecosystem to better enable the safety features that Rust champions, because ‘ results indicate that software engineers use the keyword \unsafe in less than 30% of Rust libraries, but more than 75% cannot be entirely statically checked by the Rust compiler’.
I would assume this, but also
> is there some issue with the underlying empirical analysis of Rust’s library codebase?
this is hard to tell, because
> The paper, upon which the video is based is linked in the description and is easily accessed
I don't think this is true, or else, I am missing it somehow. Where is the paper? I don't see it linked from the page that's linked in the description, and a quick google of the title didn't turn it up for me either.
> Since Unsafe Rust may modify an arbitrary memory location, any use of Unsafe Rust in any dependency compromises the static guarantees of the whole library
With this definition, literally every Rust program is not safe, because:
1. Most operating systems don't have syscalls written in Rust, so doing anything at all ends up needing unsafe.
2. Even if you wrote an OS with safe syscalls, doing things with the hardware is going to require unsafe.
So, buried somewhere in there, unsafe will exist. So I don't personally think this definition makes a lot of sense.
To me personally, comments like this are more interesting, and tell a different story:
> The number of unsafe blocks per crate is small for the majority of the crates, more than 90% of the crates have fewer than ten unsafe blocks
This validates one of Rust's core propositions, IMHO. From eyeballing the graph, it seems that ~70 of crates have zero unsafe? Very interesting.