16 ms·

Go Lang: Comments Are Not Directives

279 points by Merkur 11y ago

Go 1.4 starts to use comments as directives. I think that is a realy bad path to go on the long run. You see its beginnings in following 3 examples: # used to set a canonical import path for a package: //import "foo" # used to generate code: //go:generate bar # used to document the result of a example function: //Output: foo Comments should not be directives. Comments are free form, they do not have a syntax (as demonstrated in the examples). Comments are for humans - programms should ignore them or threat them as - comments! It is my optinion that if Go needs some kind of annotation, than there should be a new syntax for it. I would propose that directives to the tool chain will be marked with #TAG: DIRECTIVE a tool would be able to register the TAG with the go build environment. If a TAG is found in the code - the tool is called to do what ever needs to be done.

aikah 11y ago
I 100% agree. You want macros? I don't like it but think about proper macros. Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with". Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs for idiots with half baked solutions. So don't use comments for anything but documentation generation purpose. .
- enneff 11y ago
  > Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with", which is ,at the minimum, insulting. Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs for idiots with half baked solutions. That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience. "go generate" is a mechanism for invoking code generation tools; tools that people were already using in a variety of ad hoc ways. That's all. Macros are another thing entirely. Our conservatism should be a testament to how much we care about quality. We don't want to do anything by half measures, as that serves no one's interests.
  - aikah 11y ago
    My apologies if I sounded a bit rough. I know and like your conservative approach and respect your work. I just think that's not a good feature, at all. Because once you start adding pragmas in comments, where does it stop? I'm a bit emotional about it because I love Go,I use it everyday and have been successful with it. If i didn't I wouldn't be writing about it.
  - zak_mc_kracken 11y ago
    > Our conservatism should be a testament to how much we care about quality. Offering code generation as a solution to code reuse is not caring about quality, it's laziness.
    - dward 11y ago
      It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?
      - threeseed 11y ago
        Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork. Saying "it's open source so you can just add feature X or change feature B" only works if you are part of some core team or are respected via other means. Github is littered with projects that have lots of Pull Requests that never get pulled.
        yarou 11y ago
        I'd argue that making the changes you desire in an open-source project and forking the project is immeasurably more productive than complaining about it on HN. (IMHO) There are many cases where project forks become more popular than the original project itself.
        zak_mc_kracken 11y ago
        > Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork. Or d) that I have any time in my life to undertake such work.
      - coldtea 11y ago
        It's a project were all decisions taken by the core 3-4 person team are final and absolute. Open-source != bazaar.
  - coldtea 11y ago
    >That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience. As long as it aligns 100% with the bizarro ideas of the core team regarding comment pragmas, code generation, vendoring, generics, etc.
  - rattray 11y ago
    (I regularly downvote comments that are negative, and leave comments explaining why I found the comment to be negative). I actually don't think this was an unfair phrasing. I had actually felt insulted when `go generate` was announced. "You're sweeping [generics et al] under the rug using comment-bound directives and telling me it's an elegant solution to problems? Do you think I'm an idiot?" Was, in fact, very close to what went on in my head when I read that initial post/slideshow. I don't like to be degrading when it comes to differing opinions on coding practices - if generated code and comment-bound directives are good for you, well, okay - but being told that I should like it and stop questioning? That's insulting. I think the deeper complaint that's coming through is not that the Go team are bad language designers who don't care about the developer experience, but that they are condescending towards the community. Even if you really, really don't mean to be.
    - j1436go 11y ago
      Well, I get quite the opposite impression of condescending with them hanging around HN and golang nuts discussing language issues. And I'm actually fine with them making the decisions in the end. Go wouldnt be as clear and productive as it is today if every request for a feature would find it's way into the language in some half-hearted manner.
      - rudolf0 11y ago
        Isn't comment-driven code generation kind of the definition of a "feature request implemented in a half-hearted manner"? People asked for generics and got this. It seems like the kind of suggestion most language designers would throw out as unelegant. If the language is so conservative as people claim, it should have neither macros/generics nor any of these pseudo-macro-generic-y half-measures.
enneff 11y ago
(You left out "// +build", which predates Go 1.4.) We made the decision that "//go:" is the syntax for comment directives. The old ones stay around for compatibility reasons. Previous discussion: https://groups.google.com/forum/#!searchin/golang-dev/comments/golang-dev/r4rdPdsH1Fg/yjOOzqIqNPMJ https://groups.google.com/forum/#!searchin/golang-dev/commen...
- TheDong 11y ago
  Also 'cgo' comments which are fairly old. See: https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ For an example of what this looks like in actual use, see the very popular go-sqlite3 library: https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e97971fac64fa5bff4ef0934f4/sqlite3.go#L8 https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e9797... I personally think that large block-comments of code that actually do something, but only if above a certain import really strange and unexpected; it means re-ordering imports can break things, changing around spacing can break things, and tons of other things.
- eis 11y ago
  If this has to reside in comments, will the old directives be updated with aliases for the new convention? So the old ones can be kept around for backwards compatibility (maybe with a warning) but codebases could still be updated to be consistent. All of these of course are minor things. Go does a lot of things very right like easy of concurrency, scope and quality of the standard library and easy of deployment. Looking forward to the GC improvements in the near future as well as a day when we get generics. I'll be a happy camper then.
- vorg 11y ago
  And there's //line path/to/file:linenumber and //go:noescape
  - ominous_prime 11y ago
    don't forget //go:nosplit too
bsaul 11y ago
Agree as well. They could use the same convention as typescript and use a triple slash instead. That wouldn't change much of the language and impact IDEs, but at least distinguish between human comments and tooling instructions.
- enneff 11y ago
  What's the difference between "///" and "//go:"? The latter is Go's official convention, it's just that unfortunately some of our older mechanisms predate the convention.
  - bsaul 11y ago
    None, i just didn't know about //go: :)
  - Merkur 11y ago
    no difference - both are misused comments. 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!
  - anatoly 11y ago
    What do you mean "Go's official convention"? Go is a language; it has a spec. Is it in the spec? No. What is this "Go" that this is an official convention of, and where is it standartised beyond your comment?
  - tomjen3 11y ago
    Realistically there is no big difference between /// and //go: although the former is well used (Java, C# and, probably more importantly for Golang, jsdocs are written as /). Either would be useful. But the complaint is about //foobar: and that is just confusing.
TheDong 11y ago
Want to know what's even worse? Using comments for something but not parsing the syntax tree. In go 1.4, save the following to a file and run 'go generate' on it: https://play.golang.org/p/9WJtxClRXr https://play.golang.org/p/9WJtxClRXr (I'd make it run in the playground, but you can't 'fork exec', so exec.Command($GOBIN, generate) won't work sadly) Even though that code has no comments (only a multi-line string), go generate will run and print out a '\'. I also used that generate command to point out that with generate, as it exists in 1.4, there's actually NO WAY to print out a dollar sign. The dollar-sign part of this is fixed in master (so go1.5), but it was fixed not by allowing '\$', but by the bizarre $DOLLAR environment variable. See https://go-review.googlesource.com/#/c/8091/ https://go-review.googlesource.com/#/c/8091/ These "features" make the use of comments as directives even worse, because it's NOT comments being used as directives in the case of go generate, but simple string matching. It literally just loops through lines of text and checks if it startswith the correct substring. This was, of course, done due to lazyness (same as $DOLLAR and many other 'features' of go), and the lazyness is starting to show through the cracks here and there. Go often prefers pain for the programmer for the compiler developer's life being simpler by about 5 minutes.
- eis 11y ago
  That's pretty bad. I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. Which is amplified by the previous statements regarding for example generics where they said they wont introduce them until they find a really good way to do it but then crank out half baked stuff like this.
  - coldtea 11y ago
    >I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. I think that was the case with Go from the start. Can you think of some aspect that was especially well thought-out?
