Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Lang: Comments Are Not Directives

news.ycombinator.com

Post reply on HN
Print view View original

161–170 of 222 posts

Re: Go Lang: Comments Are Not Directives

#161

Post by JadeNB »

castell wrote: post #62
Merkur wrote: post #28

Earlier quoted context omitted.

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.

Maybe I have missed the point, but your post sounds like you think Merkur disagrees. I think that you are actually agreeing with the GP (https://news.ycombinator.com/item?id=9523335), which says that:

> I think this was a bad decision. I think you would agree as soon [as] a tool ... uses

    > //todo: bar
(i.e., that the `//todo:` syntax would unambiguously demonstrate the bad-ness of the decision).

Re: Go Lang: Comments Are Not Directives

#162

Post by stefantalpalaru »

henesy wrote: post #155
stefantalpalaru wrote: post #130

Earlier quoted context omitted.

What part of "all syntax should be validated" don't you understand? By putting that syntax in comments, syntax errors will not trigger any output from the tools because they remain valid free-form comments.

And they're not "Go" syntax. The syntax in the comments if for Go tools. A better approach may be to provide a more extensive syntax checking tool that parses comments and checks for syntax errors on a per-tool basis, but as I understand it it would seem that the implementation as it is now is aimed at the auxiliary Go tools, standardizing the syntax for the tools, thus allocating potential for future tools to expand…

It's irrelevant which tool does the checking. The problem is that you don't know whether "// go:generate foo", "//ho:generate bar" or "//go;generate baz" are errors or simply comments.

In order to detect most of that you'll have to redefine the comment syntax for the core language so it's no longer free-form but anything that looks like a comment-directive now triggers a warning (or most likely an error seeing the Go philosophy).

Re: Go Lang: Comments Are Not Directives

#163

Post by nulltype »

threeseed wrote: post #19
nulltype wrote: 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.

Yeah me too, and I can't recall that ever causing an issue with these comment directives.

Re: Go Lang: Comments Are Not Directives

#164

Post by nulltype »

masklinn wrote: post #15
nulltype wrote: 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

I think they should fix that bug where it's not actually looking at the comments. However, with the exception of that bug, I don't think I have ever made a comment that started with "//go:" and was not a directive. It seems kind of hard to make one of those by accident.

Re: Go Lang: Comments Are Not Directives

#165

Post by geoka9 »

Dewie3 wrote: post #54
marcus_holmes wrote: post #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.

> The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here. I don't see why that's so hard to imagine. Just because someone is skilled/bright in some area doesn't mean that they are skilled/have good taste in another area. Even if those areas are very similar from a high-level view, like both involving programming. There has been a lot of a…

Actually it does. C was shaped to a large degree by feedback from the original Unix programmers, including Ken Thompson and Rob Pike.

Re: Go Lang: Comments Are Not Directives

#166

Post by copsarebastards »

NateDad wrote: post #51
zak_mc_kracken wrote: post #12

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.

Fixing the lack of generics is not the intent of supporting a standard way to do code generation. The intent is to allow for things like generating code from protobuf specs and yacc. In fact, there was even debate against adding go:generate because they were afraid people would use it to get something like generics. To say it is for generics is to grossly mischaracterize the feature.

Given that this is the only way Go provides to gain access to generic-like behavior, you shouldn't be surprised when people use it that way, and the intent of the team is quite irrelevant.

Re: Go Lang: Comments Are Not Directives

#167

Post by copsarebastards »

hartcw wrote: post #38

Although I don't use go (yet), I can see the benefit of this mechanism as I use a similar one for my own c/c++ code. There I use specially tagged comments to embed python in the c/c++ sources, and then run all the code through a python interpret stage to expand/execute the python code before compiling it. Actually it supports C macro style for the embedded code, which is a bit more sensible than misusing code comment…

That's a valid thing to do in C++ because the language doesn't support alternatives. And you can't really expect it to, because C++ has tried various things over the years that make this much harder to add ex-post facto. However, it's worth noting that using such tooling in C++ can cause more problems than it solves if you aren't careful. This is just one of the ways C++ is showing its age.

These problems are exactly why this is unacceptable in Go. Go has the benefit of learning from C++'s mistakes and seeing other attempts at solutions to the problem. Language designers have made these mistakes before, realized they were mistakes, and come up with better alternatives. This is just another example of the Go team either being unaware of or ignoring decades of development in programming languages.

Re: Go Lang: Comments Are Not Directives

#168

Post by sounds »

coldtea wrote: post #159
curun1r wrote: post #152

Earlier quoted context omitted.

> Can you think of some aspect that was especially well thought-out? Go routines, channels and select. With very little else, it's possible to write some very useful code in a way that's concise, elegant and easy to reason about.

Only compared to something like C or explicit old-skool Java like threading. A lot of modern languages have CSP built-in or as a lib (Java, Scala, Haskell, Clojure, C++, Ada, Erlang, heck even Rust). And Go is not quite expressive to address higher level, but common, constructs ( https://gist.github.com/kachayev/21e7fe149bc5ae0bd878 ) in a conceise and elegant way. And if you access anything outside of channel provid…

It looks like from the comments on your gist, there are ways to do it. Whether it's expressive enough is subjective but it's worth pointing out that there _are_ solutions.

Re: Go Lang: Comments Are Not Directives

#169

Post by zaphar »

tomjen3 wrote: post #121
zaphar wrote: post #103

Earlier quoted context omitted.

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 is the most bizarre criticism of go I have ever heard. Go has the best tooling of any language I have ever used bar none. A cursory look at: https://go…

Eclipse has had those things for years for Java. Yeah that is not editor agnostic but when you sit down and learn a platform learning an IDE isn't a big deal. Speaking of which I do not see any official recommendation of an IDE for Go.

For the record I don't think you deserve to be downvoted like this. You stated a valid opinion. Go is not meeting a need you have and thus the value proposition for you is not the same as mine. This appears to be a case of people downvoting because they disagree not due to the quality of your comment.

Re: Go Lang: Comments Are Not Directives

#170

Post by Dewie3 »

geoka9 wrote: post #165
Dewie3 wrote: post #54

Earlier quoted context omitted.

> The response was basically "we disagree" and I wandered away feeling confused that so many bright people couldn't see the problem here. I don't see why that's so hard to imagine. Just because someone is skilled/bright in some area doesn't mean that they are skilled/have good taste in another area. Even if those areas are very similar from a high-level view, like both involving programming. There has been a lot of a…

Actually it does. C was shaped to a large degree by feedback from the original Unix programmers, including Ken Thompson and Rob Pike.

Rob Pike? I thought that C came into its shape before his time.
Post reply on HN