| > 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. |
But specifically on simplicity of implementation. Which often means pushing the complexity onto the developer.
This line from the article is a pretty good summary of Go in general:
> It looks to me a like a big flaw in the language design to make its implementation easier.