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.
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.
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 and https://clojuredocs.org/clojure.repl/source
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.
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.
The statement was asinine. 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.
False dichotomy. The fact that a language is being used for big projects (or used at all) doesn't mean it has great design. Think of PHP...
I also completely fail to see what Docker's funding has to do with Go's design.
Docker is written in Go and $95m is more validation than you'll get in ten lifetimes.
Maybe it would have been easier or harder with another language? Who knows.
The valuation has everything to do with Docker's business model and nothing to do with the language they use to implement that vision.
At no point have I made a relative statement about Go being better than another language. The only claim I would ever make is that Go is well designed and effective for certain tasks, as demonstrated by use (validated by investment, which we can accept if we assume rational investors -- not going to debate that).
Now the claim that started this was that Go authors are greenfield celebrity programmers and they don't spend their time in the trenches (as indicated by certain parts of the language that some people - usually from "enterprise" languages - don't like; heavily and unapologetically paraphrased). That statement is asinine when you consider the background of the authors and the projects they've been involved in over their collectively lengthy careers.