7 ms·

I don't want to flame, but I did find it curious they went with C rather than Rust. In my experience the transition is straightforward and the string handling (

I don't want to flame, but I did find it curious they went with C rather than Rust. In my experience the transition is straightforward and the string handling (particularly with unicode encodings) is way better (in addition to the normal ownership benefits), and the result (an easily linkable library exposing a C ABI) is roughly the same.

stefan_ 7y ago
Yes, and one library will be 100 MiB, the other 1.
- SomeOldThrow 7y ago
  A) disk space seems like a reasonable tradeoff for many situations, especially when binaries typically aren't the source of data consumption B) I don't think I've seen a rust binary more than 10 megs. Cargo, rust, and ripgrep are both about 6 mb on my disk; fd is 2.5mb. These seem like a reasonable standins for a binary of significant size and complexity. sqlite3 itself is about 1.3mb. C) Dqlite doesn't seem particularly concerned with disk-constrained systems, though I may be interpreting their site incorrectly, and the low footprint should be equally achievable with the rust runtime—surely the database itself would be a much larger concern. This just seems like an unusually good fit for the benefits of the language—reliable client glue you can import into many runtimes where being able to prove data flow would be an strong defensive coding pattern. That said, I think that C is a good, conservative approach here, I'm certainly not knocking anyone's judgement. Overall the parent poster is absolutely correct: there's a strong correlation between use of rust's type system and size of outputted code. EDIT: phrasing.
  - josegonzalez 7y ago
    > Dqlite is a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices. Seems like, at least for embedded devices, you'd want something as small as possible so as to avoid consuming all available disk (not to say any other language will balloon it significantly or not).
    - SomeOldThrow 7y ago
      I missed that it was primarily intended for embedded devices.
  - stefan_ 7y ago
    2.5 MiB is about what you expect the kernel size to be for an embedded device :) Everything is an embedded device nowadays, so for reference, if you buy a WiFi AP today and open it up, you're likely to find a 8 or 16 MiB NOR flash inside, maybe a 128 MiB NAND flash (with realistically 64 MiB space since it will be doing A/B updates). I don't think the database size is a big concern. For me the focus in dqlite is very much on the 'd' - you store atomic configuration data in there, it's not about throughput.
    - deleted 7y ago
      [deleted]
    - SomeOldThrow 7y ago
      For an embedded database, they could certainly emphasize that more.
- stjohnswarts 7y ago
  That's a gross exaggeration
tracker1 7y ago
I think it's pragmatism. There working two libraries that are already C. Also, a mentioned in another thread, type data couple bloat things a little, I think the specific statement is hyperbolic tough. My guess is their main goal was to use this in go, where they already have experienced go and C developers and adding a third language would muddy things.
- bb88 7y ago
  Yeah, I think that's correct too. But it made me think that a killer app for Rust would be this entire concept done in one embedded DB with bindings for most of the popular languages.
rdtsc 7y ago
Well they are patching SQLite and SQLite is written in C. So they'd have to maintain a C path, Rust code, and another layer of C API interface for client bindings, if I understood their architecture correctly.

stefan_ 7y ago

Yes, and one library will be 100 MiB, the other 1.

SomeOldThrow 7y ago
A) disk space seems like a reasonable tradeoff for many situations, especially when binaries typically aren't the source of data consumption B) I don't think I've seen a rust binary more than 10 megs. Cargo, rust, and ripgrep are both about 6 mb on my disk; fd is 2.5mb. These seem like a reasonable standins for a binary of significant size and complexity. sqlite3 itself is about 1.3mb. C) Dqlite doesn't seem particularly concerned with disk-constrained systems, though I may be interpreting their site incorrectly, and the low footprint should be equally achievable with the rust runtime—surely the database itself would be a much larger concern. This just seems like an unusually good fit for the benefits of the language—reliable client glue you can import into many runtimes where being able to prove data flow would be an strong defensive coding pattern. That said, I think that C is a good, conservative approach here, I'm certainly not knocking anyone's judgement. Overall the parent poster is absolutely correct: there's a strong correlation between use of rust's type system and size of outputted code. EDIT: phrasing.
- josegonzalez 7y ago
  > Dqlite is a fast, embedded, persistent SQL database with Raft consensus that is perfect for fault-tolerant IoT and Edge devices. Seems like, at least for embedded devices, you'd want something as small as possible so as to avoid consuming all available disk (not to say any other language will balloon it significantly or not).
  - SomeOldThrow 7y ago
    I missed that it was primarily intended for embedded devices.
- stefan_ 7y ago
  2.5 MiB is about what you expect the kernel size to be for an embedded device :) Everything is an embedded device nowadays, so for reference, if you buy a WiFi AP today and open it up, you're likely to find a 8 or 16 MiB NOR flash inside, maybe a 128 MiB NAND flash (with realistically 64 MiB space since it will be doing A/B updates). I don't think the database size is a big concern. For me the focus in dqlite is very much on the 'd' - you store atomic configuration data in there, it's not about throughput.
  - deleted 7y ago
    [deleted]
  - SomeOldThrow 7y ago
    For an embedded database, they could certainly emphasize that more.
stjohnswarts 7y ago
That's a gross exaggeration

tracker1 7y ago

I think it's pragmatism. There working two libraries that are already C. Also, a mentioned in another thread, type data couple bloat things a little, I think the specific statement is hyperbolic tough. My guess is their main goal was to use this in go, where they already have experienced go and C developers and adding a third language would muddy things.

bb88 7y ago
Yeah, I think that's correct too. But it made me think that a killer app for Rust would be this entire concept done in one embedded DB with bindings for most of the popular languages.

rdtsc 7y ago

Well they are patching SQLite and SQLite is written in C. So they'd have to maintain a C path, Rust code, and another layer of C API interface for client bindings, if I understood their architecture correctly.