4 ms·

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

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.

gwd 6y ago
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.
- masklinn 6y ago
  > 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 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.
  - xpressvideoz 6y ago
    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.
    - bojanz 6y ago
      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_draft_design/fywm1ap/ https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_d...
mytailorisrich 6y ago
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.
boris 6y ago
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.
- throwaway894345 6y ago
  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.
  - jzoch 6y ago
    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.
    - throwaway894345 6y ago
      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.
deleted 6y ago
[deleted]
Asooka 6y ago
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.
- yiyus 6y ago
  Besides the precious four bytes we would save for each pragma, what's the advantage of using "@" instead of "//go:"?
  - MaxBarraclough 6y ago
    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.
    - throwaway894345 6y ago
      These don’t seem like remotely significant issues, especially given how infrequent these directives are.
    - yencabulator 6y ago
      > 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.
      - breakingcups 6y ago
        Can you not see how that just amplifies the potential for confusion and bugs?

gwd 6y ago

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.

masklinn 6y ago
> 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 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.
- xpressvideoz 6y ago
  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.
  - bojanz 6y ago
    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_draft_design/fywm1ap/ https://www.reddit.com/r/golang/comments/hv96ny/qa_goembed_d...

mytailorisrich 6y ago

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.

boris 6y ago

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.

throwaway894345 6y ago
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.
- jzoch 6y ago
  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.
  - throwaway894345 6y ago
    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.

deleted 6y ago

[deleted]

Asooka 6y ago

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.

yiyus 6y ago
Besides the precious four bytes we would save for each pragma, what's the advantage of using "@" instead of "//go:"?
- MaxBarraclough 6y ago
  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.
  - throwaway894345 6y ago
    These don’t seem like remotely significant issues, especially given how infrequent these directives are.
  - yencabulator 6y ago
    > 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.
    - breakingcups 6y ago
      Can you not see how that just amplifies the potential for confusion and bugs?