5 ms·

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 im

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?
    - ticviking 11y ago
      I think that's actually the point. At their level of prestige they can kinda work on whatever they like instead of having to live through and slog through the kind of crap code that accumulates on a project where you have people far below their level working along side people only slightly below their level. If you only ever work with fellow top performers, you never need the language and tool features that make it less to work with idiots. And then they do things like this comment stuff.
    - zak_mc_kracken 11y ago
      That's both an appeal to wrongful authority and irrelevant. You don't judge a software product by the credentials of who wrote it, you judge it by whether it's a good software product or not.
      - fixxer 11y ago
        No, it was a question. The statement was asinine. I'm legitimately curious if the comment owner knows who is part of the core team.
        _pmf_ 11y ago
        > I'm legitimately curious if the comment owner knows who is part of the core team. Yes, I know. And I know perfectly well that Go at its current immature state would never have gotten the kind of attention and consideration if it had not been designed by Mr. Pike. While I believe that many of the warts of Go are by design, some are obviously not.
        fixxer 11y ago
        Tell me then why Go is being used to drive so many big projects? Docker just raised another $95m for fucks sake. Why should I listen to you? What are your qualifications? Sell me on your position.
        11y ago
sunnyps 11y ago
Have you actually studied the go compiler implementation and found that comments are preserved across all stages or are you just speculating? I can imagine a design that works where only the lexer keeps track of comments (with locations) and the remaining stages do not. In fact using comments to generate code is not all that different from using comments to generate documentation (like doxygen) and that shouldn't require comments at the AST stage.
- brandonbloom 11y ago
  > Have you actually studied the go compiler implementation ... Yes. Though it's worth mentioning that they use the same AST infrastructure for `go format` and `go fix`. That means they need to track comments anyway. However, those use cases don't necessarily have the same requirements for accurately matching comments to semantically meaningful nodes. > using comments to generate documentation (like doxygen) 1) I don't really believe in javadoc or doxygen really. 2) Even if I did, I'd prefer actually (and similarly lightweight!) metadata notation. 3) Also consider runtime documentation support. eg: https://clojuredocs.org/clojure.repl/doc https://clojuredocs.org/clojure.repl/doc and https://clojuredocs.org/clojure.repl/source https://clojuredocs.org/clojure.repl/source

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?
  - ticviking 11y ago
    I think that's actually the point. At their level of prestige they can kinda work on whatever they like instead of having to live through and slog through the kind of crap code that accumulates on a project where you have people far below their level working along side people only slightly below their level. If you only ever work with fellow top performers, you never need the language and tool features that make it less to work with idiots. And then they do things like this comment stuff.
  - zak_mc_kracken 11y ago
    That's both an appeal to wrongful authority and irrelevant. You don't judge a software product by the credentials of who wrote it, you judge it by whether it's a good software product or not.
    - fixxer 11y ago
      No, it was a question. The statement was asinine. I'm legitimately curious if the comment owner knows who is part of the core team.
      - _pmf_ 11y ago
        > I'm legitimately curious if the comment owner knows who is part of the core team. Yes, I know. And I know perfectly well that Go at its current immature state would never have gotten the kind of attention and consideration if it had not been designed by Mr. Pike. While I believe that many of the warts of Go are by design, some are obviously not.
        fixxer 11y ago
        Tell me then why Go is being used to drive so many big projects? Docker just raised another $95m for fucks sake. Why should I listen to you? What are your qualifications? Sell me on your position.
        11y ago

sunnyps 11y ago

Have you actually studied the go compiler implementation and found that comments are preserved across all stages or are you just speculating? I can imagine a design that works where only the lexer keeps track of comments (with locations) and the remaining stages do not. In fact using comments to generate code is not all that different from using comments to generate documentation (like doxygen) and that shouldn't require comments at the AST stage.

brandonbloom 11y ago
> Have you actually studied the go compiler implementation ... Yes. Though it's worth mentioning that they use the same AST infrastructure for `go format` and `go fix`. That means they need to track comments anyway. However, those use cases don't necessarily have the same requirements for accurately matching comments to semantically meaningful nodes. > using comments to generate documentation (like doxygen) 1) I don't really believe in javadoc or doxygen really. 2) Even if I did, I'd prefer actually (and similarly lightweight!) metadata notation. 3) Also consider runtime documentation support. eg: https://clojuredocs.org/clojure.repl/doc https://clojuredocs.org/clojure.repl/doc and https://clojuredocs.org/clojure.repl/source https://clojuredocs.org/clojure.repl/source