Hacker News Reader

Comment by trey-jones | Hacker News Reader

> I think most of the points raised are subjective

That was my take away. In fact many of the points made in the negative are actually positives for me :

- capitalization - I actually think it's much easier to spot the public API with this convention

- no exceptions - I get the concern about forgetting to handle and I think a compiler error for unhandled unhandled return values would be great. I also think golint probably handles this.

Other issues can be solved easily with tooling (goimports). I admit, I love the language and I feel very productive working in it. Error handling has NEVER been more successful - that's my number one praise.

View on HN

The problem with capitalization for me comes when interfacing with external json. Suddenly serializable structs have to be exported (since introspection doesn't work on private structs) which means that none of the names match the json names anymore (the web world tends to use lowercase or camel case with the first word uncapitalized). So now every json structure had to not only be public but also has to have introspection hints (`json: "my_field_name"`). It makes everything verbose and ugly. In these cases I'd much rather have "pub" in front of some lowercase names that match the json I'm reading or writing.

I feel like changing the implementation of a core feature just to make json serialization a little easier would be the completely wrong thing to optimize for. 99% of go code is not json serialization structs. Are you going to name all your fields with underscores for the same reason? What if you're using the same struct with your database? Are you going all the way and name your database fields based on your json api naming conventions just so you don't have to write some metadata?

I'll take writing tags, thanks.

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.

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

> 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--

Reply on news.ycombinator.com