4 ms·

Speaking of magic, json tags are weird stringy magic only used at runtime via reflection. If I have a struct with the tag `josn:"foo"` instead of "json", I won

Speaking of magic, json tags are weird stringy magic only used at runtime via reflection. If I have a struct with the tag `josn:"foo"` instead of "json", I won't get an error, it'll just silently blow up. If I add a new field, I have to manually add the tag too. You know what's both less magic and less fragile? The rust equivalent. In rust, I write '#[serde(rename_all = "camelCase")]' above a struct. If I typo, it won't compile. If I add new members to the struct, they'll work without me having to remember some boilerplate. If I have one that needs an exception, I can put '#[serde(rename = "foo")]' above just that one. It also won't compile if I typo. This is the alternative to what go has; compile-time safety, language-features that let a library provide such naming strategies, etc. It's less magic since it doesn't rely on these weird conventionally named tag things that are only sorta part of the language. I suspect what the author meant by naming strategy was something like that. Your argument that the author is adverse to being explicit is a strawman; the author appears to be asking for a struct-wide way to be explicit.

zamalek 9y ago
> Speaking of magic, json tags are weird stringy magic only used at runtime via reflection. Yeah, that is pretty awful. I'm a big fan of strongly-typed attributes (having come from C#). > '#[serde(rename_all = "camelCase")]' That's 99% perfect because the locality of the schema contract is near the field. I mostly have contention with using a global settings singleton (or similar) as a configuration store for this stuff as a good example. With examples like yours, my comment wouldn't have been posted.
frankietwenty9 9y ago
> Speaking of magic, json tags are weird stringy magic only used at runtime via reflection. Annotations are used at run-time via reflections. JSON marshaling is a common use for annotations. > If I have a struct with the tag `josn:"foo"` instead of "json", I won't get an error, it'll just silently blow up. well it won't blow up, it won't function as intended - much like a logical error. A linter, like the one that comes with VSCode will catch this error for you. Annotations don't need to conform to any format and are not compile time errors. I am unsure how this could change while maintaining the Go1 guarantee. Perhaps this could be an area of improvement going forward - having typed annotations. > If I add a new field, I have to manually add the tag too. It will work in go too. If you want it to deviate from the naming of your struct field, you would need to describe the map. It's like complaining that when you add a field to your database, you need to add it to your code too. Sure it's not as powerful as Rust, but that's the point. > In rust, I write '#[serde(rename_all = "camelCase")]' above a struct. If I typo, it won't compile. If I add new members to the struct, they'll work without me having to remember some boilerplate. That's handy, but incompatible with Go 1. It is worth noting that Go and Rust are different. Rust is more focused on power, while Go has more of a focus on simplicity.
- TheDong 9y ago
  > Annotations are used at run-time via reflections They're called tags, not annotations, per the spec (https://golang.org/ref/spec https://golang.org/ref/spec). I don't know what you're trying to say there, but it's using wrong terminology. > well it won't blow up, it won't function as intended - much like a logical error Aka "silently blow up", I could have used a better phrase, but I do indeed know what happens and that's what I meant. > A linter, like the one that comes with VSCode will catch this error for you. How is that possible? As you say on the next line, they don't need to conform to any format. How can my linter know that I don't have a package that parses "josn" tags, and that I typoed? Please link me to the lint rule if it exists. > That's handy, but incompatible with Go 1 So? It is, but the point of the article is that go is badly designed; the fact that they can't change it makes that design all the worse since we must live with it. Pointing out that go decided to freeze their language is totally irrelevant. > Rust is more focused on power, while Go has more of a focus on simplicity. Simplicity and power aren't always opposites, and apply to many different conflicting pieces of a language. This is a massive over-simplification. Go optimized for simplicity of the language spec and simplicity of the compiler at the expense of the simplicity of writing correct code.
  - frankietwenty9 9y ago
    > They're called tags, not annotations, per the spec (https://golang.org/ref/spec https://golang.org/ref/spec). I don't know what you're trying to say there, but it's using wrong terminology. My mistake > How is that possible? As you say on the next line, they don't need to conform to any format. How can my linter know that I don't have a package that parses "josn" tags, and that I typoed? Please link me to the lint rule if it exists. https://golang.org/cmd/vet/#hdr-Struct_tags https://golang.org/cmd/vet/#hdr-Struct_tags
    - TheDong 9y ago
      The struct tags vet will not catch the typo I mentioned. It would catch `json:"missing closing quote`; it would not catch the "josn" typo.
