3 ms·

I think https://gitlab.com/cznic/sqlite https://gitlab.com/cznic/sqlite has become pretty popular. It’s a pure go implementation

masklinn 5y ago
It is popular not because it's a good idea but because go: using cgo is a huge imposition, so recoding everything in go so it can be used from go is basically the norm. That is useless to sqlite itself, this exists only because of go's issues and is essentially unusable outside of the go ecosystem.
- pjmlp 5y ago
  Dislike for cgo, is similar to the old JNI displeasure, nowadays plenty of Java libraries don't have any issues making use of JNI. The only issue I see with cgo is that they decided to follow such path instead of a proper FFI declaration support like most languages. Even Java is now having such capability thanks Project Panama.
  - CraigJPerry 5y ago
    I’ve noticed cgo dependencies massively slow down compilation. E.g. the hugo project built with and without extended features. Build without and it’s all go, it compiles in the blink of an eye. The tooling in go, from a devops point of view, is surprisingly good. It’s not just compile speed. Build with all the c deps and well you’re compiling more code so of course it’s going to be slower but it’s disproportionately so.
  - nikki93 5y ago
    FWIW, the overhead of calls across the cgo barrier is quite high, which can have API architecture implications -- https://github.com/dyu/ffi-overhead#results-500m-calls https://github.com/dyu/ffi-overhead#results-500m-calls.
    - pjmlp 5y ago
      Just like JNI.
  - masklinn 5y ago
    > Dislike for cgo, is similar to the old JNI displeasure, nowadays plenty of Java libraries don't have any issues making use of JNI. Issue’s cgo doesn’t just make the build more complex and more expensive (and yeets cross-compilation), it also makes programming way more difficult as go tooling doesn’t understand C and C tooling has no clue about Go (because non-standard calling conventions and insular tooling community and everything), and for all that cost you get little because the go/c call overhead is stupendous (still, though smaller than it used to be), and of course it locks up the scheduler (after a slice of the goroutine being blocked the go runtime will create a new one, but still…).
    - pjmlp 5y ago
      All of that applies equally well to JNI.
      - masklinn 5y ago
        Absolutely not, java uses native threading so native calls don't generally break scheduling, and java uses native threading so while native calls have some overhead it's maybe 5x for no-op functions, it's nowhere near "two orders of magnitude".

masklinn 5y ago

It is popular not because it's a good idea but because go: using cgo is a huge imposition, so recoding everything in go so it can be used from go is basically the norm. That is useless to sqlite itself, this exists only because of go's issues and is essentially unusable outside of the go ecosystem.

pjmlp 5y ago
Dislike for cgo, is similar to the old JNI displeasure, nowadays plenty of Java libraries don't have any issues making use of JNI. The only issue I see with cgo is that they decided to follow such path instead of a proper FFI declaration support like most languages. Even Java is now having such capability thanks Project Panama.
- CraigJPerry 5y ago
  I’ve noticed cgo dependencies massively slow down compilation. E.g. the hugo project built with and without extended features. Build without and it’s all go, it compiles in the blink of an eye. The tooling in go, from a devops point of view, is surprisingly good. It’s not just compile speed. Build with all the c deps and well you’re compiling more code so of course it’s going to be slower but it’s disproportionately so.
- nikki93 5y ago
  FWIW, the overhead of calls across the cgo barrier is quite high, which can have API architecture implications -- https://github.com/dyu/ffi-overhead#results-500m-calls https://github.com/dyu/ffi-overhead#results-500m-calls.
  - pjmlp 5y ago
    Just like JNI.
- masklinn 5y ago
  > Dislike for cgo, is similar to the old JNI displeasure, nowadays plenty of Java libraries don't have any issues making use of JNI. Issue’s cgo doesn’t just make the build more complex and more expensive (and yeets cross-compilation), it also makes programming way more difficult as go tooling doesn’t understand C and C tooling has no clue about Go (because non-standard calling conventions and insular tooling community and everything), and for all that cost you get little because the go/c call overhead is stupendous (still, though smaller than it used to be), and of course it locks up the scheduler (after a slice of the goroutine being blocked the go runtime will create a new one, but still…).
  - pjmlp 5y ago
    All of that applies equally well to JNI.
    - masklinn 5y ago
      Absolutely not, java uses native threading so native calls don't generally break scheduling, and java uses native threading so while native calls have some overhead it's maybe 5x for no-op functions, it's nowhere near "two orders of magnitude".