nulltype 11y ago
I don't really agree. I don't see any substantial difference between //go: and #go: except that programs using the # syntax would not build on older versions of go. I haven't really run across any issues with the current syntax. What kind of issues are you having?
- masklinn 11y ago
  The difference is that an innocuous comment can (and inevitably will, especially since Go apparently does not actually care about comments, only that a line starts with //go:[0]) match the directive syntax at some point and then it's a right pain in the ass to debug, if that doesn't break anything. [0] https://news.ycombinator.com/item?id=9523187 https://news.ycombinator.com/item?id=9523187
  - nulltype 11y ago
    I think they should fix that bug where it's not actually looking at the comments. However, with the exception of that bug, I don't think I have ever made a comment that started with "//go:" and was not a directive. It seems kind of hard to make one of those by accident.
- threeseed 11y ago
  Doesn't Go complain about unused imports ? So what if you have a bit of code that you are half way through and you want to comment it out as well as the imports. I've done this countless times over the years.
  - nulltype 11y ago
    Yeah me too, and I can't recall that ever causing an issue with these comment directives.
marcus_holmes 11y ago
At last! I'm not insane! I raised this on the golang dev forums and got nowhere: https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOzqIqNPMJ https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOz... The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.
- EugeneOZ 11y ago
  I remember I reacted hysterically in Twitter about this change, somebody gave me link to your post and after reading first response of Brad Fitzpatrick I realized there's no chance for arguing or discussion - all decisions are final and community feedback isn't required.
  - pfortuny 11y ago
    This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link). http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-editor.html http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...
    - marcus_holmes 11y ago
      I don't know what your reaction to that response was, whether you stuck with acme or not, but I'm now looking for another language to use instead of Go. I thought at first that this reaction was just sour grapes ("nasty people on the intertubes didn't like my post"), but as I analysed it more I managed to pull out three elements: 1. If my sense of elegance and the Go team's sense of elegance is this divergent, then the language will probably get uglier to my eyes as it continues to evolve. 2. If this is the reaction from the team to this (relatively small and inexpensive to fix) problem, then we can expect absolutely no movement at all on the bigger and harder problems (dependency versioning, generics). I used to have faith that these very smart people will come up with an elegant solution to these issues - I still love the simplicity and elegance of the standard library - but my faith has now gone. 3. Brad's response was amazing and I'd follow him anywhere, but... I don't want to follow the rest. If I'm to commit my time and effort to learning (and to a tiny extent popularising) the language and being part of the community, I want to believe in the people building it. I don't any more. Humans are weird.
jdkanani 11y ago
I couldn't agree more. It also makes code hard to read. I have to look closely to check if that's a comment or directive. It would be problem when your code grows. I am in favor of #TAG: DIRECTIVE or @TAG:DIRECTIVE
brandonbloom 11y ago
Comments are also not metadata! 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.
- xyproto 11y ago
  Agree. Something like decorators could have been used instead.
  - _pmf_ 11y ago
    Go is typical "hurr durr, Java an C# are obsolete" write-only code by people who only ever work on ephemeral greenfield projects with a lifetime of 3 months and therefore can tell exactly what software development is all about.
    - fixxer 11y ago
      Such an inflammatory troll... Do you you even know who is involved in the Go project?
dvirsky 11y ago
This pattern predates Go 1.4, we've had it with CGO and build tags since at least 1.0 AFAIK. Even the Output in examples is pretty old I think. The only advantage in it is backwards compatibility with older Go versions, but in general I agree with you. When PHP did it for Python-style decorators everyone thought it was stupid. And while the build tags in Go are okay by me, doing it for CGO especially seems like a hack.
- mappu 11y ago
  AFAIK PHP doesn't provide python-style decorators and never executes code within comments. Can you cite that? Or are you maybe using a framework or library that's re-parsing your source files?
  - EugeneOZ 11y ago
    PHP never execute comments, be sure. Some frameworks and tools like Doctrine use comments and reflections to prepend comments are annotations, and it's one of the reasons why these frameworks are slow as hell.
  - dvirsky 11y ago
    Yeah you're right, my bad, I vaguely remembered it but it was a framework I was using, not the language itself. Still stupid anyway.
saintfiends 11y ago
Partially agreed. Directives should be visually distinct from comments and syntax should be formally defined such that compilers, code generators, editors and IDE's can use them consistently.
- NateDad 11y ago
  The compiler doesn't need to care about these directives. They don't have anything to do with the compiler. That's half the reason they're in comments. Otherwise you're just adding another kind of comment the compiler has to also ignore. The directives are pretty visually distinct. You could easily configure your editor to highlight them differently if you so chose.
  - saintfiends 11y ago
    1. I don't understand what you mean by "They don't have anything to do with the compiler" https://golang.org/cmd/gc/#hdr-Compiler_Directives https://golang.org/cmd/gc/#hdr-Compiler_Directives 2. I could keep adding syntax support as they come along and handle all the inconsistencies, but that is not a solution. It's a hack.
breakingcups 11y ago
The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). 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.
- teddyh 11y ago
  I tried to argue this five months ago when Go 1.4 was released: https://news.ycombinator.com/item?id=8733705 https://news.ycombinator.com/item?id=8733705 I was severely downvoted and did not get many who agreed with me.
  - deleted 11y ago
    [deleted]
- Spiritus 11y ago
lohengramm 11y ago
I also do not agree with that. This is bad for so many reasons. First, to the compiler code, comments should be discarded as soon as possible (often in the lexer). To the programmers, comments should never execute anything (this is just intuitively expected). To any go source code reader (human or machine), comments are supposed to contain only human readable text, probably a context sensitive explanation of that particular section of code. To the separation of concerns, comments are comments and compiler directives are compiler directives. To each his own. This is probably the only decision I disagree with the Go team to date.
- xyproto 11y ago
  Fully agree. I love Go and use it for anything related to servers or the web, but doing anything with comments besides just letting them be comments, is just braindead.
  - andrewchambers 11y ago
    They aren't used by the compiler at all.
    - ominous_prime 11y ago
      //#cgo //go:nosplit //go:noescpae are all used by the compiler in one way or another
      - andrewchambers 11y ago
        nosplit and noescape are internal details which are implementation specific.
        ominous_prime 11y ago
        All of these are implementation specific. That's one reason they're in comments, and not listed in the language spec.
