5 ms·

The final link in the post is relevant to mention. Pointing to the Github discussion related to this idea: https://github.com/golang/go/discussions/58409 https:

by rapnie 4y ago

The final link in the post is relevant to mention. Pointing to the Github discussion related to this idea: https://github.com/golang/go/discussions/58409 https://github.com/golang/go/discussions/58409

speedgoose 4y ago
Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. I know that managing a community online is difficult especially when the community is against a decision, but I think Google employees should communicate better. The most straightforward path for them is to announce that they have changed their mind about telemetry. Or everyone should use Rust instead, obviously.
- mort96 4y ago
  I'm guessing your last comment is a joke, but honestly, that's sort of the consequence for at least some of my projects. I like Go, and I have a prototype of something written in Go. Now that I understand the domain better, I want to rewrite it; the initial plan was to do the rewrite in Go as well, but honestly, I don't want to endorse Google's telemetry and push it onto my users. So the rewrite is going to be Rust instead.
  - verdverm 4y ago
    This is not adding telemetry to your code, it is very minimal telemetry within the go toolchain. They expect a user will send a week's worth of counters to the server once a year on average. It does not push telemetry on your users
    - none_to_remain 4y ago
      If mort96 is writing libraries it does
      - mynameisvlad 4y ago
        How? The telemetry is still only present in the toolchain. A library would be imported and built, and could trigger the telemetry collection, sure, but in what way would that be considered "part of their code". If another developer is using their library, then it would ostensibly be a go developer who themselves has chosen to opt in or out of the telemetry, so they wouldn't be pushing it onto their users either.
        none_to_remain 4y ago
        If there are a wide variety of well-maintained libraries available in Go, people are more likely to pick Go, or even feel compelled to choose it, and possibly be subject to telemetry. If the bulk of developers cease to create or maintain Go libraries, fewer people will use Go and be subject to its telemetry.
        mynameisvlad 4y ago
        I'm sorry, but that's an absurd argument. Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole? One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random library. And that still doesn't answer the question on how that possibly means telemetry gets injected into their code.
        none_to_remain 4y ago
        OK, I was imprecise, writing a library in this hypothetical future Go would not add telemetry to developers' code, but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".
        4y ago
    - mort96 4y ago
      My project is open source. That means I'm asking my users, explicitly or implicitly, to download the source code, download Go's tooling, and compile my code. That exposes them to Google's telemetry.
      - verdverm 4y ago
        If you are building a library, then you are likely targeting Go developers who have already made their decision. If you are building a binary you can publish those and no one has to compile them
        mort96 4y ago
        It's a CLI program with an associated library. That means anyone who wants to use it on a system I don't happen to publish binaries for, or who prefer to compile things from source rather than using pre-compiled binaries, or anyone who wants to use a commit I haven't published binaries for, or who uses a source package from their distro (Gentoo users, Arch users who use a source package from the AUR), anyone who wants to modify it to add a feature or fix a bug, all potential contributors, etc etc etc. would be exposed to Google's telemetry because of my decision to use Go. And then there's everyone who wants to make use of the library and chooses whatever language makes that easier. I've certainly used Python for some projects just because a certain library is most easily used from Python.
        verdverm 4y ago
        Have you read their proposal and blog posts? A Go installation will send a report ~1 per year on average This is not Google telemetry or analytics, this is independent Go telemetry and is very different I suggest everyone read about Transparent Telemetry before overreacting. It's honestly quite reasonable and will benefit everyone
        mort96 4y ago
        I'm not sure if you're aware, but the official Go tooling is developed and managed by Google; the decision makers and core developers are Google employees. Go is deeply died to Google. I'm not comfortable asking my users to send telemetry information to Google. The exact details aren't very important. People can make their own decisions about whether they're fine with it or not, but I'm not going to push people towards accepting it.
    - traceroute66 4y ago
      > This is not adding telemetry to your code 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.
      - ls65536 4y ago
        This is a valid forward-looking concern that I think needs to be much more clearly addressed. It's one thing to have default-enabled telemetry in the toolchain itself, but once that window is open it's going to be much more difficult to close it and stem the tide of telemetry features creeping in further elsewhere in the Golang ecosystem where they'd be much more of a privacy concern. 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.
        verdverm 4y ago
        From the issue on GitHub, Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this > 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.
        traceroute66 4y ago
        > Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this 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#discussioncomment-4909533 https://github.com/golang/go/discussions/58409#discussioncom... [2] https://github.com/golang/go/discussions/58409#discussioncomment-4910082 https://github.com/golang/go/discussions/58409#discussioncom...
