6 ms·

Well done, I'm excited about efforts like this and I hope you make progress towards some production traffic (I'm aware it is a toy, but toys are best when used

Well done, I'm excited about efforts like this and I hope you make progress towards some production traffic (I'm aware it is a toy, but toys are best when used by others :) )

netsec_burn 5y ago
As a Rust developer (that's up to their neck in Rust projects) I'm really looking forward to a functioning sqlite clone. To the best of my knowledge, Sqlrite (https://github.com/joaoh82/rust_sqlite https://github.com/joaoh82/rust_sqlite) was supposed to be that but it ended up diverging from sqlite. It'll make cross platform Rust builds easier.
- pm90 5y ago
  I’m curious to understand what you’re looking to benefit from with a SQLite rust clone vs SQLite itself? Would it make writing apps easier? Or would it open up the internals of dB engines to rust developers? Or something else..? Honest question.
  - netsec_burn 5y ago
    I think I answered your question in my comment, no? It'll make cross platform builds easier instead of the current steps needed for FFI libraries. My experience with cross platform FFI builds are slim but last time I tried it, it was painful (versus Rust handling it all with the right toolchain).
    - ofrzeta 5y ago
      Can't be as hard as reimplementing SQLite, can it?
      - wizzwizz4 5y ago
        But reimplementing SQLite can be done by somebody else, whereas dealing with FFI must be done by me.
        azornathogron 5y ago
        I feel like I must be misunderstanding you... why would the FFI be done by you? The rusqlite crate provides wrappers you can use, and there are probably other wrapper crates that I haven't looked at.
        netsec_burn 5y ago
        Not the parent comment, but I believe they're referring to the cross compilation aspects which wouldn't be resolved by just using the rusqlite crate (I use rusqlite and have this issue).
        wizzwizz4 5y ago
        But I have to configure how it finds SQLite. Sure, SQLite specifically is fairly easy – I only need to enable the "bundled" crate feature and make sure my Clang version matches the Rust version so LTO works – but it's a little arcane to use Cargo with any non-Rust package in the dependency chain. Cargo Just Works™. Cargo with C FFI doesn't.
        azornathogron 5y ago
        Thanks for the explanation!
- fsloth 5y ago
  Sqlite has been battletested for years. I utterly fail to see the point in reimplementing it in some other language. Innovate in databases - yes please - but "rewrite" - why? Not being able to use battletested libraries written in plain C (e.g. sqlite) sounds like a hugh mark against rust as a systems programming language. Is using C libraries an actual issue or just an aesthetic grumble?
  - simlevesque 5y ago
    > battletested Is software that is always evolving battletested ? A new version could break something. I'm aware that sqlite has one of the best test suite in all of open source, I just wonder if something that was "battletested" is still battletested after a new release.
    - lukevp 5y ago
      I guess we can’t speak about battle testing in a new release from a “running in production with real user workloads” but if the test suite is properly implemented and has good coverage and exercises many cases and failure modes, it’s possible that a SQLite release is more battle tested on day zero than other software is when it’s been running for months or years. What do you think? A new version presumably still runs through validation before release.
    - ithkuil 5y ago
      Here's where the asymmetry of security bugs and feature bugs comes into play. Introducing a buffer overflow in a small unused corner / edge case of the feature set allows an attacker to fully compromise the process, and it's thus a problem affecting a 100% of the users. Introducing a behavioral bug in the same unused corner / edge case, will affect only a very small number if people (possibly none)
    - jasonwatkinspdx 5y ago
      Freezing the software is no assurance of security either. I'll take ongoing maintenance of the quality of sqlite every time personally.
    - deleted 5y ago
- hxzhao 5y ago
  the RIIR fallacy, again
  - xpe 5y ago
    > the RIIR fallacy, again AYATAINWK? Are You Aware That Acronym Is Not Widely Known?
    - NoahKAndrews 5y ago
      I believe it's Rewrite it in Rust
      - xpe 5y ago
        Ah, there is nothing like perjorative acronyms ... they seem to be designed to shut down thinking rather than invite more of it. Let's not forget that: 1. new programming languages bring excitement, creative destruction, and yes, lots of hobby projects that don't turn into battle-tested products. I'm ok with that. 2. rewriting is not the same as re-envisioning. See the comment above. SQLite was a starting point for inspiration, not the destination. Also, we should not conflate an underlying technology with the hype around that technology: a. Just because there is a lot of hype around Rust does not mean the advantages of Rust should be overlooked b. Some highly-praised technologies deserve the praise. Yes, sometimes even the cynics are wrong.

Well done, I'm excited about efforts like this and I hope you make progress towards some production traffic (I'm aware it is a toy, but toys are best when used by others :) )