hartcw 11y ago
Although I don't use go (yet), I can see the benefit of this mechanism as I use a similar one for my own c/c++ code. There I use specially tagged comments to embed python in the c/c++ sources, and then run all the code through a python interpret stage to expand/execute the python code before compiling it. Actually it supports C macro style for the embedded code, which is a bit more sensible than misusing code comments. For example for generating a c/c++ enum: enum example_t { #py \ for line in open('values.txt'): \ print('EXAMPLE_' + line.strip() + ',') EXAMPLE_Max, EXAMPLE_Unknown }; Or alternatively to stuff it in a comment: enum example_t { /* py for line in open('values.txt'): print('EXAMPLE_' + line.strip() + ',') */ EXAMPLE_Max, EXAMPLE_Unknown }; If anyones interested, heres the python script I use to preprocess the c/c++ files https://github.com/hartcw/cppy https://github.com/hartcw/cppy
- threeseed 11y ago
  Sure the concept is definitely useful. But overloading comments seems monumentally dumb. They should have copied Java's annotation model which makes a lot more sense.
- copsarebastards 11y ago
  That's a valid thing to do in C++ because the language doesn't support alternatives. And you can't really expect it to, because C++ has tried various things over the years that make this much harder to add ex-post facto. However, it's worth noting that using such tooling in C++ can cause more problems than it solves if you aren't careful. This is just one of the ways C++ is showing its age. These problems are exactly why this is unacceptable in Go. Go has the benefit of learning from C++'s mistakes and seeing other attempts at solutions to the problem. Language designers have made these mistakes before, realized they were mistakes, and come up with better alternatives. This is just another example of the Go team either being unaware of or ignoring decades of development in programming languages.
- myg204 11y ago
  Interesting. Why don't you use an include file directive there? enum_example_t { #include "example_values.txt" EXAMPLE_Max, } where example_values would have the strings 'EXAMPLE_foo,'? Just wondering.
aablkn 11y ago
Oh don't forget the good old // +build !linux build constraints feature. It's been there since go 1.0 afaik.
erikb 11y ago
What does the word directive mean? Doing stuff by parsing comments is called a macro processor (or preprocessor, but it doesn't have to be done before the actual processing) or not? I think there are many instances where macro processors are a good thing. Some languages have them in the core. So what's the difference between macros and directives?
- Merkur 11y ago
  I would define a directive as an instruction to the tool chain. A macro processor could be one of those tools in the chain. There could be other (and Go implements other use cases!) I would also argue that a macro preprocessor do'snt need to "parse comments", it could parse any syntax the preprocessor wants to (and remove it from source befor the compiler sees it) In fact my point is, that parsing comments at all is a very bad idea. But my argument is NOT about, if Go needs a macro processor, or not. (i think it dont!) My argument is about the syntax of the directive. I argue about the syntax of declaring "Here comes something that is not Go Language!" I argue that this syntax should not be a comment - because a comment is part of the Go Language. (...among other reasons i stated in this discussion)
  - erikb 11y ago
    Okay, now I get it. Thanks for clearing that up. I have to agree that adding features into comments instead of new language blocks or frameworks is smelly.
    - Merkur 11y ago
      thank you, for beeing open to be convinced :)
rjsw 11y ago
Lisp has used directives in comments in the past. Only on the first line of a file but they were parsed.
- Grue3 11y ago
  That had to be very distant past or some non-standard lisp. Common Lisp has no such feature.
  - rjsw 11y ago
    It was done on Lisp Machines and currently in CCL.
  - lispm 11y ago
    That's a feature of the Lisp IDE. File mode lines described language, the syntax (which Lisp dialect), the Package, the numeric base, the encoding, ... Example: ;;; -*- Mode: lisp; Syntax: ANSI-Common-Lisp; Package: http; Base: 10 -*- But to implement compiler directives in Common Lisp, this is not needed. That can already be done with macros and reader macros. If you for example use a macro in source code, the compiler will need to expand it. That allows arbitrary code execution during compilation.
egeozcan 11y ago
To this day, I still couldn't figure out why Go stays at the edge of being a great language, but lacks few very essential features for -to me- inexplicable reasons. Look at all the work done on JavaScript to generate code from macros and how incompatible the libraries became (JSX, sweet.js, TypeScript and so on). If there's no standardization, I'm afraid, go may have the same destiny. If anyone on the Go core team is reading this, I'd like you to consider adding proper macros to the language.
- rudolf0 11y ago
  A more conservative approach to macros would also just be... generics.
donatj 11y ago
I honestly even feel weird about godoc just being standard comments, in my mind docs and comments are different things, docs usually being noted with / * * (no spaces, but can't figure out how to escape) and comments being /* // or #
Dewie3 11y ago
If you're feeling paranoid and don't have time to look up the set of magical incantations, maybe you should write your actual comments like this: // COMMENT we have to check that [...] :)
- Merkur 11y ago
  Code should not be magical. Magic is bad engeneering. Magic involving a whitespace is madness.
  - Dewie3 11y ago
    My intent was to poke fun at the current state of things. Not to give actual advice. :)
nicerobot 11y ago
Just because _you_ are locked into a mentality about a meaning for // does not mean we all are. Explain to me why formatted/structured text can not appear after a // in a file. If your editor parsed the text and formatted it to look meaningful, like code, would that help?
- henesy 11y ago
  I'm not sure why it bothers everyone so much. I might be missing something, but unless people are writing their comments in a very specific style then it shouldn't cause issues. From the help: "(note: no leading spaces and no space in "//go") where command is the generator to be run, corresponding to an executable file that can be run locally." It just seems like the code is distinctive enough it shouldn't cause problems. Or, if style should be adjusted, why not write your "not code" comments using the /* */ style?
  - stefantalpalaru 11y ago
    What part of "all syntax should be validated" don't you understand? By putting that syntax in comments, syntax errors will not trigger any output from the tools because they remain valid free-form comments.
    - henesy 11y ago
      And they're not "Go" syntax. The syntax in the comments if for Go tools. A better approach may be to provide a more extensive syntax checking tool that parses comments and checks for syntax errors on a per-tool basis, but as I understand it it would seem that the implementation as it is now is aimed at the auxiliary Go tools, standardizing the syntax for the tools, thus allocating potential for future tools to expand without extensive maintenance on the core language itself. The tools are not the core language, but there should probably be some form of syntax checkers for the tools, but perhaps encapsulated within the tools. The comments are still comments to the actual Go code, as they are not pertinent to the language itself, but rather an outside entity such as a tool. It is also entirely possible that I am missing the point entirely and do not understand.
donlzx 11y ago
Comments are just comments, we should not keep adding keywords and syntax to them. Go's backward compatible promise is hurting itself. By sticking with strict compatibility mode, ad hoc solutions for fundamental issues are added from time to time. Sooner or later, those patch works will back-fire. For a language so young (version 1.0 in 2012), they should keep compatibility for stable release (1.x), but start adding language features in 2.x branches ASAP. Yes, compatibility promise may help selling the Go language at the beginning, but Go authors may seem a little too confident/optimistic of the language spec. in this case. If a 2.x branch is not coming out soon enough (in about two year), we will probably face the same dilemma as Python 2 vs 3.
- Merkur 11y ago
  One of the best features of go is "go fix" Yea! A migration tool for the language it self? Before they need to worry about compatibility they can break a lot of stuff.
  - donlzx 11y ago
    Yeah I know, we can easily fix the codes with tools, we also have tools for conversion between Python 2 and 3, right? However, we can not easily fix the way people writing the code, or the so-called idiomatic Go norms. Actually, it is compatibility in the ecosystem of Go packages that matters. We have lots of good Go packages on Github that are no longer compatible with Go 1.0/1.1/1.2 etc.
