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

The design of transparent telemetry

research.swtch.com

Post reply on HN
Print view View original

21–30 of 74 posts

Re: The design of transparent telemetry

#21

Post by verdverm »

mort96 wrote: post #20
verdverm wrote: post #16

Earlier quoted context omitted.

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

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.

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

Re: The design of transparent telemetry

#22

Post by quectophoton »

dewey wrote: post #10
quectophoton wrote: post #7

Earlier quoted context omitted.

But still there's programs like Git as an existing example of this kind of "ask the user" thing. Last time I checked: * When you run `git init` without having configured default branch name it warns you with a big wall of text. * When you run `git commit` without having configured a user, it warns you with a big wall of text. * When you run `git pull` without having configured the strategy, it warns you with a big wa…

As much as I like and appreciate git, it's hardly a good example for something with great UX.

Exactly, it's an example of a CLI that already messed up its interface, and has actually changed commands (checkout -> switch, has added flags for submodules, etc), and overall has improved since past versions, and still tries to improve.

And AFAIK it didn't add telemetry to send used commands to any server, even if that would have been by far the easiest way, given 90% of devs use it and complain about how bad it is.

It's an arbitrary percentage, but it gets the point across. The amount of devs using git is probably at least an order or magnitude higher than those using Go.

Go, on the other hand, already has decent-ish tooling (at least better Git), but it wants to add opt-out telemetry anyway.

Re: The design of transparent telemetry

#23

Post by mort96 »

verdverm wrote: post #21
mort96 wrote: post #20

Earlier quoted context omitted.

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.

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

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.

Re: The design of transparent telemetry

#24

Post by verdverm »

mort96 wrote: post #23
verdverm wrote: post #21

Earlier quoted context omitted.

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

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 want…

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

Re: The design of transparent telemetry

#25

Post by traceroute66 »

verdverm wrote: post #16
mort96 wrote: post #13

Earlier quoted context omitted.

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 i…

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

> 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.

Re: The design of transparent telemetry

#26

Post by traceroute66 »

speedgoose wrote: post #11
rapnie wrote: post #9

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

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, ob…

> 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.

Re: The design of transparent telemetry

#27

Post by mort96 »

verdverm wrote: post #24
mort96 wrote: post #23

Earlier quoted context omitted.

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 want…

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

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.

Re: The design of transparent telemetry

#28

Post by mynameisvlad »

none_to_remain wrote: post #18
verdverm wrote: post #16

Earlier quoted context omitted.

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

If mort96 is writing libraries it does

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.

Re: The design of transparent telemetry

#29

Post by verdverm »

mort96 wrote: post #27
verdverm wrote: post #24

Earlier quoted context omitted.

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

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 towar…

If that's the way you feel, then stop using Go. No need to make misleading statements because you have some gear to grind every time telemetry comes up

Re: The design of transparent telemetry

#30

Post by mort96 »

verdverm wrote: post #29
mort96 wrote: post #27

Earlier quoted context omitted.

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 towar…

If that's the way you feel, then stop using Go. No need to make misleading statements because you have some gear to grind every time telemetry comes up

What have I said that's misleading? I don't want to expose my users to Google's telemetry, and that is affecting my choice of language; what part of that do you have a problem with?
Post reply on HN