24 ms·

You're missing the point a little, I think. It's not just JSON, it's anywhere your Go code interfaces with the outside world. That's where you start fighting wi

You're missing the point a little, I think. It's not just JSON, it's anywhere your Go code interfaces with the outside world. That's where you start fighting with Go case conventions vs. the rest of the world. I like the concept of tags in principle, but in practice they end up being very repetitive. Compare it with Rust's "serde" stuff—it's much nicer.

infogulch 9y ago
Boundary layers will always have naming convention conflicts. Even serde has `#[serde(rename = "name")]` [1] for this purpose. It's unlikely that go will ever be able to approach the powerful and general compile-time code generation/macros that rust avails awesome libraries like serde. I guess it's a difference of perspective: do you let the outside world's naming conventions leak into your codebase, or do you translate at the boundary? Go's field tags chooses to keep consistent naming internally and translate at the boundary, in exchange for defining that translation explicitly. Note, in some cases you will have conflicts no matter what you choose (e.g. serializing both json and database). The outside world is going to be messy and inconsistent and full of conflicts. I would prefer to keep that external to my codebase as much as possible and follow a consistent naming convention within the language instead of letting the outside world and its whims dictate it. [1]: https://serde.rs/field-attrs.html https://serde.rs/field-attrs.html
- ayosec 9y ago
  > Even serde has `#[serde(rename = "name")]` for this purpose. You can use `#[serde(rename_all = "camelCase")]`[1] in the struct to apply the fix to all fields. [1]: https://serde.rs/container-attrs.html#serderenameall-- https://serde.rs/container-attrs.html#serderenameall--