Yet ....
It could easily be only a matter of time before we see feature creep and another "proposal", this time to insert it into the binaries.
Yet ....
It could easily be only a matter of time before we see feature creep and another "proposal", this time to insert it into the binaries.
Without a strong commitment from the Golang maintainers that this is where it would stop (have they communicated anything to that effect?), we have no reason to believe it will stop here, and all the more reason to be concerned that this is just the beginning and it will be pushed much further in the future.
> To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the go command, the Go compiler, gopls, and govulncheck. I am not suggesting that instrumentation be added by the Go compiler to all Go programs in the world: that’s clearly inappropriate.
Erm, not quite....
Somebody explicitly asked (on one of the moderator hidden posts, I might add) "@rsc Can you guarantee that this will always be the case?"[1]
The answer was wishy-washy to put it politely:
"I can't guarantee we'll all still be here tomorrow. But for as long as Go exists and is developed, I expect that interested open source contributors like yourselves will notice and flag changes that move backward. That seems to me a more useful check on the future evolution of Go than anything I promise."
Saying "you'll have to notice and flag it" is not exactly reassuring. Especially given the way the Go team have been reacting to the "flagging" on the telemetry discussion itself !!
[1] https://github.com/golang/go/discussions/58409#discussioncom... [2] https://github.com/golang/go/discussions/58409#discussioncom...
Citing toxic users does not help your argument