netsec_burn 5y ago

As a Rust developer (that's up to their neck in Rust projects) I'm really looking forward to a functioning sqlite clone. To the best of my knowledge, Sqlrite (https://github.com/joaoh82/rust_sqlite https://github.com/joaoh82/rust_sqlite) was supposed to be that but it ended up diverging from sqlite. It'll make cross platform Rust builds easier.

pm90 5y ago
I’m curious to understand what you’re looking to benefit from with a SQLite rust clone vs SQLite itself? Would it make writing apps easier? Or would it open up the internals of dB engines to rust developers? Or something else..? Honest question.
- netsec_burn 5y ago
  I think I answered your question in my comment, no? It'll make cross platform builds easier instead of the current steps needed for FFI libraries. My experience with cross platform FFI builds are slim but last time I tried it, it was painful (versus Rust handling it all with the right toolchain).
  - ofrzeta 5y ago
    Can't be as hard as reimplementing SQLite, can it?
    - wizzwizz4 5y ago
      But reimplementing SQLite can be done by somebody else, whereas dealing with FFI must be done by me.
      - azornathogron 5y ago
        I feel like I must be misunderstanding you... why would the FFI be done by you? The rusqlite crate provides wrappers you can use, and there are probably other wrapper crates that I haven't looked at.
        netsec_burn 5y ago
        Not the parent comment, but I believe they're referring to the cross compilation aspects which wouldn't be resolved by just using the rusqlite crate (I use rusqlite and have this issue).
        wizzwizz4 5y ago
        But I have to configure how it finds SQLite. Sure, SQLite specifically is fairly easy – I only need to enable the "bundled" crate feature and make sure my Clang version matches the Rust version so LTO works – but it's a little arcane to use Cargo with any non-Rust package in the dependency chain. Cargo Just Works™. Cargo with C FFI doesn't.
        azornathogron 5y ago
        Thanks for the explanation!
fsloth 5y ago
Sqlite has been battletested for years. I utterly fail to see the point in reimplementing it in some other language. Innovate in databases - yes please - but "rewrite" - why? Not being able to use battletested libraries written in plain C (e.g. sqlite) sounds like a hugh mark against rust as a systems programming language. Is using C libraries an actual issue or just an aesthetic grumble?
- simlevesque 5y ago
  > battletested Is software that is always evolving battletested ? A new version could break something. I'm aware that sqlite has one of the best test suite in all of open source, I just wonder if something that was "battletested" is still battletested after a new release.
  - lukevp 5y ago
    I guess we can’t speak about battle testing in a new release from a “running in production with real user workloads” but if the test suite is properly implemented and has good coverage and exercises many cases and failure modes, it’s possible that a SQLite release is more battle tested on day zero than other software is when it’s been running for months or years. What do you think? A new version presumably still runs through validation before release.
  - ithkuil 5y ago
    Here's where the asymmetry of security bugs and feature bugs comes into play. Introducing a buffer overflow in a small unused corner / edge case of the feature set allows an attacker to fully compromise the process, and it's thus a problem affecting a 100% of the users. Introducing a behavioral bug in the same unused corner / edge case, will affect only a very small number if people (possibly none)
  - jasonwatkinspdx 5y ago
    Freezing the software is no assurance of security either. I'll take ongoing maintenance of the quality of sqlite every time personally.
  - deleted 5y ago
hxzhao 5y ago
the RIIR fallacy, again
- xpe 5y ago
  > the RIIR fallacy, again AYATAINWK? Are You Aware That Acronym Is Not Widely Known?
  - NoahKAndrews 5y ago
    I believe it's Rewrite it in Rust
    - xpe 5y ago
      Ah, there is nothing like perjorative acronyms ... they seem to be designed to shut down thinking rather than invite more of it. Let's not forget that: 1. new programming languages bring excitement, creative destruction, and yes, lots of hobby projects that don't turn into battle-tested products. I'm ok with that. 2. rewriting is not the same as re-envisioning. See the comment above. SQLite was a starting point for inspiration, not the destination. Also, we should not conflate an underlying technology with the hype around that technology: a. Just because there is a lot of hype around Rust does not mean the advantages of Rust should be overlooked b. Some highly-praised technologies deserve the praise. Yes, sometimes even the cynics are wrong.