3 ms·

There is something distasteful about this announcement but I can’t quite pinpoint it. Maybe it feels like a bait and switch announcing their own fork after the

by elteto 4y ago

There is something distasteful about this announcement but I can’t quite pinpoint it. Maybe it feels like a bait and switch announcing their own fork after the whole qemu commentary, or the wording about the code of conduct. I don’t know. One of the greatest things about SQLite is how easy it is to embed in random targets/build systems/languages: a .c and .h and you are all set. Moving away from that model will turn off many people away so I hope they retain that model.

ColonelPhantom 4y ago
The README has "Use Rust for new features" in it, so I doubt it will retain the same simplicity. As much as I like Rust, and despite mixing Rust and C++ being the clear path forward for Mozilla, I'm not so sure it's the winning approach here. Part of the beauty of SQLite is the single .c/.h thing. That said, I can see that maybe they're trying to expand the use cases of libsql compared to SQLite. That seems to be the whole idea with adding support for e.g. distributed databases, which is something SQLite just doesn't bother with at all, and would introduce a ton of external interfacing regarding networking. SQLite uses only the standard C library, and even then barely scratches its surface. Also, SQLite's VFS API can do a lot there already. For example, I remember seeing SQLite compiled to WASM, using a VFS that downloads a remote database on S3 using HTTP Range requests. (I don't think it supported writing to the database, but it was still a really cool way of allowing complex client-side querying of a dataset that is static but too big to transfer).
- sgbeal 4y ago
  > Part of the beauty of SQLite is the single .c/.h thing. Noting that it's not _developed_ that way. Its many files are compounded together by the build process to produce the amalgamation build. In a mixed-language project (Rust for some, C for others) a single-file distribution literally won't be possible and it will require as many toolchains to build as there are languages involved.
  - bpye 4y ago
    I wonder if mrustc [0] would be sufficient to retain the amalgamated build even if Rust were adopted. The regular Rust tool chain would be needed for development still, but if simply depending on the library the Rust components could be transpiled to C… [0] - https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
  - chasil 4y ago
    TH3 requires the components to be separate for testing. But that is not how it is meant to be used.
  - ReactiveJelly 4y ago
    > a single-file distribution literally won't be possible Actually. You could compile the Rust into Wasm, then the Wasm into C. Firefox did this last year [1], so the tools exist and it's neither totally impossible nor totally stupid. The penalty is less than JITting or interpreting Wasm. wasm2c is the tool they apparently used in 2021. [2] [1] https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... [2] https://github.com/WebAssembly/wabt/tree/main/wasm2c https://github.com/WebAssembly/wabt/tree/main/wasm2c > wasm2c takes a WebAssembly module and produces an equivalent C source and header.
- sgbeal 4y ago
  > Also, SQLite's VFS API can do a lot there already. For example, I remember seeing SQLite compiled to WASM, using a VFS that downloads a remote database on S3 using HTTP Range requests. (I don't think it supported writing to the database, but it was still a really cool way of allowing complex client-side querying of a dataset that is static but too big to transfer). <https://github.com/phiresky/sql.js-httpvfs https://github.com/phiresky/sql.js-httpvfs>
NoGravitas 4y ago
It also feels gross to me, but the only thing I can put my finger on is citing webshit as the reason to completely change the direction of a well-loved project.
- ReactiveJelly 4y ago
  But they aren't compelling the SQLite devs to do anything. If a fork catches on, then it's what people wanted. If it doesn't catch on, then let it fail.
  - dathinab 4y ago
    yup but more likely their changes will make it unusable for a bunch of SQLite use-cases, so if it catches on it will probably exist in parallel to SQLite and once it's realized they won't replace SQLite should increasingly diverge by focusing on it's core target audience.