cjslep 11y ago
Sad to see Go is fully going the way of Intel's Fortran compiler. It was more reasonable when (I think in cgo) you needed to export functions, which is done in Intel-compiled Fortran like so: !DEC$ ATTRIBUTES DLLEXPORT :: NameOfSubroutine Also at least Visual Studio will color those comments differently than normal comments.
bane 11y ago
As soon as you start using comments for something other than comments or documentation, you've basically admitted the language is broken and you end up becoming Java.
- Ygg2 11y ago
  Funny that you mention it, but Rust also checks all code in comments/documentation for validity, and runs test on your comments and catches if any of them fails to compile/return appropriate result.
  - tomjakubowski 11y ago
    No it doesn't. Rustdoc examines the "doc" attribute on every item for Markdowk code blocks and checks those. The "doc" attribute can be attached to an item directly, using Rust's general attribute syntax, or using so-called "doc comments" which are visually and lexically distinct from ordinary comments. In the case of single line comments (the preferred style), doc comments have three slashes instead of two; a good IDE or editor mode for Rust will highlight doc comments differently than ordinary ones.
    - Ygg2 11y ago
      Right, but it's nearly identical to having instructions in comments, like Go does. And while the post I was implying seems to think this isn't a valid use case, I think it is.
- oldmanjay 11y ago
  I don't understand the conclusion. Java is certainly verbose and a fair bit aggressively ugly, but it has consistent syntax and I've never before heard anyone describe it as broken. care to amplify?
  - bane 11y ago
    Well, not exactly comments, but Java's annotation system is an ugly kludge that should be part of the language and not an attempt at reintroducing C-style compiler directives. The abuse they suffer under various frameworks and ORMs is one of the ugliest things I've ever seen in a language. In almost every-case they either serve little to no purpose, or would be better-off just being part of the language syntax. But now you have to learn Java, and the Java-annotation meta-system. At least they aren't written in XML. note I actually don't mind the Java Community's habit of usingLongNames for things, and the actual language is pretty small and nice.
_yosefk 11y ago
One language where this is currently practiced is Verilog. To make things spicier, different vendors have different syntax for semantics-changing comments, often prefixed with the vendor's name. One "benefit" of this is that an older tool not updated to include the new syntax embedded in the comments will remain blissfully unaware of its ignorance, instead of spitting an error message. Another "benefit" is that a programmer unaware of the syntax might delete or copy & paste such comments when doing massive editing, without realizing that they aren't comments. To achieve the latter, it helps if the syntax looks like English or, better yet, if it looks like commented-out code (and, come to think of it, it's not unlikely that it will look like at least one of these things.)
yyhhsj0521 11y ago
In Python, following comment #--utf8-- indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.
- mpdehaan2 11y ago
  I was going to say it's the only one Python 2 has, AFAIK. So they've kept it reaosnable there, but then I remembered this: https://www.python.org/dev/peps/pep-0484/#id24 https://www.python.org/dev/peps/pep-0484/#id24 Which is pretty scary, IMHO. Python is productive, but I always questioned some of the choices in the language design (broken lambdas, etc -- though the implementation of list comprehensions were great so I just learned to love them) -- but it seems to take some of the same decisions Go is taking in terms of inconsistencies now. The Go stuff, however, seems much more worse. The phrase "nothing but Perl can parse Perl" comes to mind :)
  - nchammas 11y ago
    The decision to put type annotations for variables in comments was made specifically for backwards compatibility reasons. Remember that Python has supported function annotations since 3.0 [0]. Python 3.5 will only add the option to type check those same annotations. Any type annotations that can be checked by Python 3.5 can also be parsed by earlier versions of Python, though without being checked. The only wart in this master plan is specifically the one where you want to type annotate variables (as opposed to functions). Comments are the only way they could do this in a backwards compatible way. The Python devs are well aware of the ugliness of this compromise, which is why they end the section you linked to with this: > If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version. I can't comment on Go, but I wouldn't call Python's choice here unreasonable. [0] https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/
  - kbenson 11y ago
    Python's list comprehensions always struck me as an odd way to go given Python's tendency to choose clarity and simplicity over complexity and expressiveness. As a Perl user, Python list comprehensions make me go cross-eyed half the time. It's something Perl specifically decided to forego as too complex and prone to causing confusion, which is saying something.
amelius 11y ago
To be fair, it all started with #!/bin/sh
turrini 11y ago
//go:fancy seems more appropriate.
fixxer 11y ago
Meh. I hear your gripe, but I think your proposed solution is not that much of an improvement. You're also basing all of this on the idea that comments are "free form". Where is that gospel? I like the idea that comments are more than just blabber. I like the idea that, when structured some way, they take on new meanings. I think this is a semantic argument.
- Merkur 11y ago
  I too like the idea that comments are more than blabber. I do use comments like //BUG: //TODO: and //HOT: My argument is semantic? Yes it is! In my optinion thats the reason my argument is so strong. Please dont tell me you dont see a problem between //go: foor and //todo: bar - the first instructing some tool to change stuff in your build, the later merly mention that there is something left to do here. A directive like #todo: bar - is a great example for a great tool in the chain. the go tool could look for a "todo" command and this todo command could print out a warning that the code should not be released because XX todos arn't done. If the go tool would'nt find a "todo" command it could warn me that a tool in the chain is missing. I could evaluate in decide to use get this tool, or choose to ignore it. This would be imposible if comments are missused as directives!
  - fixxer 11y ago
    Now argue against yourself and prove you understand why you hit resistance.
    - Merkur 11y ago
      if you can agree that i got arguments that convince - i do you the favor. :)
      - fixxer 11y ago
        I agree that you have raised an argument. I haven't read anything to indicate you understand the issue at a higher level. It would definitely help me respect your argument as sincere if you argued the counter with sophistication.
scott_s 11y ago
I don't know enough of the matter to have an informed view, but I think it's worth noting that there is precedent for this sort of thing. Take from one of my Python scripts: #!/usr/bin/env python http://en.wikipedia.org/wiki/Shebang_%28Unix%29 http://en.wikipedia.org/wiki/Shebang_%28Unix%29
- bozoclownn 11y ago
  I would add that this technically is a (ba)sh script, not a Python script.
  - tangent128 11y ago
    On *nix systems, the #! is parsed by the kernel as a magic number. sh/bash are not involved.
    - bozoclownn 11y ago
      Thanks, didn't know!
  - stefantalpalaru 11y ago
    No, you can use any program to launch executable scripts that start with #!. The kernel sees that magic number at the beginning of the file, tries to read a program path and arguments, adds the script as the last arg and executes the whole thing. The various shells are just a subset of the possible programs used.
copsarebastards 11y ago
What's the point of having a single-pass compiler if you have to add hacky precompilation steps to make up for its shortcomings? If you're passing over the code multiple times anyway then it defeats the purpose.
fredkbloggs 11y ago
The basic syntax of Go is C-like (this is not intended to be controversial), including that of comments. There is also a C syntax for communicating with the compiler: #pragma. There is no need for yet another syntax here. Just follow the example set by the language that has already heavily influenced the Go syntax. Note that C compilers already have the attributes people are demanding here: pragma directives are parsed, unknown pragmas generate errors or warnings, they are both visually and syntactically distinct from comments (intended for humans, not the toolchain), etc. Solved problem. There's no reason to invent new syntax here.
khanhussan 11y ago
:p -_- very nice
anacrolix 11y ago
I think the same can be said of the . selector on packages.

