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…
Go port of SQLite without CGo
71–80 of 122 posts
Re: Go port of SQLite without CGo
#72If 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…
GOOS= GOARCH= CGO_ENABLED=1 go build \
-tags osusergo,netgo,sqlite_omit_load_extension \
-ldflags="-extldflags=-static"
[0]: https://www.arp242.net/static-go.htmlRe: Go port of SQLite without CGo
#73Earlier 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.
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
#74Re: Go port of SQLite without CGo
#75Earlier 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…
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
#76How 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.
Re: Go port of SQLite without CGo
#77Earlier 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.
The developer should alao maintain their software and deploy it. Has IMHO a lot of advantages
Re: Go port of SQLite without CGo
#78Earlier 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…
Re: Go port of SQLite without CGo
#79Note 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.)
Re: Go port of SQLite without CGo
#80Earlier 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.