An experimental, pre-release 5.x version of the Go driver is out: Release v5.0.0-preview · neo4j/neo4j-go-driver · GitHub
context.Context APIs, giving user more control on the timing of operations. Give it a try!
Seabolt 1.7.1 and Go Driver 1.7.1 versions are now released.
Changelogs are available at https://github.com/neo4j-drivers/seabolt/wiki/1.7-changelog#v171 and https://github.com/neo4j/neo4j-go-driver/wiki/1.7-changelog#v171 respectively.
Seabolt 1.7.2 and Go Driver 1.7.2 versions are now released.
Changelogs are available at https://github.com/neo4j-drivers/seabolt/wiki/1.7-changelog#v172 and https://github.com/neo4j/neo4j-go-driver/wiki/1.7-changelog#v172 respectively.
Go Driver v1.7.0-rc02 and Seabolt v1.7.0-rc02 are released last Friday, with experimental binary packages for seabolt available here. Please try them out and let us know any problems you run into.
For a list of changes, you can have a look at change logs -> https://github.com/neo4j/neo4j-go-driver/wiki/1.7-changelog#v170-rc02 and https://github.com/neo4j-drivers/seabolt/wiki/1.7-changelog#v170-rc02.
Seabolt 1.7.0-rc03 and
Go Driver 1.7.0-rc03 are now released.
Seabolt now has a static library output which is a step towards statically linkable go-driver!
Changelogs are available at https://github.com/neo4j-drivers/seabolt/wiki/1.7-changelog#v170-rc03 and https://github.com/neo4j/neo4j-go-driver/wiki/1.7-changelog#v170-rc03 respectively.
On the seabolt requirement question...
As part of our long term plan to support as many languages, platforms and frameworks as possible with our official drivers, we're working towards a more modular architecture for our client-side libraries. Concretely, this means that drivers will be built on top of lower level libraries, called connectors.
Seabolt is one such connector, and has been built in C to ensure both great performance and broad compatibility. Connectors will in general encompass all protocol, type system and routing logic and will surface a "Connector API" on which drivers and other tooling can be built. Note that connectors are not intended for direct use by application software.
We do recognise that there are a small subset of platform configurations that might struggle to work with a C dependency library. This is obviously unfortunate for those in this position, but we do hope that the greater breadth of language support we can offer for the wider Neo4j community will offset these limitations. Over time, we may even be able to plug some of these gaps with pure language code, should we see a great enough need.
In terms of the extra steps required for the installation of a C dependency, we are also looking at ways to streamline this process. So watch this space!
That's good feedback and certainly true at the moment. A thing to keep in mind though is that on serverless, a lot of the cloud vendors are moving towards supporting Docker containers for running cloud functions. Google already does, so does Azure, and it's kind of expected that AWS Lambda will support Docker containers too though I don't know the timeline.
If you're one of the serverless providers, docker makes sense as a support endpoint because there are too many different runtimes to support (python, node, golang, etc. etc.) and supporting individual runtimes comes with those drawbacks like this that you identify.