Go Lang: Comments Are Not Directives

CGO, for example, expects a comment immediately before a special import statement. A blank line between that comment and the import statement means that the comment is not attached to the import statement's AST node, and so is ignored. This confused me a fair amount when I started with CGO.

Part of the problem with comment syntax is that it's intentionally lexical and uniform. This simplicity means that you can easily obliterate the content of comments at any point in the input file stream via the tokenizer. However, Go instead has to bend over backwards in it's compiler toolchain to preserve comments beyond the lexer: in the parser, AST, code generator, etc.

Compare to docstrings in SmallTalk/Python/Clojure, where they are actual parsed string literals. Also compare to C#, which has explicit and distinct syntax for comments, metadata, and compiler directives. Comments can be inserted more or less anywhere. Metadata only where it's unambiguously attached to an AST node. And directives similarly to statements, unambiguously detached from other AST nodes.

With proper syntax for metadata, the CGO case would have been a compile time error about no AST node for the metadata to be attached to.

With proper syntax for directives, the //go:generate string-scanning bug would have never happened.

These syntaxes must be disjoint from comment syntax to eliminate the problems.

the main problem is not technologie but semantic. If you agree with me that the meaning of a comments is communication between humans, than you must also agree - in my opinion - that comments can not be directives to a tool chain.

It is ambiguous. It is error prone. It is easily solved using an other token.

And in the long run it may lead to madness like Java testing and documenting frameworks.

as for technical problems - I think some really bad ones are mentioned in this very discussion!

This in itself isn't bad, but the problem it causes is that the Googlers (who do not experience the pain that other users of the language do) are still the majority voice in any decision. Maybe not in numbers, but definitely in weight.

There have been a number of changes pushed through that make sense in Google's use case but not for general development use. Stuff like declaring a folder named "internal" special where it wasn't before. Perfectly understandable in Google's internal uniform codebase, where nearly every package is understood and the world is small. Not a smart change to make a few years into the 1.0 compatibility freeze though, since you can bet that a lot (I even dare say a majority) of 'regular' developers won't know about this and might run into problems because of this at one point or another.

This is just a small example that I can recall out of the top of my head but my worry is that this is happening more often with a lot of features.

Counterarguments from Googlers are usually along the line of "Go has X contributors, only Y of which are Googlers", but that is not the full truth. The top 5 contributors are still employed by Google. If you read the golang-dev mailing list, especially when it comes to discussions about tooling and ecosystem, you'll see that the Googlers have an overwhelming voice and will not shy away from flat-out rejecting criticism to proposals that might be nice for Google's use case but cause ambiguity and complexity for other developers.

Having said that, I still love the language and design. I just whished they shied away from magic comments and half-baked solutions for dependency management.