- traceroute66 4y ago
  > Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. Yes, I noticed that. Particularly given the discussion at hand (telemetry), employing heavy handed moderation tactics is not a good look.
  - verdverm 4y ago
    They likely locked it because people are 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions 2. Violating the Go Community Code of Conduct (https://github.com/golang/go/discussions/58409#discussioncomment-4939751 https://github.com/golang/go/discussions/58409#discussioncom...)
    - traceroute66 4y ago
      > 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions As was pointed out multiple times during the ensuing "discussion": 1. The proposal and blog posts were heavily biased, if not one-sided (highlighting only "pros", no "cons", pushing towards the only option being "opt-out" etc. etc.) 2. Posts in opposition to the proposal were being moderated in a heavy handed fashion through the Github hide function etc. 3. Valid answers were not being provided to those in opposition to the proposal, instead the answers were largely brushed aside with dismissive waffle. Thus the only conclusion it was locked is because the discussion was not going in the desired direction, i.e. supportive of the proposal.
      - verdverm 4y ago
        > Posts in opposition to the proposal were being moderated in a heavy handed fashion > brushed aside with dismissive waffle > Thus the only conclusion ... It's hard to take your response seriously when you only offer > heavily biased, if not one-sided opinions. If you want to make an argument that can convince people, it is best to not use polarizing language. Most of the hidden comments are of very low quality or do not add to the discussion. Others are off topic. Many dissenting comments remain. So this "heavy handed moderation" you describe is not really accurate
- typical182 4y ago
  FWIW, people had started to post obscene ASCII drawings, were using various curse words, and there were many, many repetitive comments across the ~400 comments posted. From what I understand of the conversation there, the core Go team said they were going to take some time to digest the feedback, including [0]: > The goal here is a productive conversation that aims at better understanding of different positions. Many comments here have contributed to that, and I am grateful for them. To be extra clear, the people who have been discussing opt-in vs opt-out respectfully and with reasoned arguments are most welcome here and have been an important part of the signal, not the noise. Thank you to them in particular. > Much of the moderation is being done by volunteer contributors working valiantly to keep the conversation on track, polite, useful, and non-repetitive. I appreciate their efforts. > This discussion has in fact scaled somewhat beyond what GitHub discussions can reasonably manage (I just spent a while clicking every "load more" link on the page to make ^F work again), which is causing even more repetition, so I will probably lock the discussion at the end of the day and take some time to think about the feedback we've gathered so far. [0] https://github.com/golang/go/discussions/58409#discussioncomment-4936931 https://github.com/golang/go/discussions/58409#discussioncom...
  - musicale 4y ago
    > people had started to post obscene ASCII drawings, were using various curse words, and there were many, many repetitive comments across the ~400 comments posted Sounds like an appropriate and commensurate response to this terrible idea.
none_to_remain 4y ago
Incredibly disrespectful. At first glance I'm not a big fan of this proposal, but I'm probably less opposed to it per se, and for different reasons, than the typical commenter. But the behavior of "rsc" and "mvdan" there is just enormously decrementing my opinion of the Golang team.
- verdverm 4y ago
  mvdan is not on the Go team, he works on CUE primarily, he has been a volunteer for a long time. Can you point out specific comments that you find problematic? I have looked and am not sure which ones you are referring to

by rapnie 4y ago

speedgoose 4y ago

Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. I know that managing a community online is difficult especially when the community is against a decision, but I think Google employees should communicate better. The most straightforward path for them is to announce that they have changed their mind about telemetry. Or everyone should use Rust instead, obviously.

mort96 4y ago
I'm guessing your last comment is a joke, but honestly, that's sort of the consequence for at least some of my projects. I like Go, and I have a prototype of something written in Go. Now that I understand the domain better, I want to rewrite it; the initial plan was to do the rewrite in Go as well, but honestly, I don't want to endorse Google's telemetry and push it onto my users. So the rewrite is going to be Rust instead.
- verdverm 4y ago
  This is not adding telemetry to your code, it is very minimal telemetry within the go toolchain. They expect a user will send a week's worth of counters to the server once a year on average. It does not push telemetry on your users
  - none_to_remain 4y ago
    If mort96 is writing libraries it does
    - mynameisvlad 4y ago
      How? The telemetry is still only present in the toolchain. A library would be imported and built, and could trigger the telemetry collection, sure, but in what way would that be considered "part of their code". If another developer is using their library, then it would ostensibly be a go developer who themselves has chosen to opt in or out of the telemetry, so they wouldn't be pushing it onto their users either.
      - none_to_remain 4y ago
        If there are a wide variety of well-maintained libraries available in Go, people are more likely to pick Go, or even feel compelled to choose it, and possibly be subject to telemetry. If the bulk of developers cease to create or maintain Go libraries, fewer people will use Go and be subject to its telemetry.
        mynameisvlad 4y ago
        I'm sorry, but that's an absurd argument. Your argument is that one user publishing a library in a sea of libraries which enriches the ecosystem is equivalent to directly pushing telemetry onto their users.... Because people are enticed by golang as a whole? One library isn't going to be the deciding factor in someone choosing a language, and they'll likely have to deal with telemetry well before they get to a random library. And that still doesn't answer the question on how that possibly means telemetry gets injected into their code.
        none_to_remain 4y ago
        OK, I was imprecise, writing a library in this hypothetical future Go would not add telemetry to developers' code, but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library".
        4y ago
  - mort96 4y ago
    My project is open source. That means I'm asking my users, explicitly or implicitly, to download the source code, download Go's tooling, and compile my code. That exposes them to Google's telemetry.
    - verdverm 4y ago
      If you are building a library, then you are likely targeting Go developers who have already made their decision. If you are building a binary you can publish those and no one has to compile them
      - mort96 4y ago
        It's a CLI program with an associated library. That means anyone who wants to use it on a system I don't happen to publish binaries for, or who prefer to compile things from source rather than using pre-compiled binaries, or anyone who wants to use a commit I haven't published binaries for, or who uses a source package from their distro (Gentoo users, Arch users who use a source package from the AUR), anyone who wants to modify it to add a feature or fix a bug, all potential contributors, etc etc etc. would be exposed to Google's telemetry because of my decision to use Go. And then there's everyone who wants to make use of the library and chooses whatever language makes that easier. I've certainly used Python for some projects just because a certain library is most easily used from Python.
        verdverm 4y ago
        Have you read their proposal and blog posts? A Go installation will send a report ~1 per year on average This is not Google telemetry or analytics, this is independent Go telemetry and is very different I suggest everyone read about Transparent Telemetry before overreacting. It's honestly quite reasonable and will benefit everyone
        mort96 4y ago
        I'm not sure if you're aware, but the official Go tooling is developed and managed by Google; the decision makers and core developers are Google employees. Go is deeply died to Google. I'm not comfortable asking my users to send telemetry information to Google. The exact details aren't very important. People can make their own decisions about whether they're fine with it or not, but I'm not going to push people towards accepting it.
  - traceroute66 4y ago
    > This is not adding telemetry to your code 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.
    - ls65536 4y ago
      This is a valid forward-looking concern that I think needs to be much more clearly addressed. It's one thing to have default-enabled telemetry in the toolchain itself, but once that window is open it's going to be much more difficult to close it and stem the tide of telemetry features creeping in further elsewhere in the Golang ecosystem where they'd be much more of a privacy concern. 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.
      - verdverm 4y ago
        From the issue on GitHub, Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this > 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.
        traceroute66 4y ago
        > Russ believes it would be "clearly inappropriate" to push telemetry into user code, so yes, they have communicated their opinion on this 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#discussioncomment-4909533 https://github.com/golang/go/discussions/58409#discussioncom... [2] https://github.com/golang/go/discussions/58409#discussioncomment-4910082 https://github.com/golang/go/discussions/58409#discussioncom...
traceroute66 4y ago
> Locking the conversation and marking many disagreeing comments as spam or off-topic doesn’t look good for Golang. Yes, I noticed that. Particularly given the discussion at hand (telemetry), employing heavy handed moderation tactics is not a good look.
- verdverm 4y ago
  They likely locked it because people are 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions 2. Violating the Go Community Code of Conduct (https://github.com/golang/go/discussions/58409#discussioncomment-4939751 https://github.com/golang/go/discussions/58409#discussioncom...)
  - traceroute66 4y ago
    > 1. Overreacting without reading the proposal and blog posts and making inaccurate conclusions As was pointed out multiple times during the ensuing "discussion": 1. The proposal and blog posts were heavily biased, if not one-sided (highlighting only "pros", no "cons", pushing towards the only option being "opt-out" etc. etc.) 2. Posts in opposition to the proposal were being moderated in a heavy handed fashion through the Github hide function etc. 3. Valid answers were not being provided to those in opposition to the proposal, instead the answers were largely brushed aside with dismissive waffle. Thus the only conclusion it was locked is because the discussion was not going in the desired direction, i.e. supportive of the proposal.
    - verdverm 4y ago
      > Posts in opposition to the proposal were being moderated in a heavy handed fashion > brushed aside with dismissive waffle > Thus the only conclusion ... It's hard to take your response seriously when you only offer > heavily biased, if not one-sided opinions. If you want to make an argument that can convince people, it is best to not use polarizing language. Most of the hidden comments are of very low quality or do not add to the discussion. Others are off topic. Many dissenting comments remain. So this "heavy handed moderation" you describe is not really accurate
typical182 4y ago
FWIW, people had started to post obscene ASCII drawings, were using various curse words, and there were many, many repetitive comments across the ~400 comments posted. From what I understand of the conversation there, the core Go team said they were going to take some time to digest the feedback, including [0]: > The goal here is a productive conversation that aims at better understanding of different positions. Many comments here have contributed to that, and I am grateful for them. To be extra clear, the people who have been discussing opt-in vs opt-out respectfully and with reasoned arguments are most welcome here and have been an important part of the signal, not the noise. Thank you to them in particular. > Much of the moderation is being done by volunteer contributors working valiantly to keep the conversation on track, polite, useful, and non-repetitive. I appreciate their efforts. > This discussion has in fact scaled somewhat beyond what GitHub discussions can reasonably manage (I just spent a while clicking every "load more" link on the page to make ^F work again), which is causing even more repetition, so I will probably lock the discussion at the end of the day and take some time to think about the feedback we've gathered so far. [0] https://github.com/golang/go/discussions/58409#discussioncomment-4936931 https://github.com/golang/go/discussions/58409#discussioncom...
- musicale 4y ago
  > people had started to post obscene ASCII drawings, were using various curse words, and there were many, many repetitive comments across the ~400 comments posted Sounds like an appropriate and commensurate response to this terrible idea.

none_to_remain 4y ago

Incredibly disrespectful. At first glance I'm not a big fan of this proposal, but I'm probably less opposed to it per se, and for different reasons, than the typical commenter. But the behavior of "rsc" and "mvdan" there is just enormously decrementing my opinion of the Golang team.

verdverm 4y ago
mvdan is not on the Go team, he works on CUE primarily, he has been a volunteer for a long time. Can you point out specific comments that you find problematic? I have looked and am not sure which ones you are referring to