Live data from Hacker News

Go Lang: Comments Are Not Directives

news.ycombinator.com

151–160 of 222 posts

Re: Go Lang: Comments Are Not Directives

#151

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

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.

Re: Go Lang: Comments Are Not Directives

#152
post #32
post #14

Earlier quoted context omitted.

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

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

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

Re: Go Lang: Comments Are Not Directives

#154
post #96
post #49

Earlier quoted context omitted.

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?

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.

Re: Go Lang: Comments Are Not Directives

#155
post #70

Earlier quoted context omitted.

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

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 without extensive maintenance on the core language itself. The tools are not the core language, but there should probably be some form of syntax checkers for the tools, but perhaps encapsulated within the tools. The comments are still comments to the actual Go code, as they are not pertinent to the language itself, but rather an outside entity such as a tool. It is also entirely possible that I am missing the point entirely and do not understand.

Re: Go Lang: Comments Are Not Directives

#156
The basic syntax of Go is C-like (this is not intended to be controversial), including that of comments. There is also a C syntax for communicating with the compiler: #pragma. There is no need for yet another syntax here. Just follow the example set by the language that has already heavily influenced the Go syntax.

Note that C compilers already have the attributes people are demanding here: pragma directives are parsed, unknown pragmas generate errors or warnings, they are both visually and syntactically distinct from comments (intended for humans, not the toolchain), etc.

Solved problem. There's no reason to invent new syntax here.

Re: Go Lang: Comments Are Not Directives

#157
post #148

Earlier quoted context omitted.

well, i see - my statement was flawed. :)

You stand corrected then :) (or not). Does this comment thing make you want to flee to the safety of Java? I would put up with Java semantics if I were fulfilling a community service sentence.

Actually it would remind me on C. It did not even support a redundant comment token, and of course they did not used a comment to mark directives.

go troll your self. I am always open to argue, but you have no leverage to be snarky.

Re: Go Lang: Comments Are Not Directives

#158

In Python, following comment #- -utf8- - indicated the encoding of a source file. In most cases, this won't induce ambiguity, though it's potentially dangerous.

I was going to say it's the only one Python 2 has, AFAIK. So they've kept it reaosnable there, but then I remembered this: https://www.python.org/dev/peps/pep-0484/#id24 Which is pretty scary, IMHO. Python is productive, but I always questioned some of the choices in the language design (broken lambdas, etc -- though the implementation of list comprehensions were great so I just learned to love them) -- but it seems…

Python's list comprehensions always struck me as an odd way to go given Python's tendency to choose clarity and simplicity over complexity and expressiveness. As a Perl user, Python list comprehensions make me go cross-eyed half the time. It's something Perl specifically decided to forego as too complex and prone to causing confusion, which is saying something.

Re: Go Lang: Comments Are Not Directives

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

> 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 provided stuff in Golang, you have to bring your own safety.

Re: Go Lang: Comments Are Not Directives

#160
post #33

Earlier quoted context omitted.

Most interesting response from Russ Cox: "Where you see a hack I see an elegant design." Elegant design...

They say that beauty is in the eye of the beholder. meh.

Beauty is in the eye of the beer-holder.
Post reply on HN