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