[liampulles]

As someone who is regular Go programmer, yes struct tags do suck. It gets even worse if you want to try and combine multiple "annotations" into one struct tag string.

The reason its like that is that Go philosophically is very much against the idea of annotations and macros, and very strongly about the idea of a clear upfront control flow, and this is one of the reasons I love the language. But it does come at the cost of a few highly useful usecases for annotations (like mapping JSON and XML, etc.) becoming obtuse to use.

The idea of more compile-time macros in Go is interesting to me, but at the same time the ease of debugging and understanding the Go control flow in my programs is one of the reasons I love it so much, and I would not want to invite the possibility of "magic" web frameworks that would inevitably result from more metaprogramming ability in Go. So I guess I'm prepared to live with this consequence. :/

[masklinn]

> The reason its like that is that Go philosophically is very much against the idea of annotations and macros, and very strongly about the idea of a clear upfront control flow

Annotations have no control flow, they just attach metadata to items. The difference with struct tags being that that metadata is structured.

[liampulles]

Yes, apologies I was not very clear here: What I meant to say is that Go avoids annotations because it invites magic frameworks and other types of metaprogramming that do the work for you behind the scenes.

[valenterry]

I understand your feeling. There are many magical frameworks like e.g. Spring that do these things and it's super hard to figure out what's going on.

The solution is usually to have an even better language. One, where the typesystem is so powerful, that such hacks are not necessary. Unfortunately, that also means you have to learn that typesystem to be productive in language, and you have to learn it more or less upfront - which is not something that Google wanted for golang due to the turnover.

[liampulles]

I don't think it's so much a question of a better language so much as a different language. There are obviously tradeoffs one makes with all language designs.

What might be interesting is a language ecosystem, where one can write parts of a system in one language and other parts in another. The BEAM and JVM runtimes allow for this but I don't think I've seen any good examples of different languages commingling and playing to their strengths.

[valenterry]

Well, what I meant is that there is some language feature missing. So either the language gets "better" in the sense that this feature is being added, or a different language is chosen, that is already "better" in that the feature already exists. So yeah.

> The BEAM and JVM runtimes allow for this but I don't think I've seen any good examples of different languages commingling and playing to their strengths.

Probably because the runtime is always the lowest common denominator. That being said, there are lots of tools e.g. written in Scala but then being used by Java, such as Akka or Spark. And the other way around of course.

[theasisa]

I find the most annoying thing to be that there is no standard for separate values or field in the tag string. Sometimes you use a comma (json) sometimes a semicolon (Gorm IIRC) etc. This has caused me several headaches.