Live data from Hacker News

Go Lang: Comments Are Not Directives

news.ycombinator.com

41–50 of 222 posts

Re: Go Lang: Comments Are Not Directives

#41

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.

Re: Go Lang: Comments Are Not Directives

#43
What does the word directive mean? Doing stuff by parsing comments is called a macro processor (or preprocessor, but it doesn't have to be done before the actual processing) or not? I think there are many instances where macro processors are a good thing. Some languages have them in the core. So what's the difference between macros and directives?

Re: Go Lang: Comments Are Not Directives

#44
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…

Sure the concept is definitely useful. But overloading comments seems monumentally dumb.

They should have copied Java's annotation model which makes a lot more sense.

Re: Go Lang: Comments Are Not Directives

#46
To this day, I still couldn't figure out why Go stays at the edge of being a great language, but lacks few very essential features for -to me- inexplicable reasons.

Look at all the work done on JavaScript to generate code from macros and how incompatible the libraries became (JSX, sweet.js, TypeScript and so on). If there's no standardization, I'm afraid, go may have the same destiny.

If anyone on the Go core team is reading this, I'd like you to consider adding proper macros to the language.

Re: Go Lang: Comments Are Not Directives

#47

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…

>Stuff like declaring a folder named "internal" special where it wasn't before.

Where can I read more about this?

Re: Go Lang: Comments Are Not Directives

#48
post #40
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?

PHP never execute comments, be sure. Some frameworks and tools like Doctrine use comments and reflections to prepend comments are annotations, and it's one of the reasons why these frameworks are slow as hell.

Re: Go Lang: Comments Are Not Directives

#49
post #37

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…

Agree. Something like decorators could have been used instead.

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.

Re: Go Lang: Comments Are Not Directives

#50

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.
Post reply on HN