Hello GAR Community! I hope this email finds you well.
Been a while - I've picked the Go SDK back up, and the metadata layer is ready for review. Following Xiaokang's earlier suggestion (start with GraphInfo/YAML parsing, like java-info), the info layer is pure Go: - value types: DataType (incl. list), FileType, AdjListType, Cardinality, InfoVersion - metadata model: Property, PropertyGroup, VertexInfo, EdgeInfo, GraphInfo, with validation - YAML load/save behind a private DTO layer It round-trips every graph.yml in the graphar-testing submodule (ldbc, ldbc_sample, modern_graph, nebula, neo4j, and the java fixtures), so it reads the same on-disk format the C++/Java SDKs write. go 1.23. One open question, on the data layer (the actual parquet chunks): I'm leaning towards building on apache/arrow-go instead of the CGO-to-C++ bridge from the original proposal - no C toolchain, trivial cross-compilation, no libgraphar build dependency (the go floor would move up to match arrow-go's at that point). That's the "read-write tech stack" bit we said we'd revisit; wanted to sound it out before I start down that path. For landing the info layer, I've split it into dependency-ordered pieces, each self-contained and green on CI: 1. module bootstrap + CI + tooling 2. value types 3. metadata model 4. YAML load/save 5. cross-language interop + e2e tests I've opened the first (bootstrap) so there's something concrete to look at: <PR link>. I'd keep going as a series of small PRs, each rebased on the last merge - easier to review one at a time - but happy to batch them if you'd rather. No rush on any of this - whenever you have the bandwidth. Thanks for taking a look, Zeki (Zeyu Liu) References: [1]https://github.com/apache/incubator-graphar/pull/937https://github.com/apache/incubator-graphar/pull/937 [2] https://github.com/apache/incubator-graphar/pull/938 On Tuesday, January 20th, 2026 at PM 11:45, Zeki (Zeyu Liu) <[email protected]> wrote: > Hello GAR Community! > > I hope this email finds you well. > > I am Zeki (Zeyu Liu), a developer interested in building Go support for > GraphAr. > > Following the discussion in [#540 > [1]](https://github.com/apache/incubator-graphar/discussions/540) and [#828 > [2]](https://github.com/apache/incubator-graphar/issues/828), I would like to > propose a phased approach for the Go SDK. > > Initially, I plan to implement the info package natively in Go, drawing > inspiration from the java-info implementation and other language SDKs' best > practices to ensure ease of use and maintainability. > > For the write path, I suggest leveraging CGO (the mechanism for calling C/C++ > from Go) to call the core capabilities of the existing C++ library to ensure > functional alignment. > > In the future, we can consider native Go implementations for high-frequency > community requirements as needed. > > My initial roadmap is focused on: > > Part 1: Implement the info package and support for the local filesystem. > > Part 2: Introduce storage abstraction (e.g., S3) after the core logic is > stable. > > I have submitted a minimal PR [#829 > [3]](https://github.com/apache/incubator-graphar/pull/829), which includes a > placeholder Go module and a basic CI workflow to bootstrap the project. > > I would appreciate your feedback on this hybrid approach (Native + CGO) and > the project structure. > > Best regards, > Zeki (Zeyu Liu) > > --- > > References: > [1] https://github.com/apache/incubator-graphar/discussions/540 > [2] https://github.com/apache/incubator-graphar/issues/828 > [3] https://github.com/apache/incubator-graphar/pull/829
