Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go port of SQLite without CGo

gitlab.com

Post reply on HN
Print view View original

101–110 of 122 posts

Re: Go port of SQLite without CGo

#101

Post by arp242 »

dpiddy wrote: post #92
benhoyt wrote: post #79

Earlier quoted context omitted.

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

The bits in https://gitlab.com/cznic/sqlite/-/blob/master/tcl_test.go run the full suite of SQLite TCL tests as part of a Go test. That's in turn run as part a CI setup with results at https://modern-c.appspot.com/-/builder/?importpath=modernc.o... .

Those are not all the tests for SQLite: https://sqlite.org/testing.html#harnesses

Only the TCL and SQL Logic Test are publicly available; it's one of the ways that the SQLite developers get paid.

Re: Go port of SQLite without CGo

#102

Post by tptacek »

pjmlp wrote: post #85
geraldwhen wrote: post #81

Earlier quoted context omitted.

You’re running graviton arm locally? It’s all docker containers in the end, so that’s what you get.

No, and why should I? I got into UNIX development back when the whole team shared a development server and we used telnet and X Windows for our "IDE". No one was running SPARC, RISC System/6000, PA-RISC, MIPS, Eclipse MV locally. When everyone keeps worshipping UNIX, maybe it is time to learn how grey beards used to develop for it.

That's how I came up too. It sucked. It's good that it's being forgotten.

Re: Go port of SQLite without CGo

#104

Post by 0xjnml »

tedunangst wrote: post #21

I should mention that if you use this, somebody will eventually discover this line of code and be unhappy. https://gitlab.com/cznic/libc/-/blob/v1.22.2/libc_openbsd_am...

openbsd/amd64 is not a supported target. Here's the list: https://pkg.go.dev/modernc.org/sqlite#hdr-Supported_platform...

Re: Go port of SQLite without CGo

#105

Post by preseinger »

shp0ngle wrote: post #64

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

i use it in production, at high volume and scale

it's got quirks but it's powerful and performs well

Re: Go port of SQLite without CGo

#106

Post by cube2222 »

lanstin wrote: post #98
tetete wrote: post #38

Why would you want to do this? SQLLITE is so stable. Why would you switch to some port that will be dead in a year?

Each call out to a C library from Go locks an OS thread rather than participating in the go routine scheduling. If stuff happens that makes those threads slow or have some issue, they just sit here. I had a server with C Kafka libraries and each time the network glitched the CPU would spike up wards and not decline. With pure go the scheduler is able to just swap out and ignore code that is stuck some where (unless i…

Worth noting that busy loops are handled as well since 1.18.

Re: Go port of SQLite without CGo

#107

Post by datadeft »

pjmlp wrote: post #75
datadeft wrote: post #73

Earlier quoted context omitted.

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.

I agree with you based the amount of time someone needs to spend to fix a broken repo.

I just really like to understand the tools that I use. Maybe it is a waste of time.

Re: Go port of SQLite without CGo

#108

Post by shepherdjerred »

pjmlp wrote: post #96
10000truths wrote: post #95

Earlier quoted context omitted.

It seems fairly straightforward - copy over the SDK header files and libraries to the project and then add these envs to the build: CC="/path/to/cross/compiler" CGO_CFLAGS=—I/path/to/sdk/header/files/include" CGO_LDFLAGS="-L/path/to/sdk/obj/files/lib” I suppose with .so files, you might have to specify "-Wl,-rpath" if the SDK libraries don’t reside under /usr/lib or /usr/local/lib on the target system. But I haven’t…

Now do the same as Windows UWP SDK, or iOS SDK. You're missing all the tooling and OS specific steps required to produce a proper package.

For macOS: https://github.com/tpoechtrager/osxcross

Re: Go port of SQLite without CGo

#109

Post by mdaniel »

yieldcrv wrote: post #35
tedunangst wrote: post #21

I should mention that if you use this, somebody will eventually discover this line of code and be unhappy. https://gitlab.com/cznic/libc/-/blob/v1.22.2/libc_openbsd_am...

line 213 if you’re on mobile

Don't feel bad, GitLab's line navigation thing doesn't work reliably on desktop, either. I guess they put that on the list of the other 15,000 issues that are "on the backlog"

Re: Go port of SQLite without CGo

#110

Post by dpiddy »

arp242 wrote: post #101
dpiddy wrote: post #92

Earlier quoted context omitted.

The bits in https://gitlab.com/cznic/sqlite/-/blob/master/tcl_test.go run the full suite of SQLite TCL tests as part of a Go test. That's in turn run as part a CI setup with results at https://modern-c.appspot.com/-/builder/?importpath=modernc.o... .

Those are not all the tests for SQLite: https://sqlite.org/testing.html#harnesses Only the TCL and SQL Logic Test are publicly available; it's one of the ways that the SQLite developers get paid.

You are correct, I should have clarified that it's just the publicly-available tests. Still, those are pretty expansive.
Post reply on HN