Live data from Hacker News

Go Lang: Comments Are Not Directives

news.ycombinator.com

11–20 of 222 posts

Re: Go Lang: Comments Are Not Directives

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

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.

Re: Go Lang: Comments Are Not Directives

#12
post #4
post #2

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

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

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

Re: Go Lang: Comments Are Not Directives

#13
post #4

Earlier quoted context omitted.

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

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

It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?

Re: Go Lang: Comments Are Not Directives

#14
post #8

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 (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 '…

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.

Re: Go Lang: Comments Are Not Directives

#15
post #9

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?

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

Re: Go Lang: Comments Are Not Directives

#16
post #6
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.

None, i just didn't know about //go: :)

Re: Go Lang: Comments Are Not Directives

#17
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/yjOOz...

The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here.

Re: Go Lang: Comments Are Not Directives

#19
post #9

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?

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.

Re: Go Lang: Comments Are Not Directives

#20
post #13

Earlier quoted context omitted.

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

It's an opensource project. Why don't you contribute a better solution? Or are you too lazy?

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.

Post reply on HN