- 9y ago

zamalek 9y ago

> Speaking of magic, json tags are weird stringy magic only used at runtime via reflection. Yeah, that is pretty awful. I'm a big fan of strongly-typed attributes (having come from C#). > '#[serde(rename_all = "camelCase")]' That's 99% perfect because the locality of the schema contract is near the field. I mostly have contention with using a global settings singleton (or similar) as a configuration store for this stuff as a good example. With examples like yours, my comment wouldn't have been posted.

frankietwenty9 9y ago

> Speaking of magic, json tags are weird stringy magic only used at runtime via reflection. Annotations are used at run-time via reflections. JSON marshaling is a common use for annotations. > If I have a struct with the tag `josn:"foo"` instead of "json", I won't get an error, it'll just silently blow up. well it won't blow up, it won't function as intended - much like a logical error. A linter, like the one that comes with VSCode will catch this error for you. Annotations don't need to conform to any format and are not compile time errors. I am unsure how this could change while maintaining the Go1 guarantee. Perhaps this could be an area of improvement going forward - having typed annotations. > If I add a new field, I have to manually add the tag too. It will work in go too. If you want it to deviate from the naming of your struct field, you would need to describe the map. It's like complaining that when you add a field to your database, you need to add it to your code too. Sure it's not as powerful as Rust, but that's the point. > In rust, I write '#[serde(rename_all = "camelCase")]' above a struct. If I typo, it won't compile. If I add new members to the struct, they'll work without me having to remember some boilerplate. That's handy, but incompatible with Go 1. It is worth noting that Go and Rust are different. Rust is more focused on power, while Go has more of a focus on simplicity.

TheDong 9y ago
> Annotations are used at run-time via reflections They're called tags, not annotations, per the spec (https://golang.org/ref/spec https://golang.org/ref/spec). I don't know what you're trying to say there, but it's using wrong terminology. > well it won't blow up, it won't function as intended - much like a logical error Aka "silently blow up", I could have used a better phrase, but I do indeed know what happens and that's what I meant. > A linter, like the one that comes with VSCode will catch this error for you. How is that possible? As you say on the next line, they don't need to conform to any format. How can my linter know that I don't have a package that parses "josn" tags, and that I typoed? Please link me to the lint rule if it exists. > That's handy, but incompatible with Go 1 So? It is, but the point of the article is that go is badly designed; the fact that they can't change it makes that design all the worse since we must live with it. Pointing out that go decided to freeze their language is totally irrelevant. > Rust is more focused on power, while Go has more of a focus on simplicity. Simplicity and power aren't always opposites, and apply to many different conflicting pieces of a language. This is a massive over-simplification. Go optimized for simplicity of the language spec and simplicity of the compiler at the expense of the simplicity of writing correct code.
- frankietwenty9 9y ago
  > They're called tags, not annotations, per the spec (https://golang.org/ref/spec https://golang.org/ref/spec). I don't know what you're trying to say there, but it's using wrong terminology. My mistake > How is that possible? As you say on the next line, they don't need to conform to any format. How can my linter know that I don't have a package that parses "josn" tags, and that I typoed? Please link me to the lint rule if it exists. https://golang.org/cmd/vet/#hdr-Struct_tags https://golang.org/cmd/vet/#hdr-Struct_tags
  - TheDong 9y ago
    The struct tags vet will not catch the typo I mentioned. It would catch `json:"missing closing quote`; it would not catch the "josn" typo.
9y ago