it will be much less power-efficient, when jailbreak you could schedule the kindle to wake up once per 15/30/60 minutes to fetch the new data, set it as screensaver and then go back to sleep.
All of `Vec` is much smaller than all of the place using Vec. IIRC, Vec is around 3k LoC. And for even low level code like Oxide & Android core, they are observed less than 4% of their code is inside or related to unsafe, that’s a massive improvement.
Yes, Rust is not new in term of allow building hard to misuse abstraction, it’s just allow abstraction over memory safety without relying on GC or runtime checks.
Rust achieve this by adding capability to enforce shared XOR mutability with its borrowck which C++ couldn’t.
That would be the unsoundness of `Vec` itself, but if the abstraction of `Vec` is sound, there would be no way to use `Vec` outside of `unsafe` that can cause memory unsafety.
The point coming back to abstraction and responsibility, in Rust, you can build abstraction that is sound and guarantee memory safety from there. There can be soundness bug inside your abstraction, but it will be a massively smaller surface for auditing and expert required to write such abstraction. Also, when soundness bug appears, the responsibility is solely on the abstraction writer, not the user.
Whereas in C, without those safe abstraction, the surface of doing thing right to avoid memory safety issue is your entire codebase, and responsibility of "holding the knife correctly" is on the user.
> logic bugs outside "unsafe" can cause bugs unsafe.
This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build.
The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".