hitekker 4y ago
Trust your gut. It's a public shaming campaign disguised as a history lesson. Glauber Costa is trying to seem welcoming in one breath and, in another breath, is sniping at the same people he claims to want to join. > We [Glauber Costa] take our code of conduct seriously, and unlike SQLite, we do not substitute it with an unclear alternative. We strive to foster a community that values diversity, equity, and inclusion. We encourage others to speak up if they feel uncomfortable. With zero new code to justify this fork, this article is little more than a silly power trip by a flailing startup.
- dathinab 4y ago
  They do have clear goals of what to add, their goals make somewhat sense for some use-cases. But pretty much all of them direct conflict with at least one and sometimes multiple SQLlite core principles... What the author wants as far as I can tell is a embedded distributed (edge) database with some C-API and SQL compatibility to SQLite so that you can use it with existing tooling (like e.g. by linking against it instead of sqlite) but not necessary as a drop in replacement (different transaction semantics), which doesn't need the same degree of portability as sqlite. Through that is not quite what the author ends up communicating in the article. I wonder what degree of the formulations are intentionally manipulative compared to accidentally badly formulated.
  - diffxx 4y ago
    Regardless of intention, the inability of the author to adequately explain why a fork was necessary, apart from some hand wavy arguments that some other solutions were inadequate, does not inspire confidence. I find it very hard to be generous with the author given the way that he paints himself as a visionary while casually dismissing the work and perspective of the people who actually did the real visionary work of seeding the technologies that he has hitched his wagon to.
throw_a_grenade 4y ago
> There is something distasteful about this announcement but I can’t quite pinpoint it. I think it's a general lack of gratefulness. The author considers sqlite as something to be taken without even saying thank you to drh. All he has to say is, that's a nice project you have there, it would be shame if something happened to it. Like to qemu.
- matheusmoreira 4y ago
  > The author considers sqlite as something to be taken without even saying thank you to drh. Well, it is in the public domain. Respecting and thanking people is of course a very nice thing to do but the fact is there are zero restrictions on what can be done with this software. > that's a nice project you have there, it would be shame if something happened to it That's always possible in all free and open source software development. Anyone can show up and just start working harder than whoever's currently in charge. Corporations can show up with paid full time developers and completely displace a project's leadership. Eventually the fork will accumulate so many improvements it will become the de facto upstream. It remains to be seen if this is what will happen to SQLite and this new libSQL. Who knows, right? I don't expect SQLite to go anywhere though.

by elteto 4y ago

ColonelPhantom 4y ago

The README has "Use Rust for new features" in it, so I doubt it will retain the same simplicity. As much as I like Rust, and despite mixing Rust and C++ being the clear path forward for Mozilla, I'm not so sure it's the winning approach here. Part of the beauty of SQLite is the single .c/.h thing. That said, I can see that maybe they're trying to expand the use cases of libsql compared to SQLite. That seems to be the whole idea with adding support for e.g. distributed databases, which is something SQLite just doesn't bother with at all, and would introduce a ton of external interfacing regarding networking. SQLite uses only the standard C library, and even then barely scratches its surface. Also, SQLite's VFS API can do a lot there already. For example, I remember seeing SQLite compiled to WASM, using a VFS that downloads a remote database on S3 using HTTP Range requests. (I don't think it supported writing to the database, but it was still a really cool way of allowing complex client-side querying of a dataset that is static but too big to transfer).

sgbeal 4y ago
> Part of the beauty of SQLite is the single .c/.h thing. Noting that it's not _developed_ that way. Its many files are compounded together by the build process to produce the amalgamation build. In a mixed-language project (Rust for some, C for others) a single-file distribution literally won't be possible and it will require as many toolchains to build as there are languages involved.
- bpye 4y ago
  I wonder if mrustc [0] would be sufficient to retain the amalgamated build even if Rust were adopted. The regular Rust tool chain would be needed for development still, but if simply depending on the library the Rust components could be transpiled to C… [0] - https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- chasil 4y ago
  TH3 requires the components to be separate for testing. But that is not how it is meant to be used.
