Moving to ARTs (possibly combined with B+ trees) might be a smart choice after all.
Edit: sorry, I missed that grand-parent has cited the same paper already.
That's precisely the claim made in the original paper describing Bw-trees.
Would be interesting with a comparison with mentat . Do you plan to support any query langauge such as datalog, like mentat?
What does he mean here? Don't wake up people with operational problems? Or does "wake up" refer to a scheduling strategy?
Either way, what are these techniques?
(For predictable answers to these, and many other complex questions, when dealing with data you care about, use sqlite)
So the only thing you can do is add checksumming schemes that allow you to detect you have been affected.
The paper is from 2013, so the situation might have improved meanwhile (I wouldn't put any money on it)
Or the drive catching fire and the user manually deleting all existing backups.
Quoting from the rust book:
> Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler is trying to determine if code upholds the guarantees or not, it’s better for it to reject some programs that are valid than accept some programs that are invalid. That inevitably means there are some times when your code might be okay, but Rust thinks it’s not! In these cases, you can use unsafe code to tell the compiler, “trust me, I know what I’m doing.” The downside is that you’re on your own; if you get unsafe code wrong, problems due to memory unsafety, like null pointer dereferencing, can occur.
> There’s another reason Rust has an unsafe alter ego: the underlying hardware of computers is inherently not safe. If Rust didn’t let you do unsafe operations, there would be some tasks that you simply could not do. Rust needs to allow you to do low-level systems programming like directly interacting with your operating system, or even writing your own operating system! That’s one of the goals of the language. Let’s see what you can do with unsafe Rust, and how to do it.
(I would also disagree with that statement, but in a different way: Rust enables zero-cost abstractions, but nothing inherently means they have to be. I can also make quite costly ones, and they'll compile.)
Yes and it's more disturbing. It says "In Rust abstractions are free" when an algorithm was discussed.
Rust having "free" abstractions does not change the performance characteristics of an algorithm: this is what the grand-parent was talking about.
We have a whole working group this year working on embedded.
> I think they mean "embedded" as in "embedded in a program", not "targeting embedded hardware".
P.S. Really looking forward to writing Rust on AVRs.
Compare with SQLite, not with Orcale or Postgres.