10 ms·

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 so

by 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".
        mynameisvlad 4y ago
        This: > but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. does not follow from this: > One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library". An ecosystem becomes enticing due to a number of factors. Availability of libraries is one thing, but so is the language, tooling, and general popularity. Those are all interdependent as a thriving ecosystem will generally mean better tooling and more focus being put on the language development, which boosts the language's popularity. A user is going to choose a language based on all these factors, and while a large number of libraries would be one of the factors in favor, telemetry would be one against. It's up to the developer choosing the language to weigh these factors, not the individual library developers. Nor does writing a library for a particular language "push telemetry onto their users" unless the library is actually pushing telemetry directly onto their users. The language or tooling doing it does not equate to the library itself doing it.
        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...

by mort96 4y ago

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".
        mynameisvlad 4y ago
        This: > but it would contribute to inducing those developers to use the hypothetical telemetry-enabled Go toolchain. does not follow from this: > One library is probably not the deciding factor, but an ecosystem of libraries is just many thousands of instances of "one library". An ecosystem becomes enticing due to a number of factors. Availability of libraries is one thing, but so is the language, tooling, and general popularity. Those are all interdependent as a thriving ecosystem will generally mean better tooling and more focus being put on the language development, which boosts the language's popularity. A user is going to choose a language based on all these factors, and while a large number of libraries would be one of the factors in favor, telemetry would be one against. It's up to the developer choosing the language to weigh these factors, not the individual library developers. Nor does writing a library for a particular language "push telemetry onto their users" unless the library is actually pushing telemetry directly onto their users. The language or tooling doing it does not equate to the library itself doing it.
        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...