- ReactiveJelly 4y ago
  > a single-file distribution literally won't be possible Actually. You could compile the Rust into Wasm, then the Wasm into C. Firefox did this last year [1], so the tools exist and it's neither totally impossible nor totally stupid. The penalty is less than JITting or interpreting Wasm. wasm2c is the tool they apparently used in 2021. [2] [1] https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/ https://hacks.mozilla.org/2021/12/webassembly-and-back-again... [2] https://github.com/WebAssembly/wabt/tree/main/wasm2c https://github.com/WebAssembly/wabt/tree/main/wasm2c > wasm2c takes a WebAssembly module and produces an equivalent C source and header.
sgbeal 4y ago
> Also, SQLite's VFS API can do a lot there already. For example, I remember seeing SQLite compiled to WASM, using a VFS that downloads a remote database on S3 using HTTP Range requests. (I don't think it supported writing to the database, but it was still a really cool way of allowing complex client-side querying of a dataset that is static but too big to transfer). <https://github.com/phiresky/sql.js-httpvfs https://github.com/phiresky/sql.js-httpvfs>

NoGravitas 4y ago

It also feels gross to me, but the only thing I can put my finger on is citing webshit as the reason to completely change the direction of a well-loved project.

ReactiveJelly 4y ago
But they aren't compelling the SQLite devs to do anything. If a fork catches on, then it's what people wanted. If it doesn't catch on, then let it fail.
- dathinab 4y ago
  yup but more likely their changes will make it unusable for a bunch of SQLite use-cases, so if it catches on it will probably exist in parallel to SQLite and once it's realized they won't replace SQLite should increasingly diverge by focusing on it's core target audience.

hitekker 4y ago

Trust your gut. It's a public shaming campaign disguised as a history lesson. Glauber Costa is trying to seem welcoming in one breath and, in another breath, is sniping at the same people he claims to want to join. > We [Glauber Costa] take our code of conduct seriously, and unlike SQLite, we do not substitute it with an unclear alternative. We strive to foster a community that values diversity, equity, and inclusion. We encourage others to speak up if they feel uncomfortable. With zero new code to justify this fork, this article is little more than a silly power trip by a flailing startup.

dathinab 4y ago
They do have clear goals of what to add, their goals make somewhat sense for some use-cases. But pretty much all of them direct conflict with at least one and sometimes multiple SQLlite core principles... What the author wants as far as I can tell is a embedded distributed (edge) database with some C-API and SQL compatibility to SQLite so that you can use it with existing tooling (like e.g. by linking against it instead of sqlite) but not necessary as a drop in replacement (different transaction semantics), which doesn't need the same degree of portability as sqlite. Through that is not quite what the author ends up communicating in the article. I wonder what degree of the formulations are intentionally manipulative compared to accidentally badly formulated.
- diffxx 4y ago
  Regardless of intention, the inability of the author to adequately explain why a fork was necessary, apart from some hand wavy arguments that some other solutions were inadequate, does not inspire confidence. I find it very hard to be generous with the author given the way that he paints himself as a visionary while casually dismissing the work and perspective of the people who actually did the real visionary work of seeding the technologies that he has hitched his wagon to.

throw_a_grenade 4y ago

> There is something distasteful about this announcement but I can’t quite pinpoint it. I think it's a general lack of gratefulness. The author considers sqlite as something to be taken without even saying thank you to drh. All he has to say is, that's a nice project you have there, it would be shame if something happened to it. Like to qemu.

matheusmoreira 4y ago
> The author considers sqlite as something to be taken without even saying thank you to drh. Well, it is in the public domain. Respecting and thanking people is of course a very nice thing to do but the fact is there are zero restrictions on what can be done with this software. > that's a nice project you have there, it would be shame if something happened to it That's always possible in all free and open source software development. Anyone can show up and just start working harder than whoever's currently in charge. Corporations can show up with paid full time developers and completely displace a project's leadership. Eventually the fork will accumulate so many improvements it will become the de facto upstream. It remains to be seen if this is what will happen to SQLite and this new libSQL. Who knows, right? I don't expect SQLite to go anywhere though.