10 ms·

Written in Rust™

by marcosdly 3y ago

Written in Rust™

vdfs 3y ago
unsafe fn main() { ... }
- eatonphil 3y ago
  Not that I see? https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/main.rs https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/...
  - topbanana 3y ago
    RocksDB is written in C++ and runs in-process. That's just like having a load of unsafe Rust code.
    - deleted 3y ago
      [deleted]
    - SableDb 3y ago
      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
xedrac 3y ago
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 3y ago
  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 https://github.com/spacejam/sled
  - SableDb 3y ago
    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 3y ago
  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" ?

Written in Rust™

vdfs 3y ago

unsafe fn main() { ... }

eatonphil 3y ago
Not that I see? https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/main.rs https://github.com/sabledb-io/sabledb/blob/main/sabledb/src/...
- topbanana 3y ago
  RocksDB is written in C++ and runs in-process. That's just like having a load of unsafe Rust code.
  - deleted 3y ago
    [deleted]
  - SableDb 3y ago
    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

xedrac 3y ago

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 3y ago
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 https://github.com/spacejam/sled
- SableDb 3y ago
  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 3y ago
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" ?