4 ms·

What's the problem of linking against SQLite? In my book it's much better because: - SQLite is coded in C, so performance and weight are going to be equal or b

by Ecco 6y ago

What's the problem of linking against SQLite? In my book it's much better because: - SQLite is coded in C, so performance and weight are going to be equal or better than any other reimplementation. - Having one code base means no compatibility issue between implementations - Also SQLite's codebase is so heavily tested and its track record is so good that I really don't see the point.

pvg 6y ago
https://www.zdnet.com/article/google-chrome-impacted-by-new-magellan-2-0-vulnerabilities/ https://www.zdnet.com/article/google-chrome-impacted-by-new-...
- sigzero 6y ago
  He didn't say it never has bugs. It does have a great track record and Dr. Hipp fixes things quickly when found.
- cowsandmilk 6y ago
  If there were implementations of SQLite in other languages, do you believe chrome would have used a different implementation?
  - pvg 6y ago
    I don't know! But if this sort of thing can happen in Chrome, I think it's a pretty strong counterargument to "let's standardize formats in terms of a C implementation of a thing that parses a complicated language, among many other things".
    - rhencke 6y ago
      XML has been a source of countless vulnerabilities, yet we continue to use it as a standard.
      - pvg 6y ago
        XML has its own problems but 'has a single canonical implementation in a big hairball of C' is not among them.
      - viraptor 6y ago
        Non-C implementations of XML don't have countless vulnerabilities. There's XXE and schema requests which are language independent, but otherwise... it's ok.
gwd 6y ago
FWIW I've used golang linking against sqlite in a couple of my projects. One issue is that linking through cgo is really slow, due to the fact that the runtime has no idea anything about types. Probably OK if you're just doing basic queries at a reasonable rate; but if you implement a custom callback, suddenly all the marshaling back and forth takes a huge amount of time. Not a deal-breaker; but a native implementation of sqlite in golang would be a lot nicer.
- 0xjnml 6y ago
  > Not a deal-breaker; but a native implementation of sqlite in golang would be a lot nicer. CGo-free SQLite for Linux: https://godoc.org/modernc.org/sqlite https://godoc.org/modernc.org/sqlite
sargun 6y ago
I'll give a couple examples of where I've needed a K/V database, but linking caused problems: * We have a sandboxed Javascript runtime inside of the JVM that can only do restricted work. IT would be nice to be able to use something like a SQLite file to deliver configuration to this Javascript runtime * There are environments where you cannot install any native code -- like serverless providers that require your software to be pure Java / Javascript / Python * Cross-language debugging can be very difficult when something goes wrong * Erlang's FFI model is either "blocking and fast" (it runs the FFI call inline, and halts preemptive multitasking), or "slow and safe" (dirty NIFs, where it runs FFI calls on a dedicated thread.) This can get really ugly, really quickly.

by Ecco 6y ago

pvg 6y ago

https://www.zdnet.com/article/google-chrome-impacted-by-new-magellan-2-0-vulnerabilities/ https://www.zdnet.com/article/google-chrome-impacted-by-new-...

sigzero 6y ago
He didn't say it never has bugs. It does have a great track record and Dr. Hipp fixes things quickly when found.
cowsandmilk 6y ago
If there were implementations of SQLite in other languages, do you believe chrome would have used a different implementation?
- pvg 6y ago
  I don't know! But if this sort of thing can happen in Chrome, I think it's a pretty strong counterargument to "let's standardize formats in terms of a C implementation of a thing that parses a complicated language, among many other things".
  - rhencke 6y ago
    XML has been a source of countless vulnerabilities, yet we continue to use it as a standard.
    - pvg 6y ago
      XML has its own problems but 'has a single canonical implementation in a big hairball of C' is not among them.
    - viraptor 6y ago
      Non-C implementations of XML don't have countless vulnerabilities. There's XXE and schema requests which are language independent, but otherwise... it's ok.

gwd 6y ago

FWIW I've used golang linking against sqlite in a couple of my projects. One issue is that linking through cgo is really slow, due to the fact that the runtime has no idea anything about types. Probably OK if you're just doing basic queries at a reasonable rate; but if you implement a custom callback, suddenly all the marshaling back and forth takes a huge amount of time. Not a deal-breaker; but a native implementation of sqlite in golang would be a lot nicer.

0xjnml 6y ago
> Not a deal-breaker; but a native implementation of sqlite in golang would be a lot nicer. CGo-free SQLite for Linux: https://godoc.org/modernc.org/sqlite https://godoc.org/modernc.org/sqlite

sargun 6y ago

I'll give a couple examples of where I've needed a K/V database, but linking caused problems: * We have a sandboxed Javascript runtime inside of the JVM that can only do restricted work. IT would be nice to be able to use something like a SQLite file to deliver configuration to this Javascript runtime * There are environments where you cannot install any native code -- like serverless providers that require your software to be pure Java / Javascript / Python * Cross-language debugging can be very difficult when something goes wrong * Erlang's FFI model is either "blocking and fast" (it runs the FFI call inline, and halts preemptive multitasking), or "slow and safe" (dirty NIFs, where it runs FFI calls on a dedicated thread.) This can get really ugly, really quickly.