[freakynit]

Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?

[piekvorst]

I think the core reasoning is about minimizing its use. I have answered [1] the same question in another thread.

https://news.ycombinator.com/item?id=47395574

[alecthomas]

These are called directives [1], and are treated as metadata by the compiler.

[1] https://pkg.go.dev/go/ast#Directive

[freakynit]

Understood... but why in comments?

[alecthomas]

Someone else said this below...

> Go designers distinguish between Go language as defined by Go spec and implementation details. > //go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language. > > If they made it part of the syntax, that would require other implementations to implement it.

...I'm not sure I buy that argument TBH.

[OJFord]

That does seem a strange argument, it could simply be `%%` (or whatever) to introduce a 'metadata comment', and then a Go implementation that doesn't support metadata would simply lex both `%%` and `//` as comments and treat them identically.

[powerpixel]

I'd buy it. AFAIK the goal of Go is to have as little breaking changes as possible between versions. Although they introduced backwards compat breaking features such as generics have they not ?

[freakynit]

hmm... thanks... And yes, I don't buy it either.

"If they made it part of the syntax, that would require other implementations to implement it." ... I mean, so what? Has golang stopped ading new features to the spec? If not (which I guess so), then how is this any different? Unless you have freezed the language, this reasoning doesn't make sense to me.

[9rx]

You are right that there could be new syntax, like, say, `@tool:name args` or `#tool.name args`, but is that any different than `//tool:name args`? They all read the same to me.

The upside of that particular syntax is that only the parser used by tools needs to understand directives. All other parser implementations can be blissfully unaware, negating the need for special no-ops. The downside is...?

[freakynit]

I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. But we don't do that, because intuitively we know that's not the right place for it.

The issue isn't that this approach is incorrect, it's that it feels out of place. A comment should be a comment, nothing more. When comments start carrying executable meaning or structured directives, they stop serving their primary purpose.

It also becomes difficult to represent anything moderately complex in a clear way. Once the structure grows beyond something trivial, readability suffers quickly.

To me, it ends up feeling like command-line arguments.. technically workable, but messy and hard to reason about. Just look at something like "ffmpeg" arguments.. and then compare that to defining the same configuration through a structured format like Yaml or Json. The latter is simply clearer and easier to maintain.

It's not wrong, but, it doesn't feel right.

[pjmlp]

This is typical Go design, other languages do it worse, it isn't really needed, and then it gets added half way as it was supposed to be if done early on, and everyone cheers how Go is a "simple" language.

Just like some other famous languages of the authors.

[frou_dh]

It's abject hackery because such "comment" directives don't even necessarily have to be a comment to be active:

    const x = `This whole thing is
    a
    //go:generate worse-is-better
    multiline
    string literal`

A lot of people in this discussion are beating up Go for using syntactical comments for directives, but in reality the implementation is even less principled than that!