Hacker News Reader

Comment by tgv | Hacker News Reader

I don't hope someone is going to attempt to rewrite sqlite in go. The C version is very well tested. A rewrite can only add bugs. Automatic transcription is the best way forward, the performance hit (when you want to avoid cgo) be damned.

I do suppose that the group_by performance can be improved by working on the c->go compiler, though. I think that's a more worthwhile effort than rewriting sqlite.

View on HN

> 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?

> 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

> 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.

> 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

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.

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.

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.

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.

I agree. And I work at https://github.com/goplus/c2go recently. Its goal is converting any C project into Go without any human intervention and keeping performance close to C.

Reply on news.ycombinator.com