Hacker News new | comments | show | ask | jobs | submit login

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.

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.

> 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 and https://clojuredocs.org/clojure.repl/source

Agree. Something like decorators could have been used instead.

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.

Such an inflammatory troll... Do you you even know who is involved in the Go project?

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.

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.

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.

> 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.

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.

> Tell me then why Go is being used to drive so many big projects?

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.

Good design = it gets shit done. I don't care for PHP syntax, but it gets shit done. Any definition of good design beyond that simple metric is pure masturbation.

Docker is written in Go and $95m is more validation than you'll get in ten lifetimes.

Again, that says absolutely nothing about the quality of Go compared to other languages. You can write programs that work in Go, big deal.

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.

So you think that the ability to execute a large project successfully implies nothing about the quality of the tools used to implement the project? I disagree.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact