For once, I'm gonna be the one sticking up for Go here. :) Pragmas or annotations are kind of unavoidable, and I don't think that it was a mistake to include them. I wouldn't have used comment syntax, but whatever; that's a minor quibble.<p>Actually, I wish Rust had done one thing that Go did: namespacing the pragmas. That would have been a more future-proof thing to do, because macros effectively give us user-definable pragmas, and once you have user-definable pragmas you have name collision problems. Kudos to the Go team for being forward-thinking there. I suspect we'll have to figure out some kind of solution here, but it won't be as pleasant as if we had just used namespaces in the first place.
Poor Rob Pike. He always tries to make things simple, and over they time entropy always does its thing. You can hear his frustration in his cited comment.
The page is missing the best one of them all //go:linkname, which allows for linking in private functions from other packages. Including the Go runtime. For example: <a href="https://github.com/tidwall/algo/blob/master/algo.go" rel="nofollow">https://github.com/tidwall/algo/blob/master/algo.go</a>
Pragmas are always a bad idea. The Ada community has learned that the hard way. Whatever the pragma does, it should be part of the language standard and never be implementation-dependent.<p>It's time that language designers include <i>language pragmatics</i> in the core language. That includes for example big O information about data structures, packing of structures, alignment properties, memory access information, etc. Currently, in most if not all languages this information is spread all over levels, from nonstandardized compiler flags over pragmas up to the core language. It's a huge mess.
I hated the idea of using comments as directives when Go 1.4 introduced //go:generate. But, holy, they were there from the beginning?<p>They bring back my painful memories of the old days when I had to use conditional comments to support IE6...
The pragmas in Go are not intended to be used in general user code. They should be only used in Go runtime implementation and standard packages.
The pragmas in Go are just some hints for compilers. Compilers will ignore many of the pragmas used in custom user code.
> Given the race detector has no known false positives, there should be very little reason to exclude a function from its scope.<p>Performance, maybe?
Go's "pragmas" are already exposed to the developer via go generate [0].<p>Edit: Granted, this is not a directive for the compiler though.<p>[0] <a href="https://blog.golang.org/generate" rel="nofollow">https://blog.golang.org/generate</a>