Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TurboKV: Insanely fast Rust key-value store

github.com

Post reply on HN
Print view View original

51–60 of 89 posts

Re: TurboKV: Insanely fast Rust key-value store

#51

Post by tinco »

DarmokTanagra wrote: post #45
insanitybit wrote: post #43

Earlier 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.

It's not pedantry, you're trying to find something in Rust that's simply not there. If this sort of thing turns you off on Rust you should be looking at a programming language with other priorities.

Re: TurboKV: Insanely fast Rust key-value store

#52

Post by derriz »

DarmokTanagra wrote: post #45
insanitybit wrote: post #43

Earlier 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.

I’ve had the same reaction. We’ve seen this play out in other language eco-systems (Java - JAXP, javax.validation, JPA, etc all ended up with a de facto single implementation) and the idea of pluggable implementations sounds appealing but rarely pays off. The price that Rust paid for this abstraction - which in fact ended up not being useful as tokio is the only reasonable choice - was high in terms of requiring ugly (to my eyes) changes to its type system.

Re: TurboKV: Insanely fast Rust key-value store

#53

Post by insanitybit »

DarmokTanagra wrote: post #45
insanitybit wrote: post #43

Earlier 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.

You would only have to include it if the library uses `spawn`, as far as I am aware, or some tokio specific type, which is the same as any other library.

Re: TurboKV: Insanely fast Rust key-value store

#54

Post by insanitybit »

derriz wrote: post #52
DarmokTanagra wrote: post #45

Earlier quoted context omitted.

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.

I’ve had the same reaction. We’ve seen this play out in other language eco-systems (Java - JAXP, javax.validation, JPA, etc all ended up with a de facto single implementation) and the idea of pluggable implementations sounds appealing but rarely pays off. The price that Rust paid for this abstraction - which in fact ended up not being useful as tokio is the only reasonable choice - was high in terms of requiring ugly…

There is no price to pay on the type system that was imposed by tokio. I assume you're saying something like "I have to add 'static in generics" or something?

It has absolutely paid off, there are many people not using tokio.

Re: TurboKV: Insanely fast Rust key-value store

#56

Post by itemize123 »

nine_k wrote: post #2

I suppose the insane speed is due to this: > TurboKV's persisted Bloom-filter format uses hardware AES. Also, built-in LZ4 compression. I would expect SIMD to be used for scans.

that's optimizing a pretty fast already portion of code. unlikely it's the difference maker.

Re: TurboKV: Insanely fast Rust key-value store

#57

Post by VorpalWay »

derriz wrote: post #52
DarmokTanagra wrote: post #45

Earlier quoted context omitted.

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.

I’ve had the same reaction. We’ve seen this play out in other language eco-systems (Java - JAXP, javax.validation, JPA, etc all ended up with a de facto single implementation) and the idea of pluggable implementations sounds appealing but rarely pays off. The price that Rust paid for this abstraction - which in fact ended up not being useful as tokio is the only reasonable choice - was high in terms of requiring ugly…

Tokio is definitely not the only reasonable choice. I use embassy[1] on microcontrollers (the Pi Pico and ESP32 in my case), where tokio can't run.

[1] https://embassy.dev/

Re: TurboKV: Insanely fast Rust key-value store

#58

Post by zbentley »

taneq wrote: post #10
bestouff wrote: post #9

Earlier quoted context omitted.

I said elsewhere this doesn't survive a power loss.

While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes? Of course, if you need SIL2 type reliability then you need to assume any given hardware component can spontaneously combust and become a total loss, at which point the data loss caused by a power cut is a rounding error.

A UPS won’t save you from a kernel panic.

Re: TurboKV: Insanely fast Rust key-value store

#59

Post by kshri24 »

DarmokTanagra wrote: post #42

Off 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.

I prefer compio over tokio. So would not want libs to depend on a library that is essentially a runtime. Runtimes should be swappable.
Post reply on HN