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.
I'd suggest a simple language requires a simpler implementation.
> It wasn't enough to just add features to existing programming languages, because sometimes you can get more in the long run by taking things away. They wanted to start from scratch and rethink everything. ... [But they did not want] to deviate too much from what developers already knew because they wanted to avoid alienating Go's target audience.[1]
Sometimes for simple problems a simple tool is the best fit.
[1]https://arstechnica.com/information-technology/2009/11/go-ne... (via wiki)
They're called tags, not annotations, per the 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.
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.
It would catch `json:"missing closing quote`; it would not catch the "josn" typo.
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.
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.