Go SDK

[chensid]

Is your feature request related to a problem? Please describe.

Rerun ships SDKs for Python, Rust, and C++. A lot of robotics data infrastructure — ingestion services, job workers, object-storage plumbing — is written in Go, and there is currently no way to produce or read the Rerun format from it.

One practical consequence: when a Go-based pipeline needs to emit a derived artifact for visualization, MCAP is reachable (github.com/foxglove/mcap/go/mcap) and RRD is not. So the choice gets made by SDK availability rather than by what suits the viewer — and the RRD-only capabilities (footer manifest, on-demand chunk loading via rerun server) stay out of reach for that whole class of services.

Describe the solution you'd like

Not the full SDK — the write path would cover most of it:

• recording stream: init, set_time, log
• a core set of archetypes (scalars, transforms, points, images)
• save to .rrd

No viewer, no spawn, no gRPC client.

Describe alternatives you've considered

• Shell out to the rerun CLI — workable, but means shipping the CLI in worker images and treating its behavior as an API.
• A Python sidecar just to call the SDK — a second runtime and deployment unit for one function.
• Emit MCAP instead — the viewer reads MCAP natively, so this gets you visualization without RRD. It's the pragmatic answer today, at the cost of the RRD-only capabilities above.

Additional context

I searched issues and discussions and didn't find an existing request for Go, so this is to gauge interest rather than to assert demand. If it's out of scope, that's a useful answer too — in that case, documenting the supported way to produce RRDs from outside the three SDK languages (a stable CLI contract, or format-stability guarantees for third-party writers) would cover most of the need.

[Wumpf]

Makes a lot of sense! We don't quite feel ready to add another officially supported SDK language, but as we see more Go usage this will change. Worth calling out that someone recently did their own Julia SDK over here

[chensid]

Makes a lot of sense! We don't quite feel ready to add another officially supported SDK language, but as we see more Go usage this will change. Worth calling out that someone recently did their own Julia SDK over here

Thanks, that makes sense.

This comes from a real use case on our side: most of our robotics data ingestion and storage services are written in Go, and we would mainly need a small write-only path for generating .rrd files.

I’d be interested in exploring a community-maintained prototype. For a minimal Go writer, would you recommend:

• wrapping/reusing the existing Rust logging crates through FFI, or
• implementing the RRD serialization directly in Go?

Knowing which direction is less likely to break across Rerun releases would be very helpful.

[Wumpf]

Wherever possible I'd go through the existing C interface which the C++ interface is built on top of and extend it as needed. That way you can follow an established pattern for the FFI and get fairly consistent behavior without having to maintain the bulk of the logic. I.e. the main thing you then need on the Go side is making those interface idiomatic and arrow serialization

[chensid]

That makes sense, thanks.

One more question on the contribution model: if a minimal Go SDK prototype proves useful, would you prefer it to be proposed as a PR to the main Rerun repository, or maintained as a separate community project initially?

I’d like to align with the direction that would be easiest for the Rerun team to support and review.

[Wumpf]

Thanks for being so considerate! <3
Given our current reluctance to maintain it I think a separate project makes more sense right now. But if you do it as a repository fork I'd be curious what a minimal draft PR could look like if you're willing to set one up :)