Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

//go:fix inline and the source-level inliner

go.dev

Post reply on HN
Print view View original

61–70 of 81 posts

Re: //go:fix inline and the source-level inliner

#61

Post by pjmlp »

freakynit wrote: post #48

Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?

This is typical Go design, other languages do it worse, it isn't really needed, and then it gets added half way as it was supposed to be if done early on, and everyone cheers how Go is a "simple" language.

Just like some other famous languages of the authors.

Re: //go:fix inline and the source-level inliner

#62

Post by debugnik »

thwarted wrote: post #17
Mond_ wrote: post #12

Earlier quoted context omitted.

This is begging the question. Yes, but why did they do that over dedicated syntax? (My personal theory is that early go had a somewhat misguided idea of simplicity, and preferred overloading existing concepts with special cases over introducing new keywords. Capitalization for visibility is another example of that.)

//go:xyz is dedicated syntax that is compatible with both the language spec and other toolchains that don't know about it.

Good luck compiling on a toolchain that doesn't know about //go:embed or /* */import "C" comments.

Re: //go:fix inline and the source-level inliner

#63

Post by 9rx »

freakynit wrote: post #60
9rx wrote: post #59

Earlier quoted context omitted.

You are right that there could be new syntax, like, say, `@tool:name args` or `#tool.name args`, but is that any different than `//tool:name args`? They all read the same to me. The upside of that particular syntax is that only the parser used by tools needs to understand directives. All other parser implementations can be blissfully unaware, negating the need for special no-ops. The downside is...?

I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. But we don't do that, because intuitively we know that's not the right place for it. The issue isn't that this approach is incorrect, it's that it feels out of place. A comment should be a comment, nothing more. When comments start carrying executable meaning or structured directives, they stop ser…

> I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully.

It sounds like you are talking about cgo. I think you have a stronger case there, but it is much the same situation: It's conceptually a third-party add-on that the Go language doesn't know anything about. "Cgo is not Go"[1]

I mean, if you really did have your own business logic language that you needed to include in Go code, where else would you put it if not in the "comments"? You, a random third-party, won't be able to add syntax to Go, so you cannot reasonably consider that to be an option. What syntax could Go add that is flexible enough to allow anyone to add anything they need, but that doesn't end up being comments by another token?

> A comment should be a comment, nothing more.

It's not really a comment, though. It is a directive. A comment is structured like `// Who the hell wrote this crap?`, while this is structured like `//tool:name args`.

I think what you are saying is that you don't like overloaded syntax, which is fair, but Go overloads syntax in several places so this is not a unique case. Besides, most languages end up with overloaded syntax in practice, so it isn't even something unique to Go.

To be clear, this isn't a feature of Go. There is nothing in the spec about it. It is what outside tools have hacked on top of Go because it doesn't offer that infinitely flexible feature mentioned above. However, it remains to be seen how you add infinitely flexible syntax without it turning into just being comments again.

[1] https://go-proverbs.github.io

Re: //go:fix inline and the source-level inliner

#64

Post by debugnik »

overfeed wrote: post #58
Mond_ wrote: post #46

Earlier quoted context omitted.