279 points by Merkur 11y ago

aikah 11y ago

I 100% agree. You want macros? I don't like it but think about proper macros. Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with". Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs for idiots with half baked solutions. So don't use comments for anything but documentation generation purpose. .

enneff 11y ago
> Go generate is just sweeping issues under the carpet and say to developers "it has been dealt with", which is ,at the minimum, insulting. Nobody expects a language to be perfect, but sometimes I feel the Go team takes devs for idiots with half baked solutions. That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience. "go generate" is a mechanism for invoking code generation tools; tools that people were already using in a variety of ad hoc ways. That's all. Macros are another thing entirely. Our conservatism should be a testament to how much we care about quality. We don't want to do anything by half measures, as that serves no one's interests.
- aikah 11y ago
  My apologies if I sounded a bit rough. I know and like your conservative approach and respect your work. I just think that's not a good feature, at all. Because once you start adding pragmas in comments, where does it stop? I'm a bit emotional about it because I love Go,I use it everyday and have been successful with it. If i didn't I wouldn't be writing about it.
- zak_mc_kracken 11y ago
  > Our conservatism should be a testament to how much we care about quality. Offering code generation as a solution to code reuse is not caring about quality, it's laziness.
  - dward 11y ago
    It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?
    - threeseed 11y ago
      Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork. Saying "it's open source so you can just add feature X or change feature B" only works if you are part of some core team or are respected via other means. Github is littered with projects that have lots of Pull Requests that never get pulled.
      - yarou 11y ago
        I'd argue that making the changes you desire in an open-source project and forking the project is immeasurably more productive than complaining about it on HN. (IMHO) There are many cases where project forks become more popular than the original project itself.
      - zak_mc_kracken 11y ago
        > Just because it is open source does not me (a) that your changes will be mainlined, (b) that your changes will be even considered or (c) that you will logistically be able to maintain an ongoing fork. Or d) that I have any time in my life to undertake such work.
    - coldtea 11y ago
      It's a project were all decisions taken by the core 3-4 person team are final and absolute. Open-source != bazaar.
- coldtea 11y ago
  >That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience. As long as it aligns 100% with the bizarro ideas of the core team regarding comment pragmas, code generation, vendoring, generics, etc.
- rattray 11y ago
  (I regularly downvote comments that are negative, and leave comments explaining why I found the comment to be negative). I actually don't think this was an unfair phrasing. I had actually felt insulted when `go generate` was announced. "You're sweeping [generics et al] under the rug using comment-bound directives and telling me it's an elegant solution to problems? Do you think I'm an idiot?" Was, in fact, very close to what went on in my head when I read that initial post/slideshow. I don't like to be degrading when it comes to differing opinions on coding practices - if generated code and comment-bound directives are good for you, well, okay - but being told that I should like it and stop questioning? That's insulting. I think the deeper complaint that's coming through is not that the Go team are bad language designers who don't care about the developer experience, but that they are condescending towards the community. Even if you really, really don't mean to be.
  - j1436go 11y ago
    Well, I get quite the opposite impression of condescending with them hanging around HN and golang nuts discussing language issues. And I'm actually fine with them making the decisions in the end. Go wouldnt be as clear and productive as it is today if every request for a feature would find it's way into the language in some half-hearted manner.
    - rudolf0 11y ago
      Isn't comment-driven code generation kind of the definition of a "feature request implemented in a half-hearted manner"? People asked for generics and got this. It seems like the kind of suggestion most language designers would throw out as unelegant. If the language is so conservative as people claim, it should have neither macros/generics nor any of these pseudo-macro-generic-y half-measures.

enneff 11y ago

(You left out "// +build", which predates Go 1.4.) We made the decision that "//go:" is the syntax for comment directives. The old ones stay around for compatibility reasons. Previous discussion: https://groups.google.com/forum/#!searchin/golang-dev/comments/golang-dev/r4rdPdsH1Fg/yjOOzqIqNPMJ https://groups.google.com/forum/#!searchin/golang-dev/commen...

TheDong 11y ago
Also 'cgo' comments which are fairly old. See: https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ For an example of what this looks like in actual use, see the very popular go-sqlite3 library: https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e97971fac64fa5bff4ef0934f4/sqlite3.go#L8 https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e9797... I personally think that large block-comments of code that actually do something, but only if above a certain import really strange and unexpected; it means re-ordering imports can break things, changing around spacing can break things, and tons of other things.
eis 11y ago
If this has to reside in comments, will the old directives be updated with aliases for the new convention? So the old ones can be kept around for backwards compatibility (maybe with a warning) but codebases could still be updated to be consistent. All of these of course are minor things. Go does a lot of things very right like easy of concurrency, scope and quality of the standard library and easy of deployment. Looking forward to the GC improvements in the near future as well as a day when we get generics. I'll be a happy camper then.
vorg 11y ago
And there's //line path/to/file:linenumber and //go:noescape
- ominous_prime 11y ago
  don't forget //go:nosplit too

bsaul 11y ago

Agree as well. They could use the same convention as typescript and use a triple slash instead. That wouldn't change much of the language and impact IDEs, but at least distinguish between human comments and tooling instructions.

enneff 11y ago
What's the difference between "///" and "//go:"? The latter is Go's official convention, it's just that unfortunately some of our older mechanisms predate the convention.
- bsaul 11y ago
  None, i just didn't know about //go: :)
- Merkur 11y ago
  no difference - both are misused comments. 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!
- anatoly 11y ago
  What do you mean "Go's official convention"? Go is a language; it has a spec. Is it in the spec? No. What is this "Go" that this is an official convention of, and where is it standartised beyond your comment?
- tomjen3 11y ago
  Realistically there is no big difference between /// and //go: although the former is well used (Java, C# and, probably more importantly for Golang, jsdocs are written as /). Either would be useful. But the complaint is about //foobar: and that is just confusing.

TheDong 11y ago

Want to know what's even worse? Using comments for something but not parsing the syntax tree. In go 1.4, save the following to a file and run 'go generate' on it: https://play.golang.org/p/9WJtxClRXr https://play.golang.org/p/9WJtxClRXr (I'd make it run in the playground, but you can't 'fork exec', so exec.Command($GOBIN, generate) won't work sadly) Even though that code has no comments (only a multi-line string), go generate will run and print out a '\'. I also used that generate command to point out that with generate, as it exists in 1.4, there's actually NO WAY to print out a dollar sign. The dollar-sign part of this is fixed in master (so go1.5), but it was fixed not by allowing '\$', but by the bizarre $DOLLAR environment variable. See https://go-review.googlesource.com/#/c/8091/ https://go-review.googlesource.com/#/c/8091/ These "features" make the use of comments as directives even worse, because it's NOT comments being used as directives in the case of go generate, but simple string matching. It literally just loops through lines of text and checks if it startswith the correct substring. This was, of course, done due to lazyness (same as $DOLLAR and many other 'features' of go), and the lazyness is starting to show through the cracks here and there. Go often prefers pain for the programmer for the compiler developer's life being simpler by about 5 minutes.

