[marcosdly]

Written in Rust™

[xedrac]

So it's a Redis API written in Rust, but the underlying database is all C++. It seems like a nice project, but perhaps a little misleading to say it's written in Rust.

[zackangelo]

If anyone is interested in a Rust-based on-disk KV store, I've come across sled[0] a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well.

[0] https://github.com/spacejam/sled

[SableDb]

See my previous comment. Sled was considered, and it was the main KV storage in early implementation.

I kept the adapter approach in the code, so switching back to sled should be pretty easy (or even converting it to full in-memory)

[SableDb]

The storage itself uses the rust binding for RocksDb

However, I did have a branch (in another repo) that uses other different storage, some are purely written in Rust, like "dash" (which is full in-memory), "sled" and "speedb". I eventually decided to stick with RocksDb since its well mature and maintained by some giant companies like Meta.

The user code (the one I wrote) is all Rust.

Also, one could also argue that the `bytes` crate that is heavily utilized in the code base of SableDb, uses plenty of `unsafe` code, does this make it less "Rust" ?

[vdfs]

    unsafe fn main() {
        ...
    }

[eatonphil]

Not that I see?

https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/...

[topbanana]

RocksDB is written in C++ and runs in-process. That's just like having a load of unsafe Rust code.

[SableDb]

So does OpenSSL, Bytes crates, WinAPI and many many other crates used by many Rust applications. Does this make applications written in Rust less "Rusties"?

IMO, the networking, threading and "tasks" ("green threads") in SableDb code base are the most risky part of writing a server and by choosing Rust, the risk of memory issues is reduced to minimum without scarifying performance