Hacker News Reader

Comment by breakingcups | Hacker News Reader

Again, more magic comments.

The proposed feature is great, but the unwillingness of the Go team to use a separate, clearly defined project file or at the very least a separate syntax in your code file leads them to stuff every additional feature into comments, a space shared by human notetaking.

Let's have a look: * Build constraints (// +build linux) * Code generation (//go:generate <command> <arguments>) * Cgo, you can even stuff entire C programs in the comments (// #include <stdio.h>) * Cgo flags (// #cgo CFLAGS: -DPNG_DEBUG=1) * and now this, file embedding (//go:embed html/index.html)

Most novices would assume the commented out code does nothing, and rightly so in my opinion. Half of these features aren't even code-file specific but project-wide, making deciding which file to put them in hard and looking them up even harder.

View on HN

You forgot documentation (which actually annoys me more, because I can't put comments to developers of the function right before the function, because it will be interpreted as documentation to users of the function).

I mean yeah, I think the comment thing is a bit wonky, and it's not the way I'd do it. But once you've got "//go:generate", adding "//go:embed" isn't really any worse.

EDIT: Just noticed this line in the proposal:

> Another explicit goal is to avoid a language change. To us, embedding static assets seems like a tooling issue, not a language issue. Avoiding a language change also means we avoid the need to update the many tools that process Go code, among them goimports, gopls, and staticcheck.

So this partly explains the idea of putting things in comments: things classified as "tooling issues" are put there so that "language tools" aren't affected. I do agree it probably would have been better to invent a specific language construct for, "This is a tooling issue, please ignore"; a bit like the # prefix in C.

> But once you've got "//go:generate", adding "//go:embed" isn't really any worse.

There's way more than that: https://golang.org/src/cmd/compile/internal/gc/lex.go#L53

And I would argue that it's bull. Once they realised that they were introducing pragmas / attributes into the language, they should have bitten the bullet and actually introduced a clean way to annotate language items.

The first and second ones are excusable as "we'll only need one" and "well it's not worth the hassle" but at the third one it's not a special case it's a pattern. Especially as the excuse that "other implementations can ignore those" gets less and less true: a compiler which ignores go:embed can not be considered working.

Wow, the lexer function is even named "pragmaValue". So Go does have a concept of pragma, not just magic comments. Go developers' stubbornness on forward compatibility is beyond me.

To quote[1] Russ Cox: "C uses #pragma foo for this. Go simply spells #pragma as //go:."

https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_d...

This is essentially embedding bits and pieces of a makefile into source code as ad hoc comments. Which is what happens when you don't have a proper, general-purpose build system.

I’m sure this comment won’t be popular, but this is making a mountain out of a molehill. I particularly like Go’s build system—specifically that it isn’t some disaster that requires learning a one-off DSL (a la CMake, Gradle, Make, etc) just to enumerate dependencies. It’s clearly not perfect, but it’s always seemed pretty reasonable to use a general purpose build tool (like Bazel or Nix or Make) to call into the Go tool for more complicated builds.

The one off DSL exists. It’s worse because you may think it doesn’t but it does: it’s just in the comments. The fact that COMMENTS have side effects that affect how your code is built is so backwards I don’t get the justification.

The comment interface is minimal, easily understood, and affects only a small minority of projects because it is explicitly for advanced features. Contrast this with CMake, etc where you need to use the DSL for even single-source-file builds with zero dependencies. Then you have multi file builds which involve more complex DSL scripts, and then you have builds that need to pull dependencies which are more complex yet. This is all supported by the Go tool out of the box without any DSL whatsoever. Then you have things like linking to a C project which is just a comment in Go, but in DSL-based languages it’s even more scripting. This is all strictly better than having to deal with a DSL, especially from day 0.

Using comments (or “COMMENTS”) for these directives is sorta not ideal but if anyone could produce a case study where it causes anything but the most trivial of problems, I would be shocked. This seems like textbook overreaction.

This is subjective though, a makefile could also be considered minimal, but it's still a makefile

These should all just have been pragmas with their own syntax. I would even accept something as heretical as "@" for the pragma command, e.g.

  @build linux
  @generate <cmd> <args>
  @C #include <stdio.h>
  @cgo CFLAGS: -etc
  @embed path/to/file

Maybe these could even be come kind of code that you can write yourself and define your own pragmas and code transformations by passing some lib folder to the compiler with prebuilt compiler extensions... Ah well.

Besides the precious four bytes we would save for each pragma, what's the advantage of using "@" instead of "//go:"?

1. It doesn't look like a comment, so it's less confusing to people new to the language

2. It allows the programmer to skip comments entirely, when reasoning about program behaviour

3. You can write comments without fear of the comment changing program behaviour (probably of little concern in practice, but still)

Putting directives in comments is always a hack. C and C++ get this right, with #pragma.

These don’t seem like remotely significant issues, especially given how infrequent these directives are.

> 3. You can write comments without fear of the comment changing program behaviour (probably of little concern in practice, but still)

There's historical exceptions, but the new rule is this:

Comments begin with "// ", pragmas don't have that space.

Can you not see how that just amplifies the potential for confusion and bugs?

You also get no completion help from the language server since you are in a damn comment

That's another good point.

You get error messages if you get it wrong.

Spot the bug in the below:

    // +build windows
    package my_pkg

That's right, if you don't have a newline between the build comment and the package, it gets ignored as a package doc comment, not a build tag. So that comment is treated as a comment, but if there's a newline it isn't.

If we had a normal pragma, "go build" could error out instead, but we don't.

Similarly, if you typo

   //go:embd file

go build will ignore that as a comment. If it were '#embd', the tooling could error out with "unrecognized pragma".

I think that's the main argument for not using comments.

Imagine writing cgo like this:

    #pragma C {
    #include <stdio.h>
    
    int foo(var * bar) {
     ...
    }

Or having documentation look like this:

    // FIXME: This is kind of a hack, and we should
    // get rid of it before v1.0
    #pragma docs {
    The FooBar function will Foo all the Bars passed to it.
    }
    func FooBar(...) {

You could even imagine modifying your editor to do proper syntax highlighting on the C code.

Ah, well -- water under the bridge at this point. I like Go as a language overall. Most of their experiments have worked out pretty well, I think; it's inevitable that some of your experiments don't work out the way you expect, and then you're stuck with them.

I'm not sure about using this syntax for embedded file, but in general I see their point:

These annotations are not go code but specific to this go source file.

The latter means that embedding them in the go source file makes them easy to find and read =, and avoid multiplying configuration files.

From there the former (adding annotations in comments) is basically the simpler, and perhaps only, way to embed the annotations while make sure the file is still valid go code.

Reply on news.ycombinator.com