6 ms·

Basically a throwaway comment that is somewhat off topic, but your current Github README is very "inside baseball." I think it would be worth a one-sentence int

Basically a throwaway comment that is somewhat off topic, but your current Github README is very "inside baseball." I think it would be worth a one-sentence introduction to what your library can do (allows an app to incorporate a database, and it also has compatibility with a very popular library called SQLite, etc), then to tout the benefits of not requiring CGO, etc.

KingOfCoders 3y ago
I think when you create a website (write a document, write a README) it is important to imagine the top 3 reader/visitor personas. What do they want from the README (website)? 1. Go+SQLite user: No CGO 2. Go user 3. Wanting to use the library 4. Someone following a link from HN 5. ...
- carbocation 3y ago
  Agreed, although I think a brief one-line intro to what this thing does wouldn't really interrupt the flow for any of the above use-cases. Right now, the top of the README is a list of sub-libraries, listing the library first. Personally, I would add ~2 sentences in the order I outlined, and then I would reorient the list (currently library-first) in a use-case first arrangement like you mentioned. I mean, realistically my git repos are a mess, so who am I to talk? But this one looks promising enough such that it's worth offering a bit of feedback.
  - KingOfCoders 3y ago
    Agree, 4. Someone following a link from HN I'm often confused when clicking through from HN and can't figure out from the website or README what the project is doing.
  - ncruces 3y ago
    Thank you for the feedback! I tried to improve the copy a bit, but this is clearly not my thing…
- trevyn 3y ago
  Sometimes you want people who don’t get it to bounce. Keeps the signal to noise ratio higher.
deleted 3y ago
[deleted]
acqq 3y ago
I'd like to read what the actual benefits of not linking to C sqlite implementation are. I can imagine using wazero.io for libraries, but I fail to understand _why_ would anybody prefer to run sqlite that way from their own go program, except if it's in cases where execution times are clearly not important (which explains to me the background story).
- ncruces 3y ago
  The major one is (cross) compilation and portability. You can (e.g.) easily whip up a small CLI that embeds an SQLite database in the binary [1], cross compile this to all the platforms Go supports [2], copy one file, and be reasonably sure it'll run in any of them. This is an example of embedding a database in a binary (with go:embed), and opening it for reading/writing in memory. You can then save the modified copy to disk using the backup API: [1]: https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/memdb#example-package https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/memdb#e... [2]: https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63#platform-values https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b...
  - acqq 3y ago
    I'm still missing some details to understand that story, as I don't believe that there is any platform that Go supports on which C sqlite would not run, more the opposite, the memory requirements of wazero.io way must be clearly higher than of the C sqlite library? It seems to me it's not about would C sqlite run or not on that platform but that there is still some other convenience, and that's what I'd still like to learn, as I'm sure ncruces does solve some specific problem.
    - ncruces 3y ago
      To compile C for a given platform, you need a C compiler for that platform. Which definitely exists but you may not have it at hand. To cross compile from your platform A to that platform B, you need a cross compiler, which may be even harder to come by. If you're working on a Go project, you already have a Go compiler that can do this (cross compilation) very easily, out of the box. But if you add a C dependency, you also need a C cross compiler. SQLite is easy to configure, and very portable, but this still adds some friction. Then if you want to setup CI, you need all this infra in CI. If you want to automate releases for a bunch of platforms, you need all of it in your release process. I'm not saying it's a huge pain but it's enough that some projects avoid cgo as a matter of principle.

KingOfCoders 3y ago

I think when you create a website (write a document, write a README) it is important to imagine the top 3 reader/visitor personas. What do they want from the README (website)? 1. Go+SQLite user: No CGO 2. Go user 3. Wanting to use the library 4. Someone following a link from HN 5. ...

carbocation 3y ago
Agreed, although I think a brief one-line intro to what this thing does wouldn't really interrupt the flow for any of the above use-cases. Right now, the top of the README is a list of sub-libraries, listing the library first. Personally, I would add ~2 sentences in the order I outlined, and then I would reorient the list (currently library-first) in a use-case first arrangement like you mentioned. I mean, realistically my git repos are a mess, so who am I to talk? But this one looks promising enough such that it's worth offering a bit of feedback.
- KingOfCoders 3y ago
  Agree, 4. Someone following a link from HN I'm often confused when clicking through from HN and can't figure out from the website or README what the project is doing.
- ncruces 3y ago
  Thank you for the feedback! I tried to improve the copy a bit, but this is clearly not my thing…
trevyn 3y ago
Sometimes you want people who don’t get it to bounce. Keeps the signal to noise ratio higher.

deleted 3y ago

[deleted]

acqq 3y ago

I'd like to read what the actual benefits of not linking to C sqlite implementation are. I can imagine using wazero.io for libraries, but I fail to understand _why_ would anybody prefer to run sqlite that way from their own go program, except if it's in cases where execution times are clearly not important (which explains to me the background story).

ncruces 3y ago
The major one is (cross) compilation and portability. You can (e.g.) easily whip up a small CLI that embeds an SQLite database in the binary [1], cross compile this to all the platforms Go supports [2], copy one file, and be reasonably sure it'll run in any of them. This is an example of embedding a database in a binary (with go:embed), and opening it for reading/writing in memory. You can then save the modified copy to disk using the backup API: [1]: https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/memdb#example-package https://pkg.go.dev/github.com/ncruces/go-sqlite3/vfs/memdb#e... [2]: https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b8aede63#platform-values https://gist.github.com/asukakenji/f15ba7e588ac42795f421b48b...
- acqq 3y ago
  I'm still missing some details to understand that story, as I don't believe that there is any platform that Go supports on which C sqlite would not run, more the opposite, the memory requirements of wazero.io way must be clearly higher than of the C sqlite library? It seems to me it's not about would C sqlite run or not on that platform but that there is still some other convenience, and that's what I'd still like to learn, as I'm sure ncruces does solve some specific problem.
  - ncruces 3y ago
    To compile C for a given platform, you need a C compiler for that platform. Which definitely exists but you may not have it at hand. To cross compile from your platform A to that platform B, you need a cross compiler, which may be even harder to come by. If you're working on a Go project, you already have a Go compiler that can do this (cross compilation) very easily, out of the box. But if you add a C dependency, you also need a C cross compiler. SQLite is easy to configure, and very portable, but this still adds some friction. Then if you want to setup CI, you need all this infra in CI. If you want to automate releases for a bunch of platforms, you need all of it in your release process. I'm not saying it's a huge pain but it's enough that some projects avoid cgo as a matter of principle.