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.
