Go Lang: Comments Are Not Directives

That's absolutely a mischaracterisation, and a hurtful one at that because we absolutely care about our developer experience.

"go generate" is a mechanism for invoking code generation tools; tools that people were already using in a variety of ad hoc ways. That's all. Macros are another thing entirely.

Our conservatism should be a testament to how much we care about quality. We don't want to do anything by half measures, as that serves no one's interests.

For an example of what this looks like in actual use, see the very popular go-sqlite3 library: https://github.com/mattn/go-sqlite3/blob/dee1a37fe11067e9797...

I personally think that large block-comments of code that actually do something, but only if above a certain import really strange and unexpected; it means re-ordering imports can break things, changing around spacing can break things, and tons of other things.

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.

    //line path/to/file:linenumber

    //go:noescape

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

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.

Interesting contrast to the philosophy of Perl 6: 'torture the implementor on behalf of the user'.

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

[0] https://news.ycombinator.com/item?id=9523187

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.

Elegant design...

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 appeal to authority with regards to the Go designers/developers - basically that they have a long track record of making great/influential software. And though appealing to authority certainly isn't without merit, I think it was taken a bit far, namely that it was used as an argument to try to end all discussion. And secondly the things that they are famous for does not seem to be related to PL/design.

That's a rather disingenuous summary given that literally the very first response is Brad Fitzpatrick from the Go team agreeing with you, acknowledging that it's unfortunate, and admitting that it can't feasibly be changed yet due to the compatibility guarantees. And then shortly afterwards, he encourages you to bring this point up when Go 2 comes around.

If I had a huge amount invested in Go I would consider forking it - it is one thing to have a benevolent dictator, but if he doesn't at least listen then there is no point at all.

> But I disagree that putting commands in comments at all is a good idea. Just because other languages do it doesn't make it a good idea. It's clearly a hack to get around some historical problem, and we're better than that.

A member of the Go team says:

> Where you see a hack I see an elegant design.

It's never been an elegant design, at best, it was an acceptable design in the 90s.

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.

The directives are pretty visually distinct. You could easily configure your editor to highlight them differently if you so chose.

https://news.ycombinator.com/item?id=8733705

I was severely downvoted and did not get many who agreed with me.

Where can I read more about this?

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

* Automated refactoring that is editor agnostic? check.

* Editor agnostic built in documentation tool/server? check.

* Editor agnostic Code analyzers/oracles? check.

Go's core dev team is many things but saying they don't care about tooling and ecosystem is a gross misrepresentation. They may not care about your specific IDE or preferred language design but they most definitely care about making tooling available to everyone regardless of IDE/editor choice.

I'd say you got this exactly backwards. The language is mediocre, but the tooling and ecosystem are great.

The `go` command in particular is something I really want in other languages: no messing around with build files or monsters like `cabal`.

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

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.

    enum_example_t
    {
        #include "example_values.txt"
        EXAMPLE_Max,
    } 

Something like PY_CODE(<blah>), for instance. That way it won't compile unless you run it through the preprocessor.

A macro processor could be one of those tools in the chain. There could be other (and Go implements other use cases!)

I would also argue that a macro preprocessor do'snt need to "parse comments", it could parse any syntax the preprocessor wants to (and remove it from source befor the compiler sees it) In fact my point is, that parsing comments at all is a very bad idea.

But my argument is NOT about, if Go needs a macro processor, or not. (i think it dont!) My argument is about the syntax of the directive.

I argue about the syntax of declaring "Here comes something that is not Go Language!" I argue that this syntax should not be a comment - because a comment is part of the Go Language. (...among other reasons i stated in this discussion)

IF has a meaning - and it always have this meaning. FUNC has a meaning - always the same. // are comments. The meaning of comments is to communicate with humans.

We know the principal of "overloading" syntax. Things can have a different meaning in a different context. One could argue using //go: is overloading the comment. BUT: Go is not a language that do's overloading - in fact its philosophy is against overloading, as it is against generics. (and I realy like this philosophy!)

I argue that directives to the tool chain should not apear in a comment - because a directive to the tool chain has a different & incompatible meaning than a comment.

I argue future: There is a need for directives to the tool chain in the Go source code. The go-team has this need, and there can be great things done with such e mechanism. The go community will do great things with directives! I see tons of use cases for godep. I see tons of use cases for debuggers, profilers and all kinds of other tools.

The go-team not only implements go, they also set an example to the usage of the language. If they misuse comments to express directives, other projects will eventualy follow.

But what will happens in the long run if we embrace that example and use //foo: bar as directives for our tool chains?

The go tool chain could not generate meaningfull errors about missing tools, or syntax errors in directives. Also: Comments would not be safe to communicate with fellow programmers - who knows that kind of tools where used in my dependencies? And what kinds of //foo: should be marked pink in my editor? All of em?

All this could be solved by using an other syntax for directives. I do not care if its # or @ or #! or whatever - as long as it is not a comment.

I also have no argument about macros, generics or whatever. I just want go to be unambiguous.

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 to take some of the same decisions Go is taking in terms of inconsistencies now.

The Go stuff, however, seems much more worse.

The phrase "nothing but Perl can parse Perl" comes to mind :)