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

201–210 of 222 posts

Re: Go Lang: Comments Are Not Directives

#201

Post by marcus_holmes »

pfortuny wrote: post #140
EugeneOZ wrote: post #29

Earlier quoted context omitted.

I remember I reacted hysterically in Twitter about this change, somebody gave me link to your post and after reading first response of Brad Fitzpatrick I realized there's no chance for arguing or discussion - all decisions are final and community feedback isn't required.

This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link). http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...

I don't know what your reaction to that response was, whether you stuck with acme or not, but I'm now looking for another language to use instead of Go.

I thought at first that this reaction was just sour grapes ("nasty people on the intertubes didn't like my post"), but as I analysed it more I managed to pull out three elements:

1. If my sense of elegance and the Go team's sense of elegance is this divergent, then the language will probably get uglier to my eyes as it continues to evolve.

2. If this is the reaction from the team to this (relatively small and inexpensive to fix) problem, then we can expect absolutely no movement at all on the bigger and harder problems (dependency versioning, generics). I used to have faith that these very smart people will come up with an elegant solution to these issues - I still love the simplicity and elegance of the standard library - but my faith has now gone.

3. Brad's response was amazing and I'd follow him anywhere, but... I don't want to follow the rest. If I'm to commit my time and effort to learning (and to a tiny extent popularising) the language and being part of the community, I want to believe in the people building it. I don't any more.

Humans are weird.

Re: Go Lang: Comments Are Not Directives

#202

Post by brandonbloom »

sunnyps wrote: post #151
brandonbloom wrote: post #21

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

> 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

Re: Go Lang: Comments Are Not Directives

#203

Post by pfortuny »

marcus_holmes wrote: post #201
pfortuny wrote: post #140

Earlier quoted context omitted.

This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link). http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...

I don't know what your reaction to that response was, whether you stuck with acme or not, but I'm now looking for another language to use instead of Go. I thought at first that this reaction was just sour grapes ("nasty people on the intertubes didn't like my post"), but as I analysed it more I managed to pull out three elements: 1. If my sense of elegance and the Go team's sense of elegance is this divergent, then t…

Never used Acme. The answer always seemed to me weird, like "we are right, we do not care about this."

Just say no is a good slogan for "bad" things but pretending that syntax highlighting is "bad" is senseless.

Re: Go Lang: Comments Are Not Directives

#204

Post by okal »

andrewchambers wrote: post #185
nevergo wrote: post #112

Earlier quoted context omitted.

Go has the poorest std lib I've ever seen.

Compared with? My reference point is python,java,clojure,c,c++. Python is huge and useful but messy and inconsistent. Java is huge and doesn't compose well. Clojure is underdocmented and hardly batteries included. C and C++ can't do anything useful without a bunch of extra libraries. From what I can see, C# is like java in this regard. Go is a small incredibly useful and composable set of libraries that handles a vas…

I had the same feeling about Clojure, but it mostly has to do with non-standard libs. It's forced me to rely on reading source code a lot more than I did in other languages, so I'm not entirely sure that's a mark against it. I'm curious why you think that about Python, though. Care to illustrate?

Re: Go Lang: Comments Are Not Directives

#205

Post by _pmf_ »

fixxer wrote: post #178
zak_mc_kracken wrote: post #154

Earlier quoted context omitted.

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.

Re: Go Lang: Comments Are Not Directives

#206

Post by anon3_ »

TheDong wrote: 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 '…

https://golang.org/doc/faq#Why_doesnt_Go_have_feature_X

"Every language contains novel features and omits someone's favorite feature. Go was designed with an eye on felicity of programming, speed of compilation, orthogonality of concepts, and the need to support features such as concurrency and garbage collection. Your favorite feature may be missing because it doesn't fit, because it affects compilation speed or clarity of design, or because it would make the fundamental system model too difficult.

If it bothers you that Go is missing feature X, please forgive us and investigate the features that Go does have. You might find that they compensate in interesting ways for the lack of X."

Re: Go Lang: Comments Are Not Directives

#207

Post by Ygg2 »

tomjakubowski wrote: post #183
Ygg2 wrote: post #102

Earlier quoted context omitted.

Funny that you mention it, but Rust also checks all code in comments/documentation for validity, and runs test on your comments and catches if any of them fails to compile/return appropriate result.

No it doesn't. Rustdoc examines the "doc" attribute on every item for Markdowk code blocks and checks those. The "doc" attribute can be attached to an item directly, using Rust's general attribute syntax, or using so-called "doc comments" which are visually and lexically distinct from ordinary comments. In the case of single line comments (the preferred style), doc comments have three slashes instead of two; a good I…

Right, but it's nearly identical to having instructions in comments, like Go does. And while the post I was implying seems to think this isn't a valid use case, I think it is.

Re: Go Lang: Comments Are Not Directives

#209

Post by EugeneOZ »

marcus_holmes wrote: post #201
pfortuny wrote: post #140

Earlier quoted context omitted.

This reminds me of Plan9 "Just say no" on the Acme editor (see number 6 in the link). http://fixunix.com/plan9/523380-%5B9fans%5D-using-acme-edito...

I don't know what your reaction to that response was, whether you stuck with acme or not, but I'm now looking for another language to use instead of Go. I thought at first that this reaction was just sour grapes ("nasty people on the intertubes didn't like my post"), but as I analysed it more I managed to pull out three elements: 1. If my sense of elegance and the Go team's sense of elegance is this divergent, then t…

Agree with 1 and 2. And to clarify my comment: Brad's response is very detailed and I have nothing against it, I just see even Brad can't change things so these things will not be changed by community. I really respect Brad as a programmer.

Re: Go Lang: Comments Are Not Directives

#210

Post by myg204 »

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…

Interesting. Why don't you use an include file directive there?

    enum_example_t
    {
        #include "example_values.txt"
        EXAMPLE_Max,
    }
where example_values would have the strings 'EXAMPLE_foo,'? Just wondering.
Post reply on HN