Christian Legnitto

Can you fix this in the go sdk so the structs we are generating from it are then correct?

Hmmm, I'll have to think about this. I think we can support this case but it will take some refactoring.

Is the go code correct in this case? Does it have `omitempty`?

@calavera what do you think about this? I feel like most bugs these days are because Go's type system is less expressive and/or they have a bug in their defs.

Mainly because the go library this generates from doesn't really have the distinction...go has default values and the default value of a string is `""`, so a straight string field...

I tried to think what would be the most idiomatic / least surprising in most cases but sadly the Go defs don't give me enough semantic information to cover all...

Yeah, we do have to special case things / have to pick some stance because Go may not declare a field as nullable and then silently coerce a null to...

How about using the newly (1.60) stabilized `target_has_atomic`? ```rust #[cfg(all(std, target_has_atomic = "ptr"))] ``` From this [old RFC](https://rust-lang.github.io/rfcs/1543-integer_atomics.html#target-support): > After a quick survey of the LLVM and Clang code, architectures...

Sure, I thought we wanted to use the RFC doc as the source of truth but I can pull some stuff up here! Thanks for the quick response 🚀

The thinking here is other entropy pools would be seeded from this main pool, giving a single place to control all downstream (and plugins, I guess that is upstream?) determinism....