eis 11y ago
That's pretty bad. I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. Which is amplified by the previous statements regarding for example generics where they said they wont introduce them until they find a really good way to do it but then crank out half baked stuff like this.
- coldtea 11y ago
  >I think the reason why people are so upset/surprised is because they expect better from the Go team. Sometimes it really feels like they take the lazy route without putting enough thought and polish into things. I think that was the case with Go from the start. Can you think of some aspect that was especially well thought-out?

nulltype 11y ago

I don't really agree. I don't see any substantial difference between //go: and #go: except that programs using the # syntax would not build on older versions of go. I haven't really run across any issues with the current syntax. What kind of issues are you having?

masklinn 11y ago
The difference is that an innocuous comment can (and inevitably will, especially since Go apparently does not actually care about comments, only that a line starts with //go:[0]) match the directive syntax at some point and then it's a right pain in the ass to debug, if that doesn't break anything. [0] https://news.ycombinator.com/item?id=9523187 https://news.ycombinator.com/item?id=9523187
- nulltype 11y ago
  I think they should fix that bug where it's not actually looking at the comments. However, with the exception of that bug, I don't think I have ever made a comment that started with "//go:" and was not a directive. It seems kind of hard to make one of those by accident.
threeseed 11y ago
Doesn't Go complain about unused imports ? So what if you have a bit of code that you are half way through and you want to comment it out as well as the imports. I've done this countless times over the years.
- nulltype 11y ago
  Yeah me too, and I can't recall that ever causing an issue with these comment directives.

marcus_holmes 11y ago

At last! I'm not insane! I raised this on the golang dev forums and got nowhere: https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOzqIqNPMJ https://groups.google.com/d/msg/golang-dev/r4rdPdsH1Fg/yjOOz... The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.

EugeneOZ 11y ago
I remember I reacted hysterically in Twitter about this change, somebody gave me link to your post and after reading first response of Brad Fitzpatrick I realized there's no chance for arguing or discussion - all decisions are final and community feedback isn't required.
- pfortuny 11y ago
  This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link). http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-editor.html http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...
  - marcus_holmes 11y ago
    I don't know what your reaction to that response was, whether you stuck with acme or not, but I'm now looking for another language to use instead of Go. I thought at first that this reaction was just sour grapes ("nasty people on the intertubes didn't like my post"), but as I analysed it more I managed to pull out three elements: 1. If my sense of elegance and the Go team's sense of elegance is this divergent, then the language will probably get uglier to my eyes as it continues to evolve. 2. If this is the reaction from the team to this (relatively small and inexpensive to fix) problem, then we can expect absolutely no movement at all on the bigger and harder problems (dependency versioning, generics). I used to have faith that these very smart people will come up with an elegant solution to these issues - I still love the simplicity and elegance of the standard library - but my faith has now gone. 3. Brad's response was amazing and I'd follow him anywhere, but... I don't want to follow the rest. If I'm to commit my time and effort to learning (and to a tiny extent popularising) the language and being part of the community, I want to believe in the people building it. I don't any more. Humans are weird.

jdkanani 11y ago

I couldn't agree more. It also makes code hard to read. I have to look closely to check if that's a comment or directive. It would be problem when your code grows. I am in favor of #TAG: DIRECTIVE or @TAG:DIRECTIVE

brandonbloom 11y ago

Comments are also not metadata! 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.

xyproto 11y ago
Agree. Something like decorators could have been used instead.
- _pmf_ 11y ago
  Go is typical "hurr durr, Java an C# are obsolete" write-only code by people who only ever work on ephemeral greenfield projects with a lifetime of 3 months and therefore can tell exactly what software development is all about.
  - fixxer 11y ago
    Such an inflammatory troll... Do you you even know who is involved in the Go project?

dvirsky 11y ago

This pattern predates Go 1.4, we've had it with CGO and build tags since at least 1.0 AFAIK. Even the Output in examples is pretty old I think. The only advantage in it is backwards compatibility with older Go versions, but in general I agree with you. When PHP did it for Python-style decorators everyone thought it was stupid. And while the build tags in Go are okay by me, doing it for CGO especially seems like a hack.

mappu 11y ago
AFAIK PHP doesn't provide python-style decorators and never executes code within comments. Can you cite that? Or are you maybe using a framework or library that's re-parsing your source files?
- EugeneOZ 11y ago
  PHP never execute comments, be sure. Some frameworks and tools like Doctrine use comments and reflections to prepend comments are annotations, and it's one of the reasons why these frameworks are slow as hell.
- dvirsky 11y ago
  Yeah you're right, my bad, I vaguely remembered it but it was a framework I was using, not the language itself. Still stupid anyway.

saintfiends 11y ago

Partially agreed. Directives should be visually distinct from comments and syntax should be formally defined such that compilers, code generators, editors and IDE's can use them consistently.

NateDad 11y ago
The compiler doesn't need to care about these directives. They don't have anything to do with the compiler. That's half the reason they're in comments. Otherwise you're just adding another kind of comment the compiler has to also ignore. The directives are pretty visually distinct. You could easily configure your editor to highlight them differently if you so chose.
- saintfiends 11y ago
  1. I don't understand what you mean by "They don't have anything to do with the compiler" https://golang.org/cmd/gc/#hdr-Compiler_Directives https://golang.org/cmd/gc/#hdr-Compiler_Directives 2. I could keep adding syntax support as they come along and handle all the inconsistencies, but that is not a solution. It's a hack.

breakingcups 11y ago

The problem with Go is that, while the language and compiler are excellent, Google doesn't a lot care about tooling & ecosystem. Why? They have their own in-house tooling (which is of course both highly specific to Google's use case and closed of for the public). 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.

teddyh 11y ago
I tried to argue this five months ago when Go 1.4 was released: https://news.ycombinator.com/item?id=8733705 https://news.ycombinator.com/item?id=8733705 I was severely downvoted and did not get many who agreed with me.
- deleted 11y ago
  [deleted]
Spiritus 11y ago

lohengramm 11y ago

I also do not agree with that. This is bad for so many reasons. First, to the compiler code, comments should be discarded as soon as possible (often in the lexer). To the programmers, comments should never execute anything (this is just intuitively expected). To any go source code reader (human or machine), comments are supposed to contain only human readable text, probably a context sensitive explanation of that particular section of code. To the separation of concerns, comments are comments and compiler directives are compiler directives. To each his own. This is probably the only decision I disagree with the Go team to date.

xyproto 11y ago
Fully agree. I love Go and use it for anything related to servers or the web, but doing anything with comments besides just letting them be comments, is just braindead.
- andrewchambers 11y ago
  They aren't used by the compiler at all.
  - ominous_prime 11y ago
    //#cgo //go:nosplit //go:noescpae are all used by the compiler in one way or another
    - andrewchambers 11y ago
      nosplit and noescape are internal details which are implementation specific.
      - ominous_prime 11y ago
        All of these are implementation specific. That's one reason they're in comments, and not listed in the language spec.

hartcw 11y ago

Although I don't use go (yet), I can see the benefit of this mechanism as I use a similar one for my own c/c++ code. There I use specially tagged comments to embed python in the c/c++ sources, and then run all the code through a python interpret stage to expand/execute the python code before compiling it. Actually it supports C macro style for the embedded code, which is a bit more sensible than misusing code comments. For example for generating a c/c++ enum: enum example_t { #py \ for line in open('values.txt'): \ print('EXAMPLE_' + line.strip() + ',') EXAMPLE_Max, EXAMPLE_Unknown }; Or alternatively to stuff it in a comment: enum example_t { /* py for line in open('values.txt'): print('EXAMPLE_' + line.strip() + ',') */ EXAMPLE_Max, EXAMPLE_Unknown }; If anyones interested, heres the python script I use to preprocess the c/c++ files https://github.com/hartcw/cppy https://github.com/hartcw/cppy

