5 ms·

> Automatic transcription is the best way forward, the performance hit (when you want to avoid cgo) be damned But if performance is worse than the C wrapper, t

> Automatic transcription is the best way forward, the performance hit (when you want to avoid cgo) be damned But if performance is worse than the C wrapper, there is surely no point whatsoever for such a native version to exist? Isn't the whole point of a native Go/whatever version to avoid the interop penalty? > The C version is very well tested Couldn't the same test suite be used for a Go/whatever rewrite, or at least be ported to Go too?

tgv 4y ago
> there is surely no point whatsoever for such a native version to exist If you want to avoid cgo. There are two reasons for that: easy cross-compilation, and https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go > Couldn't the same test suite be used for a Go/whatever rewrite, or at least be ported to Go too? And then port each and every update as well? The only use of such a rewrite is performance improvement in go programs. Surely improving the c-to-go compiler is a better investment of effort? It would benefit other projects too. Rewriting sqlite in go will only lead to less effort on the c-to-go compiler.
hexmiles 4y ago
> Isn't the whole point of a native Go/whatever version to avoid the interop penalty? CGO require a c compiler (not always easy available) and make cross-compilation harder
- c0balt 4y ago
  Dumb question, on which system with a go compiler is a C compiler hard to install? Most *nix distros either come with gcc (and/ or clang) already or have it easily available as a package. AFAIK the same is applicable for MacOS with homebrew. Is this a problem for windows users or am I overlooking someone? I'm genuinly interested since I've recently started with Go and would like to use cgo in the future.
  - hexmiles 4y ago
    My primary use case is windows and embedded. Also sometimes while the compiler is easy to install, make c compilation work seamlessly across multiple machine with unreliable vendor toolchain or weird path issue where the compiler can't find the correct header/library are not that uncommon.
    - c0balt 4y ago
      Thank you for your response and perspective. I didn't consider the various toolchains and environments from this POV. Your points make sense and are very helpful.
- fileeditview 4y ago
  It also makes it harder to debug or do performance profiling. Or to manage builds in CI/CD.. there is a lot of cost to CGO. I still would not rewrite SQLite. It's just too good how it is.

tgv 4y ago

> there is surely no point whatsoever for such a native version to exist If you want to avoid cgo. There are two reasons for that: easy cross-compilation, and https://dave.cheney.net/2016/01/18/cgo-is-not-go https://dave.cheney.net/2016/01/18/cgo-is-not-go > Couldn't the same test suite be used for a Go/whatever rewrite, or at least be ported to Go too? And then port each and every update as well? The only use of such a rewrite is performance improvement in go programs. Surely improving the c-to-go compiler is a better investment of effort? It would benefit other projects too. Rewriting sqlite in go will only lead to less effort on the c-to-go compiler.

hexmiles 4y ago

> Isn't the whole point of a native Go/whatever version to avoid the interop penalty? CGO require a c compiler (not always easy available) and make cross-compilation harder

c0balt 4y ago
Dumb question, on which system with a go compiler is a C compiler hard to install? Most *nix distros either come with gcc (and/ or clang) already or have it easily available as a package. AFAIK the same is applicable for MacOS with homebrew. Is this a problem for windows users or am I overlooking someone? I'm genuinly interested since I've recently started with Go and would like to use cgo in the future.
- hexmiles 4y ago
  My primary use case is windows and embedded. Also sometimes while the compiler is easy to install, make c compilation work seamlessly across multiple machine with unreliable vendor toolchain or weird path issue where the compiler can't find the correct header/library are not that uncommon.
  - c0balt 4y ago
    Thank you for your response and perspective. I didn't consider the various toolchains and environments from this POV. Your points make sense and are very helpful.
fileeditview 4y ago
It also makes it harder to debug or do performance profiling. Or to manage builds in CI/CD.. there is a lot of cost to CGO. I still would not rewrite SQLite. It's just too good how it is.