Live data from Hacker News

Go port of SQLite without CGo

gitlab.com

71–80 of 122 posts

Re: Go port of SQLite without CGo

#71
post #68
post #26

Earlier quoted context omitted.

In addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.

I was surprised with the announcement that Go's standard compiler had register allocation for function arguments[0] added to it. This seemed like table stakes for a very long time but it really illustrated just how Go's compiler is much, much simpler than most in many areas. On one hand it makes you wonder how much could be squeezed out of Go and how many basic things they're still leaving out of the compiler. On the…

I wonder if they'll ever switch to a "normal = fast compile, low optimisation; release = slow compile, high optimisation" model like Rust. Although I suppose other languages already have the "high optimisation" parts covered (rust, julia, python+numpy, etc.) which might make it a fool's errand.

Re: Go port of SQLite without CGo

#72
post #8

If you cross-compile (which everybody using macOS to developer for Linux servers does), it's annoying to introduce SQLite to your project, because immediately the conventional `GOOS= GOARCH= go build` trick stops working. But, in case it's helpful, it's also really easy to set up a full cross-compiling environment, either with Zig or with Filippo's musl-cross: https://words.filippo.io/easy-windows-and-linux-cross-com…

The following post [0] describes how to build static binaries even with cgo enabled:

    GOOS= GOARCH= CGO_ENABLED=1 go build \
      -tags osusergo,netgo,sqlite_omit_load_extension \
      -ldflags="-extldflags=-static"
[0]: https://www.arp242.net/static-go.html

Re: Go port of SQLite without CGo

#73
post #57

Earlier quoted context omitted.

Pretty sure lots of people still touch servers directly, and will continue to until servers are no longer a thing.

Sure, but then DevOps aren't doing their jobs. No devs on production servers unless for tracking down issues, or servers configured for remote development. Which in both cases, don't require cross compilation to start with.

There are less and less touching servers directly happening. Not only DevOps but the current raise of k8s and serverless deployments making it less relevant. There is also the security aspect of it.

The downside is that people (especially the ones who are just joining the workforce) are less efficient with the command line and more dependant on GUI. For example some of the junior devs do not know git cli anymore and rely on the VSCode plugin to interact with git. This becomes an issue when there is a bug in the plugin and you should use the CLI.

Re: Go port of SQLite without CGo

#74
i used it for a bit but was constantly getting transaction lock errors. i even added manual mutex for all transactions since it natively does not have exclusive transactions but even that did not worked. there is not a single good sqlite library for go out there. period. waste of time fiddling with it.

Re: Go port of SQLite without CGo

#75
post #57

Earlier quoted context omitted.

Sure, but then DevOps aren't doing their jobs. No devs on production servers unless for tracking down issues, or servers configured for remote development. Which in both cases, don't require cross compilation to start with.

There are less and less touching servers directly happening. Not only DevOps but the current raise of k8s and serverless deployments making it less relevant. There is also the security aspect of it. The downside is that people (especially the ones who are just joining the workforce) are less efficient with the command line and more dependant on GUI. For example some of the junior devs do not know git cli anymore and…

That is easy to sort out, like every git problem, clone the repo and start again.

I know SCM tooling since the RCS days, and couldn't be bothered to master git implementation details to fix broken repos.

Unfortunely we are stuck with git for the time being.

Re: Go port of SQLite without CGo

#76

How does this compare to https://github.com/glebarez/go-sqlite ? Using that for https://www.octobench.com/ and I'm very happy.

It looks like your library is using some of the plumbing from the parent. I can't tell what benefit it adds on top of it because the parent is also compatible with the Go standard library sql/driver API.

Thanks!

Re: Go port of SQLite without CGo

#77
post #57

Earlier quoted context omitted.

Pretty sure lots of people still touch servers directly, and will continue to until servers are no longer a thing.

Sure, but then DevOps aren't doing their jobs. No devs on production servers unless for tracking down issues, or servers configured for remote development. Which in both cases, don't require cross compilation to start with.

DevOps should IMHO not be a job role but a company philosophy.

The developer should alao maintain their software and deploy it. Has IMHO a lot of advantages

Re: Go port of SQLite without CGo

#78
post #57

Earlier quoted context omitted.

Sure, but then DevOps aren't doing their jobs. No devs on production servers unless for tracking down issues, or servers configured for remote development. Which in both cases, don't require cross compilation to start with.

There are less and less touching servers directly happening. Not only DevOps but the current raise of k8s and serverless deployments making it less relevant. There is also the security aspect of it. The downside is that people (especially the ones who are just joining the workforce) are less efficient with the command line and more dependant on GUI. For example some of the junior devs do not know git cli anymore and…

Yes, we're shelling into k8s containers now

Re: Go port of SQLite without CGo

#79

Note that this is not “go port”. It’s C transpiled to go with their custom C compiler, and it’s transpiled differently for each architecture (as it’s using unsafe go heavily) I look at it like a neat exercise but not really something to use in production. (I actually use it in tests though.)

It is definitely neat, but I think it's more than an exercise. I believe he runs it through the extensive SQLite test suite (I've seen that before, though I can't see where that's stated now).

Re: Go port of SQLite without CGo

#80
post #57

Earlier quoted context omitted.

Pretty sure lots of people still touch servers directly, and will continue to until servers are no longer a thing.

Sure, but then DevOps aren't doing their jobs. No devs on production servers unless for tracking down issues, or servers configured for remote development. Which in both cases, don't require cross compilation to start with.

This comment leads me to believe that you’re used to working in one type of organisation to the point where you’re projecting it on your entire understanding of this incredibly broad industry.
Post reply on HN