Well, I've been unable to follow you as well, then. Obviously if they'd used a different type of syntax (e.g. using # for annotations), those would also be compatible with the language spec, and other implementations would still be just as capable of ignoring all unknown annotations. (Though for the record, talking about alternative implementations when discussing Go is kind of a funny joke.)

Is gccgo a joke to you?

Maybe? It's stuck at 1.18 without generics and no one has replaced its maintainer, Ian Lance Taylor, who seems to have moved on after leaving Google.

But to be fair to alternative toolchains, TinyGo and TamaGo are also a thing.

Re: //go:fix inline and the source-level inliner

#65

Post by 9rx »

ternaryoperator wrote: post #31
tptacek wrote: post #22

Earlier quoted context omitted.

There's nothing unique to Go about this kind of tooling. It exists in C, Java, Rust, Typescript, and probably dozens of other settings as well. It's the standard way of implementing "after-market" opt-in directives.

It does not exist in Java. Comments in Java do not change code.

It doesn't exist in Go either. https://go.dev/ref/spec

That's why you find it in the comments. That is where tools have found a place to add their own syntax without breaking the Go code.

Absolutely you can do the same in Java. It exists to the exact same degree as it does in Go. I expect it isn't done as often in the Java world because it is much harder to parse Java code so the tools don't get built.

Re: //go:fix inline and the source-level inliner

#66

Post by usrnm »

bheadmaster wrote: post #13
kjksf wrote: post #11

Earlier quoted context omitted.

Go designers distinguish between Go language as defined by Go spec and implementation details. //go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language. If they made it part of the syntax, that would require other implementations to implement it.

That's such an elegant solution. I keep being impressed at subtle but meaningful things that Go does right.

It only seems right because there are no other implementations and the distinction is meaningless. You don't want to live in the world of multiple slightly different implementations all of which you need to support, this is, roughly, what the C++ build story looks like, and it's not fun.

Re: //go:fix inline and the source-level inliner

#67

Post by freakynit »

9rx wrote: post #63
freakynit wrote: post #60

Earlier quoted context omitted.

I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. But we don't do that, because intuitively we know that's not the right place for it. The issue isn't that this approach is incorrect, it's that it feels out of place. A comment should be a comment, nothing more. When comments start carrying executable meaning or structured directives, they stop ser…

> I mean, technically you could write your entire business logic inside comments and have some tool parse it successfully. It sounds like you are talking about cgo. I think you have a stronger case there, but it is much the same situation: It's conceptually a third-party add-on that the Go language doesn't know anything about. "Cgo is not Go"[1] I mean, if you really did have your own business logic language that you…

I think your latest comment clarifies a lot of things for me here... primary being that it's something language designer did not wanted... just that tool developers went ahead with because there wasn't somethinf else (or something better) they could use.

If that is indeed the case, I believe it's fair. Im not into language/compiler design etc., but if I have to take a guess, this is where metaprogramming would have helped, right? Like the ones provided by zig or rust?

Re: //go:fix inline and the source-level inliner

#68

Post by fghorow »

I know this is off-topic, and likely to get me down-voted, but hey! I'll live dangerously for the sake of repeating a hilarious (to me) .sig in a now ancient Usenet post.

These //go.* commands always remind me of this:

"""

//GO.SYSIN DD *

DOO DAH

DOO DAH

"""

(Why yes, that is IBM System 360 JCL from circa 1975. Why do you ask?)

Re: //go:fix inline and the source-level inliner

#69

Post by powerpixel »

alecthomas wrote: post #51
freakynit wrote: post #50

Earlier quoted context omitted.

Understood... but why in comments?

Someone else said this below... > Go designers distinguish between Go language as defined by Go spec and implementation details. > //go:fix is something understood by a particular implementation of Go. Another implementation could implement Go without implementing support for //go:fix and it would be a fully compliant implementation of Go, the language. > > If they made it part of the syntax, that would require other…

I'd buy it. AFAIK the goal of Go is to have as little breaking changes as possible between versions. Although they introduced backwards compat breaking features such as generics have they not ?

Re: //go:fix inline and the source-level inliner

#70

Post by frou_dh »

pjmlp wrote: post #61
freakynit wrote: post #48

Can't golang devs prioritize something like annotations or other attribute/metadata system instead of writing these in comments? I'm pretty sure this must have been raised a lot of times before, so just wanted to ask if there is/are any specific reason(s)?

This is typical Go design, other languages do it worse, it isn't really needed, and then it gets added half way as it was supposed to be if done early on, and everyone cheers how Go is a "simple" language. Just like some other famous languages of the authors.

It's abject hackery because such "comment" directives don't even necessarily have to be a comment to be active:

    const x = `This whole thing is
    a
    //go:generate worse-is-better
    multiline
    string literal`
A lot of people in this discussion are beating up Go for using syntactical comments for directives, but in reality the implementation is even less principled than that!
Post reply on HN