threeseed 11y ago
Sure the concept is definitely useful. But overloading comments seems monumentally dumb. They should have copied Java's annotation model which makes a lot more sense.
copsarebastards 11y ago
That's a valid thing to do in C++ because the language doesn't support alternatives. And you can't really expect it to, because C++ has tried various things over the years that make this much harder to add ex-post facto. However, it's worth noting that using such tooling in C++ can cause more problems than it solves if you aren't careful. This is just one of the ways C++ is showing its age. These problems are exactly why this is unacceptable in Go. Go has the benefit of learning from C++'s mistakes and seeing other attempts at solutions to the problem. Language designers have made these mistakes before, realized they were mistakes, and come up with better alternatives. This is just another example of the Go team either being unaware of or ignoring decades of development in programming languages.
myg204 11y ago
Interesting. Why don't you use an include file directive there? enum_example_t { #include "example_values.txt" EXAMPLE_Max, } where example_values would have the strings 'EXAMPLE_foo,'? Just wondering.

aablkn 11y ago

Oh don't forget the good old // +build !linux build constraints feature. It's been there since go 1.0 afaik.

erikb 11y ago

What does the word directive mean? Doing stuff by parsing comments is called a macro processor (or preprocessor, but it doesn't have to be done before the actual processing) or not? I think there are many instances where macro processors are a good thing. Some languages have them in the core. So what's the difference between macros and directives?

Merkur 11y ago
I would define a directive as an instruction to the tool chain. A macro processor could be one of those tools in the chain. There could be other (and Go implements other use cases!) I would also argue that a macro preprocessor do'snt need to "parse comments", it could parse any syntax the preprocessor wants to (and remove it from source befor the compiler sees it) In fact my point is, that parsing comments at all is a very bad idea. But my argument is NOT about, if Go needs a macro processor, or not. (i think it dont!) My argument is about the syntax of the directive. I argue about the syntax of declaring "Here comes something that is not Go Language!" I argue that this syntax should not be a comment - because a comment is part of the Go Language. (...among other reasons i stated in this discussion)
- erikb 11y ago
  Okay, now I get it. Thanks for clearing that up. I have to agree that adding features into comments instead of new language blocks or frameworks is smelly.
  - Merkur 11y ago
    thank you, for beeing open to be convinced :)

rjsw 11y ago

Lisp has used directives in comments in the past. Only on the first line of a file but they were parsed.

Grue3 11y ago
That had to be very distant past or some non-standard lisp. Common Lisp has no such feature.
- rjsw 11y ago
  It was done on Lisp Machines and currently in CCL.
- lispm 11y ago
  That's a feature of the Lisp IDE. File mode lines described language, the syntax (which Lisp dialect), the Package, the numeric base, the encoding, ... Example: ;;; -*- Mode: lisp; Syntax: ANSI-Common-Lisp; Package: http; Base: 10 -*- But to implement compiler directives in Common Lisp, this is not needed. That can already be done with macros and reader macros. If you for example use a macro in source code, the compiler will need to expand it. That allows arbitrary code execution during compilation.

egeozcan 11y ago

To this day, I still couldn't figure out why Go stays at the edge of being a great language, but lacks few very essential features for -to me- inexplicable reasons. Look at all the work done on JavaScript to generate code from macros and how incompatible the libraries became (JSX, sweet.js, TypeScript and so on). If there's no standardization, I'm afraid, go may have the same destiny. If anyone on the Go core team is reading this, I'd like you to consider adding proper macros to the language.

rudolf0 11y ago
A more conservative approach to macros would also just be... generics.

donatj 11y ago

I honestly even feel weird about godoc just being standard comments, in my mind docs and comments are different things, docs usually being noted with / * * (no spaces, but can't figure out how to escape) and comments being /* // or #

Dewie3 11y ago

If you're feeling paranoid and don't have time to look up the set of magical incantations, maybe you should write your actual comments like this: // COMMENT we have to check that [...] :)

Merkur 11y ago
Code should not be magical. Magic is bad engeneering. Magic involving a whitespace is madness.
- Dewie3 11y ago
  My intent was to poke fun at the current state of things. Not to give actual advice. :)

nicerobot 11y ago

Just because _you_ are locked into a mentality about a meaning for // does not mean we all are. Explain to me why formatted/structured text can not appear after a // in a file. If your editor parsed the text and formatted it to look meaningful, like code, would that help?

henesy 11y ago
I'm not sure why it bothers everyone so much. I might be missing something, but unless people are writing their comments in a very specific style then it shouldn't cause issues. From the help: "(note: no leading spaces and no space in "//go") where command is the generator to be run, corresponding to an executable file that can be run locally." It just seems like the code is distinctive enough it shouldn't cause problems. Or, if style should be adjusted, why not write your "not code" comments using the /* */ style?
- stefantalpalaru 11y ago
  What part of "all syntax should be validated" don't you understand? By putting that syntax in comments, syntax errors will not trigger any output from the tools because they remain valid free-form comments.
  - henesy 11y ago
    And they're not "Go" syntax. The syntax in the comments if for Go tools. A better approach may be to provide a more extensive syntax checking tool that parses comments and checks for syntax errors on a per-tool basis, but as I understand it it would seem that the implementation as it is now is aimed at the auxiliary Go tools, standardizing the syntax for the tools, thus allocating potential for future tools to expand without extensive maintenance on the core language itself. The tools are not the core language, but there should probably be some form of syntax checkers for the tools, but perhaps encapsulated within the tools. The comments are still comments to the actual Go code, as they are not pertinent to the language itself, but rather an outside entity such as a tool. It is also entirely possible that I am missing the point entirely and do not understand.

donlzx 11y ago

Comments are just comments, we should not keep adding keywords and syntax to them. Go's backward compatible promise is hurting itself. By sticking with strict compatibility mode, ad hoc solutions for fundamental issues are added from time to time. Sooner or later, those patch works will back-fire. For a language so young (version 1.0 in 2012), they should keep compatibility for stable release (1.x), but start adding language features in 2.x branches ASAP. Yes, compatibility promise may help selling the Go language at the beginning, but Go authors may seem a little too confident/optimistic of the language spec. in this case. If a 2.x branch is not coming out soon enough (in about two year), we will probably face the same dilemma as Python 2 vs 3.

Merkur 11y ago
One of the best features of go is "go fix" Yea! A migration tool for the language it self? Before they need to worry about compatibility they can break a lot of stuff.
- donlzx 11y ago
  Yeah I know, we can easily fix the codes with tools, we also have tools for conversion between Python 2 and 3, right? However, we can not easily fix the way people writing the code, or the so-called idiomatic Go norms. Actually, it is compatibility in the ecosystem of Go packages that matters. We have lots of good Go packages on Github that are no longer compatible with Go 1.0/1.1/1.2 etc.

cjslep 11y ago

Sad to see Go is fully going the way of Intel's Fortran compiler. It was more reasonable when (I think in cgo) you needed to export functions, which is done in Intel-compiled Fortran like so: !DEC$ ATTRIBUTES DLLEXPORT :: NameOfSubroutine Also at least Visual Studio will color those comments differently than normal comments.

