Go bindings

[reez]

Describe the enhancement
I would like to offer Go bindings for bdk-ffi.

Blocker
bdk-ffi (currently on uniffi = 0.30.0) cannot currently generate Go bindings with uniffi-bindgen-go.

tnull has an issue open to bump to 0.29.5 NordSecurity/uniffi-bindgen-go#86 , but thru my experimentation/testing it seems that for direct compatibility with current bdk-ffi we likely need uniffi 0.30.x support

Options

• wait for uniffi-bindgen-go to bump to uniffi 0.30.x (minimal lift, unknown timeline)
• fork uniffi-bindgen-go and port to 0.30.x (large lift)
• make go compat bdk-ffi branch/fork (large lift)
• wait for another go plugin to show up (minimal lift, uncertain)

[reez]

tnull has open pr for this now NordSecurity/uniffi-bindgen-go#88 to 0.30

[reez]

I tested bdk-ffi Go binding generation with @tnull uniffi-bindgen-go PR #88 (UniFFI 0.30 support):

• Binding generation succeeds

The generator command exits successfully, but the failure appears in a subsequent Go compile step.

That generator step does not run go build, so compile/type errors are caught later by go build/go test, and I got compilation errors:

bdk/bdk.go:12358:17: invalid map key type ControlBlock
bdk/bdk.go:12366:18: invalid map key type ProprietaryKey
bdk/bdk.go:12368:14: invalid map key type Key
bdk/bdk.go:12827:18: invalid map key type ProprietaryKey
bdk/bdk.go:12829:14: invalid map key type Key
bdk/bdk.go:23230:17: invalid map key type []uint32
bdk/bdk.go:28343:77: invalid map key type ControlBlock
bdk/bdk.go:28344:32: invalid map key type ControlBlock
bdk/bdk.go:28347:79: invalid map key type ControlBlock
bdk/bdk.go:28348:21: invalid map key type ControlBlock
bdk/bdk.go:28348:21: too many errors

So the blocker now is a Go compile failure in generated code.

I decided to see if I could fix that failure, created this branch, which builds on top of PR 88 from tnull:

• Root cause seems like bdk-ffi exposes maps with keys that are not Go comparable
  • Satisfaction::PartialComplete.conditions: HashMap<Vec<u32>, Vec<Condition>>
    • (see invalid map key type []uint32)
  • tap_scripts: HashMap<ControlBlock, TapScriptEntry>
  • proprietary: HashMap<ProprietaryKey, Vec<u8>>
  • unknown: HashMap<Key, Vec<u8>>
    • tap_scripts, proprietary, unknown roll up to Input type we expose in bdk-ffi

So PR #88 unblocks UniFFI 0.30 generation, but bdk-ffi will still need Go backend handling for non-comparable map keys.

[tnull]

Hmm, I looked into a bit, but unfortunately it seems to really be a limitation of Go. I assume there could be workaround here and/or in the uniffi-bindgen-go generator which we could explore further. To quote the AI summary:

This is a Go language constraint rather than a Rust trait issue. In Go, map keys must be comparable types (per the https://go.dev/ref/spec#Comparison_operators). The bindings generator currently has no validation for this — it blindly generates map[KeyType]ValueType and lets the Go compiler
  fail.

  Here's the breakdown:

  Go-comparable (valid as map keys):
  - Primitives: bool, intN, uintN, floatN, string
  - Pointers (so *Object types work)
  - Structs where all fields are comparable
  - Arrays of comparable types

  NOT comparable (invalid as map keys):
  - Slices ([]T) — this is what Vec<T> maps to
  - Maps (map[K]V)
  - []byte — what bytes/Vec<u8> maps to

  So for HashMap<Vec<u32>, Vec<Condition>>, the key Vec<u32> becomes []uint32 in Go, which is a slice and cannot be a map key. No Rust trait (Hash, Eq, etc.) can fix this — it's a fundamental Go type system constraint.

  For Records specifically: A Record becomes a Go struct, which is automatically comparable if and only if all its fields are comparable Go types. A Record with only primitive/string/enum fields works fine as a map key. A Record containing a Vec, HashMap, or bytes field does not.

[tnull]

Btw, some of this seems to be also pre-existing at least in Python, and Claude is the opinion it will simply fail at runtime rather than at compile time:

 The answer is straightforward based on what we already found:

  Python has the exact same problem as Go — it just manifests at runtime instead of compile-time.

  The uniffi-rs Python bindings would generate something like:

  @dataclass
  class Satisfaction:
      class PartialComplete:
          def __init__(self, *, n: int, m: int, items: list[int],
                       sorted: Optional[bool],
                       conditions: dict[list[int], list[Condition]]):
              ...

  Python list is not hashable, so using it as a dict key raises TypeError: unhashable type: 'list' at runtime. The bindings will generate fine, and the code will import fine, but the moment you try to deserialize/lift a PartialComplete value with data in conditions, the Read method in the
  FfiConverter would do:

  result = {}
  for i in range(length):
      key = FfiConverterSequenceUInt32.read(buf)   # returns a list
      value = FfiConverterSequenceTypeCondition.read(buf)
      result[key] = value  # BOOM: TypeError: unhashable type: 'list'

  So none of the official bindings actually solve this:
  - Swift/Kotlin: Don't have the problem (their list types are hashable/have hashCode)
  - Python: Same problem as Go, but fails at runtime instead of compile-time
  - Go: Fails at compile-time because slices aren't comparable

  This means bdk-ffi's HashMap<Vec<u32>, Vec<Condition>> is fundamentally broken for both Python and Go bindings. It only works for Swift and Kotlin. The right fix would likely need to happen either upstream in bdk-ffi (e.g., using a newtype wrapper or different key type) or in the bindings
  generators with a clear error at generation time.

[reez]

@tnull that's interesting I didnt realize the python issue you mentioned.

does the go generator fallback approach in my branch I posted above seem valid at all, or is it preferred that it should be generator time errors for these cases?

[tnull]

@tnull that's interesting I didnt realize the python issue you mentioned.

does the go generator fallback approach in my branch I posted above seem valid at all, or is it preferred that it should be generator time errors for these cases?

Honestly, I'm not sure, that might be something to explore also with other users of the bindgen, if we don't find a better way here. The issue is that it might lead to relatively unexpected results for people who aren't aware of the workaround.

[reez]

Honestly, I'm not sure, that might be something to explore also with other users of the bindgen, if we don't find a better way here. The issue is that it might lead to relatively unexpected results for people who aren't aware of the workaround.

Yeah I see what your saying, hoping to find a better way

[reez]

@tnull 's PR NordSecurity/uniffi-bindgen-go#88 upgrading to uniffi v0.30 uniffi-bindgen-go worked well when I tested related to bdk-go. ✅

0.30 matches bdk-ffi now which is nice.

we still have blocker related to bdk-go from failing at the Go compile layer (as seen in discussions above) ❌

@tnull also has open PR NordSecurity/uniffi-bindgen-go#90 upgrading to 0.31 also worked well when I tested related to bdk-go. ✅

[reez]

0.31 merged NordSecurity/uniffi-bindgen-go#90