4 ms·

Different programming languages, same databases, same problems

Spivak 4y ago
The fact that the solution for everyone isn't "link against libmysql and write bindings so the interface is idiomatic to your language" will be a source of endless bugs.
- ComputerGuru 4y ago
  I mean, that's golang for you. While many other languages are plagued with NIH (I love rust, but it's very much guilty of this, often to avoid having to deal with non-native dependencies) they at least give you a feasible option of FFI while go is truly allergic to it.
  - dpifke 4y ago
    Why do you think CGo is not feasible?
    - bdhcuidbebe 4y ago
      FFI overhead
  - enneff 4y ago
    Not really? A cgo wrapper for SQLite is by far the most popular way to use SQLite in Go and it works great. But I think it’s a major design error to use FFI for a thin client library. You’re bringing in a whole other network stack for what should be some simple serialisation/deserialisation. Plus even if you were, say, linking against libmysql you’d still have a bunch of wrapper code to make it a nice API in whatever the host language may be. Not worth it.
- chrsig 4y ago
  1. That presumes linking against libmysql and making bindings won't be a source of endless bugs :) 2. One of the major pitfalls with linking against c libraries that do their own i/o is that they don't play nicely with the go scheduler. That means the goroutines blocking on a c i/o operation will occupy it's thread for the duration of the call.
- haileys 4y ago
  The GitHub Rails app did link against libmysql originally, via the Ruby bindings. This turned out to be a source of endless bugs, especially in dev envs, so in 2015 Brian Lopez and I built a new client library for the Rails app: https://github.blog/2022-08-25-introducing-trilogy-a-new-database-adapter-for-ruby-on-rails/ https://github.blog/2022-08-25-introducing-trilogy-a-new-dat... This article however is about Go, where linking to C libraries is often not the best approach, so the situation is a little different.
- sofixa 4y ago
  This has a significant usability issue. Static C libs usually have a bunch of static dependencies like libc which means you can't really update them without updating your whole OS. The Golang git package was unusable for multiple Debian versions because it relied on libgit which was missing some critical functions for multiple Debian major versions (e.g. Jessie and Stretch), which means for literally years.
- up2isomorphism 4y ago
  Because then you can not write a big blog post to show what you are doing.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]

The fact that the solution for everyone isn't "link against libmysql and write bindings so the interface is idiomatic to your language" will be a source of endless bugs.

ComputerGuru 4y ago
I mean, that's golang for you. While many other languages are plagued with NIH (I love rust, but it's very much guilty of this, often to avoid having to deal with non-native dependencies) they at least give you a feasible option of FFI while go is truly allergic to it.
- dpifke 4y ago
  Why do you think CGo is not feasible?
  - bdhcuidbebe 4y ago
    FFI overhead
- enneff 4y ago
  Not really? A cgo wrapper for SQLite is by far the most popular way to use SQLite in Go and it works great. But I think it’s a major design error to use FFI for a thin client library. You’re bringing in a whole other network stack for what should be some simple serialisation/deserialisation. Plus even if you were, say, linking against libmysql you’d still have a bunch of wrapper code to make it a nice API in whatever the host language may be. Not worth it.
chrsig 4y ago
1. That presumes linking against libmysql and making bindings won't be a source of endless bugs :) 2. One of the major pitfalls with linking against c libraries that do their own i/o is that they don't play nicely with the go scheduler. That means the goroutines blocking on a c i/o operation will occupy it's thread for the duration of the call.
haileys 4y ago
The GitHub Rails app did link against libmysql originally, via the Ruby bindings. This turned out to be a source of endless bugs, especially in dev envs, so in 2015 Brian Lopez and I built a new client library for the Rails app: https://github.blog/2022-08-25-introducing-trilogy-a-new-database-adapter-for-ruby-on-rails/ https://github.blog/2022-08-25-introducing-trilogy-a-new-dat... This article however is about Go, where linking to C libraries is often not the best approach, so the situation is a little different.
sofixa 4y ago
This has a significant usability issue. Static C libs usually have a bunch of static dependencies like libc which means you can't really update them without updating your whole OS. The Golang git package was unusable for multiple Debian versions because it relied on libgit which was missing some critical functions for multiple Debian major versions (e.g. Jessie and Stretch), which means for literally years.
up2isomorphism 4y ago
Because then you can not write a big blog post to show what you are doing.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]