Go Lang: Comments Are Not Directives • Hacker News Board

Re: Go Lang: Comments Are Not Directives

#61

Post by castell » Mon, May 11, 2015, 11:10 AM UTC

NateDad wrote: post #50

breakingcups wrote: post #27

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…

They did a lot of research on the "internal" folder name and after downloading every github repo that contained go code, they found only a handful of repos that used a folder called internal. Don't think they went into that blind and just assumed no one used the name.

Many "internal" code bases don't reside on GitHub or are marked as "private". I do like Go lang, but some of their decisions are weird.

Re: Go Lang: Comments Are Not Directives

#62

Post by castell » Mon, May 11, 2015, 11:14 AM UTC

Merkur wrote: post #28

enneff wrote: post #3

(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/commen...

I think this was a bad decision. I think you would agree as soon a tool emerges that follows your example and uses //todo: bar to do stuff with the code, and makes the program fail because it's not done, because you don't know about it. with a #todo: bar the go tool chain would catch this error

If the add "//Todo:" as syntax, many projects would be screwed. Abusing comments for anything else is not good.

Re: Go Lang: Comments Are Not Directives

#63

Post by nicerobot » Mon, May 11, 2015, 11:14 AM UTC

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?

Re: Go Lang: Comments Are Not Directives

#64

Post by Grue3 » Mon, May 11, 2015, 11:19 AM UTC

rjsw wrote: post #45

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

That had to be very distant past or some non-standard lisp. Common Lisp has no such feature.

Re: Go Lang: Comments Are Not Directives

#65

Post by coldtea » Mon, May 11, 2015, 11:19 AM UTC

andrewchambers wrote: post #58

coldtea wrote: post #32

Earlier quoted context omitted.

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

Go has the best and most consistent std library I have seen.

It's quite good, but e.g. Java SDK has stuff that runs circles around Go's standard library regarding breadth and maturity, especially stuff added since 1.4 (nio, etc).

And some aspects of the Go SKD are horrible in practical use. Case in point, most things math related.

Re: Go Lang: Comments Are Not Directives

#66

Post by [deleted] » Mon, May 11, 2015, 11:33 AM UTC

teddyh wrote: post #41

breakingcups wrote: post #27

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…

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

[deleted]

Re: Go Lang: Comments Are Not Directives

#67

Post by dvirsky » Mon, May 11, 2015, 11:34 AM UTC

mappu wrote: post #40

dvirsky wrote: post #22

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 hac…

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?

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.

Re: Go Lang: Comments Are Not Directives

#68

Post by anatoly » Mon, May 11, 2015, 11:38 AM UTC

enneff wrote: post #6

bsaul wrote: post #5

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.

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.

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?

Re: Go Lang: Comments Are Not Directives

#69

Post by donlzx » Mon, May 11, 2015, 11:43 AM UTC

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.

Re: Go Lang: Comments Are Not Directives

#70

Post by henesy » Mon, May 11, 2015, 11:46 AM UTC

nicerobot wrote: post #63

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?

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?