> DbOptions::durable() > Appended to the WAL without a per-write sync So… it’s not durable? Durable doesn’t mean “survives a process restart”, it means “durably saved to persistent storage”. For example, this “durable” mode wouldn’t survive power loss.
Are we back to MongoDB -- no fsync() but webscale speed?
TurboKV: Insanely fast Rust key-value store
41–50 of 89 posts
Re: TurboKV: Insanely fast Rust key-value store
#42It seems pretty ubiquitous yet not a part of the core rust libs.
Re: TurboKV: Insanely fast Rust key-value store
#43Off topic, but why is tokio still independent of the rust async runtime? It seems pretty ubiquitous yet not a part of the core rust libs.
Re: TurboKV: Insanely fast Rust key-value store
#44Re: TurboKV: Insanely fast Rust key-value store
#45Off topic, but why is tokio still independent of the rust async runtime? It seems pretty ubiquitous yet not a part of the core rust libs.
The same reason as ever. Not everyone wants to use the same runtime.
I'm not trying to be pedantic, but this split over async runtimes was what originally turned me off of rust years ago and it still seems to be an issue.
Re: TurboKV: Insanely fast Rust key-value store
#46> DbOptions::durable() > Appended to the WAL without a per-write sync So… it’s not durable? Durable doesn’t mean “survives a process restart”, it means “durably saved to persistent storage”. For example, this “durable” mode wouldn’t survive power loss.
Re: TurboKV: Insanely fast Rust key-value store
#47Re: TurboKV: Insanely fast Rust key-value store
#48Re: TurboKV: Insanely fast Rust key-value store
#49Earlier quoted context omitted.
The same reason as ever. Not everyone wants to use the same runtime.
Sure, but now if my rust application isn't using tokio I have to include it as a new dependency because the author of this lib decided to use it as his async runtime? I'm not trying to be pedantic, but this split over async runtimes was what originally turned me off of rust years ago and it still seems to be an issue.
Re: TurboKV: Insanely fast Rust key-value store
#50Earlier quoted context omitted.
Word choice matters. Defaults matter. People will go "well it says durable right here" and while arguably, yes, they should RTFM, it would still be great if tool-builders did not set the shotgun's default state to State::AT_FOOT. It would be nice if every paragraph of technical writing that I have to do need not be burdened by a thousand asterisks of "durable in this context means something other than durable".
>arguably, yes, they should RTFM Agreed. Good design is when the things do what you expect them to do without reading the manual, don't reuse wording with other meaning in the wrong way. That way if you do encounter nee wording, you know you should read the manual.