bane 11y ago

As soon as you start using comments for something other than comments or documentation, you've basically admitted the language is broken and you end up becoming Java.

Ygg2 11y ago
Funny that you mention it, but Rust also checks all code in comments/documentation for validity, and runs test on your comments and catches if any of them fails to compile/return appropriate result.
- tomjakubowski 11y ago
  No it doesn't. Rustdoc examines the "doc" attribute on every item for Markdowk code blocks and checks those. The "doc" attribute can be attached to an item directly, using Rust's general attribute syntax, or using so-called "doc comments" which are visually and lexically distinct from ordinary comments. In the case of single line comments (the preferred style), doc comments have three slashes instead of two; a good IDE or editor mode for Rust will highlight doc comments differently than ordinary ones.
  - Ygg2 11y ago
    Right, but it's nearly identical to having instructions in comments, like Go does. And while the post I was implying seems to think this isn't a valid use case, I think it is.
oldmanjay 11y ago
I don't understand the conclusion. Java is certainly verbose and a fair bit aggressively ugly, but it has consistent syntax and I've never before heard anyone describe it as broken. care to amplify?
- bane 11y ago
  Well, not exactly comments, but Java's annotation system is an ugly kludge that should be part of the language and not an attempt at reintroducing C-style compiler directives. The abuse they suffer under various frameworks and ORMs is one of the ugliest things I've ever seen in a language. In almost every-case they either serve little to no purpose, or would be better-off just being part of the language syntax. But now you have to learn Java, and the Java-annotation meta-system. At least they aren't written in XML. note I actually don't mind the Java Community's habit of usingLongNames for things, and the actual language is pretty small and nice.

_yosefk 11y ago

One language where this is currently practiced is Verilog. To make things spicier, different vendors have different syntax for semantics-changing comments, often prefixed with the vendor's name. One "benefit" of this is that an older tool not updated to include the new syntax embedded in the comments will remain blissfully unaware of its ignorance, instead of spitting an error message. Another "benefit" is that a programmer unaware of the syntax might delete or copy & paste such comments when doing massive editing, without realizing that they aren't comments. To achieve the latter, it helps if the syntax looks like English or, better yet, if it looks like commented-out code (and, come to think of it, it's not unlikely that it will look like at least one of these things.)

yyhhsj0521 11y ago

In Python, following comment #--utf8-- indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.

mpdehaan2 11y ago
I was going to say it's the only one Python 2 has, AFAIK. So they've kept it reaosnable there, but then I remembered this: https://www.python.org/dev/peps/pep-0484/#id24 https://www.python.org/dev/peps/pep-0484/#id24 Which is pretty scary, IMHO. Python is productive, but I always questioned some of the choices in the language design (broken lambdas, etc -- though the implementation of list comprehensions were great so I just learned to love them) -- but it seems to take some of the same decisions Go is taking in terms of inconsistencies now. The Go stuff, however, seems much more worse. The phrase "nothing but Perl can parse Perl" comes to mind :)
- nchammas 11y ago
  The decision to put type annotations for variables in comments was made specifically for backwards compatibility reasons. Remember that Python has supported function annotations since 3.0 [0]. Python 3.5 will only add the option to type check those same annotations. Any type annotations that can be checked by Python 3.5 can also be parsed by earlier versions of Python, though without being checked. The only wart in this master plan is specifically the one where you want to type annotate variables (as opposed to functions). Comments are the only way they could do this in a backwards compatible way. The Python devs are well aware of the ugliness of this compromise, which is why they end the section you linked to with this: > If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version. I can't comment on Go, but I wouldn't call Python's choice here unreasonable. [0] https://www.python.org/dev/peps/pep-3107/ https://www.python.org/dev/peps/pep-3107/
- kbenson 11y ago
  Python's list comprehensions always struck me as an odd way to go given Python's tendency to choose clarity and simplicity over complexity and expressiveness. As a Perl user, Python list comprehensions make me go cross-eyed half the time. It's something Perl specifically decided to forego as too complex and prone to causing confusion, which is saying something.

amelius 11y ago

To be fair, it all started with #!/bin/sh

turrini 11y ago

//go:fancy seems more appropriate.

fixxer 11y ago

Meh. I hear your gripe, but I think your proposed solution is not that much of an improvement. You're also basing all of this on the idea that comments are "free form". Where is that gospel? I like the idea that comments are more than just blabber. I like the idea that, when structured some way, they take on new meanings. I think this is a semantic argument.

Merkur 11y ago
I too like the idea that comments are more than blabber. I do use comments like //BUG: //TODO: and //HOT: My argument is semantic? Yes it is! In my optinion thats the reason my argument is so strong. Please dont tell me you dont see a problem between //go: foor and //todo: bar - the first instructing some tool to change stuff in your build, the later merly mention that there is something left to do here. A directive like #todo: bar - is a great example for a great tool in the chain. the go tool could look for a "todo" command and this todo command could print out a warning that the code should not be released because XX todos arn't done. If the go tool would'nt find a "todo" command it could warn me that a tool in the chain is missing. I could evaluate in decide to use get this tool, or choose to ignore it. This would be imposible if comments are missused as directives!
- fixxer 11y ago
  Now argue against yourself and prove you understand why you hit resistance.
  - Merkur 11y ago
    if you can agree that i got arguments that convince - i do you the favor. :)
    - fixxer 11y ago
      I agree that you have raised an argument. I haven't read anything to indicate you understand the issue at a higher level. It would definitely help me respect your argument as sincere if you argued the counter with sophistication.

scott_s 11y ago

I don't know enough of the matter to have an informed view, but I think it's worth noting that there is precedent for this sort of thing. Take from one of my Python scripts: #!/usr/bin/env python http://en.wikipedia.org/wiki/Shebang_%28Unix%29 http://en.wikipedia.org/wiki/Shebang_%28Unix%29

bozoclownn 11y ago
I would add that this technically is a (ba)sh script, not a Python script.
- tangent128 11y ago
  On *nix systems, the #! is parsed by the kernel as a magic number. sh/bash are not involved.
  - bozoclownn 11y ago
    Thanks, didn't know!
- stefantalpalaru 11y ago
  No, you can use any program to launch executable scripts that start with #!. The kernel sees that magic number at the beginning of the file, tries to read a program path and arguments, adds the script as the last arg and executes the whole thing. The various shells are just a subset of the possible programs used.

copsarebastards 11y ago

What's the point of having a single-pass compiler if you have to add hacky precompilation steps to make up for its shortcomings? If you're passing over the code multiple times anyway then it defeats the purpose.

fredkbloggs 11y ago

The basic syntax of Go is C-like (this is not intended to be controversial), including that of comments. There is also a C syntax for communicating with the compiler: #pragma. There is no need for yet another syntax here. Just follow the example set by the language that has already heavily influenced the Go syntax. Note that C compilers already have the attributes people are demanding here: pragma directives are parsed, unknown pragmas generate errors or warnings, they are both visually and syntactically distinct from comments (intended for humans, not the toolchain), etc. Solved problem. There's no reason to invent new syntax here.

khanhussan 11y ago

:p -_- very nice

anacrolix 11y ago

I think the same can be said of the . selector on packages.