4 ms·

Why would you want to do this? SQLLITE is so stable. Why would you switch to some port that will be dead in a year?

by tetete 3y ago

LVB 3y ago
The project converts the SQLite C code and has been kept very up to date, so it is far more than a one-off port. The reason is to avoid dealing with CGO in your project, which is necessary with other drivers such as mattn/go-sqlite3.
masklinn 3y ago
Implementation decisions of Go have various advantages in terms of control and memory use but they make linking to binary artefacts problematic. Not complicated, but it impacts the toll chain’s flexibility drastically. The FFI is also extremely slow. That is why the go ecosystem tends to reimplement everything in go.
jjgreen 3y ago
C has no telemetry
lanstin 3y ago
Each call out to a C library from Go locks an OS thread rather than participating in the go routine scheduling. If stuff happens that makes those threads slow or have some issue, they just sit here. I had a server with C Kafka libraries and each time the network glitched the CPU would spike up wards and not decline. With pure go the scheduler is able to just swap out and ignore code that is stuck some where (unless it were in a busy loop). With this SQLite implementation I can stick it in my server (as a background, near real time mirror of memory state to disk) without worrying that the main loop will get clogged or my real time path will be hurt. I use glabarez’ wrapper which makes it have an API like other Go databases: https://github.com/glebarez/sqlite/ https://github.com/glebarez/sqlite/ and hey have been very responsive to issues I raised. I have been running load tests against it for a few weeks, and it is quite solid.
- cube2222 3y ago
  Worth noting that busy loops are handled as well since 1.18.
- pkolaczk 3y ago
  Doesn't Go runtime offer anything like spawn_blocking in Rust async runtimes? Spawn_blocking allows to run any blocking operation without blocking the main executor threads, by spawning blocking operation into a separate thread-pool. This way there is no reason to worry "that the main loop will get clogged or my real time path will be hurt."

Why would you want to do this? SQLLITE is so stable. Why would you switch to some port that will be dead in a year?

by tetete 3y ago

Why would you want to do this? SQLLITE is so stable. Why would you switch to some port that will be dead in a year?

LVB 3y ago

The project converts the SQLite C code and has been kept very up to date, so it is far more than a one-off port. The reason is to avoid dealing with CGO in your project, which is necessary with other drivers such as mattn/go-sqlite3.

masklinn 3y ago

Implementation decisions of Go have various advantages in terms of control and memory use but they make linking to binary artefacts problematic. Not complicated, but it impacts the toll chain’s flexibility drastically. The FFI is also extremely slow. That is why the go ecosystem tends to reimplement everything in go.

jjgreen 3y ago

C has no telemetry

lanstin 3y ago

Each call out to a C library from Go locks an OS thread rather than participating in the go routine scheduling. If stuff happens that makes those threads slow or have some issue, they just sit here. I had a server with C Kafka libraries and each time the network glitched the CPU would spike up wards and not decline. With pure go the scheduler is able to just swap out and ignore code that is stuck some where (unless it were in a busy loop). With this SQLite implementation I can stick it in my server (as a background, near real time mirror of memory state to disk) without worrying that the main loop will get clogged or my real time path will be hurt. I use glabarez’ wrapper which makes it have an API like other Go databases: https://github.com/glebarez/sqlite/ https://github.com/glebarez/sqlite/ and hey have been very responsive to issues I raised. I have been running load tests against it for a few weeks, and it is quite solid.

cube2222 3y ago
Worth noting that busy loops are handled as well since 1.18.
pkolaczk 3y ago
Doesn't Go runtime offer anything like spawn_blocking in Rust async runtimes? Spawn_blocking allows to run any blocking operation without blocking the main executor threads, by spawning blocking operation into a separate thread-pool. This way there is no reason to worry "that the main loop will get clogged or my real time path will be hurt."