Hacker News Reader

Comment by hn92726819 | Hacker News Reader

> Asking nicely doesn't work in pratice

LLVM, GCC, rust, zig, D, etc don't have telementry and they seem to be doing fine. What makes go special? They aren't trying to be more efficient than rust. It isn't more widely used than GCC. I would argue they don't need this telemetry at all.

View on HN

FWIW, there is a proposal to add telemetry to LLVM [0] and Rust used to have telemetry [1], both off by default. Some things in the node.js world have telemetry enabled by default, like Next.js [3].

Some people are posting here as if this is already decided -- AFAICT, that's not the case. It's not even a formal proposal yet, and the stated intent was to start a conversation around something concrete. (For context, this is standard for how the Go project approaches large topics, including for example I think there were something like ~8 very detailed generics design drafts from the core Go team over ~10 years).

It sounds like the Go team is going to take some time to look into some of the alternative approaches suggested in the feedback collected so far.

In any event, this is obviously a topic people are very passionate about, especially opt-in vs. opt-out, but I guess I would suggest not giving up hope quite yet.

[0] https://discourse.llvm.org/t/rfc-lldb-telemetry-metrics/6458...

[1] https://github.com/rust-lang/rustup/issues/341

[2] https://nextjs.org/telemetry

> What makes go special?

it's owned by an ad company

No one claimed it's essential to have telemetry or that a language literally can't do without it. After all, Go is doing fine without telemetry too.

But that doesn't mean it's not useful, for Go but also gcc, or Zig, or D, or any other language.

A long list of use cases is given here: https://research.swtch.com/telemetry-uses

Useful doesn't mean it should be done. There are a ton of useful things for me I don't do because it's not right to do them.

Apparently as soon as a company becomes big enough, the line between convenience and ethical becomes very blurry.

> Useful doesn't mean it should be done.

I never said anything about what should be done. I'm just saying it is useful, as the previous commenter said it's not.

When did I say it isn't useful? I said they didn't need it. They also don't need to install a kernel module that records every keystroke and memory access, but it would certainly be useful data.

Have you asked core developers of those languages how they feel about this? I'd bet that you'd have near unanimous agreement that this class of information would be useful for informing support decisions.

Where I'd expect difference is precisely over the question of whether it's worth the cost & trust issues. That makes me wonder whether there might be some middle-ground here where some third-party like the Linux Foundation could run a telemetry service which is highly public in both its design and collected data, and whether that would be enough that many people would be comfortable with this kind of service without Google's business reputation entering into the equation.

> useful for informing support decisions

Useful does not equal ethical or legal. A lot of things would be useful to me.

Please enumerate. Go on.

Hence the second paragraph in the comment you're replying to. There's no question that this could be implemented legally but the ethical considerations are legitimate and warrant extensive discussion for an open source community. I think that the Go proposal has been derailed by a lot of hot takes based on scenarios far in excess of what's actually described, but I also think it's quite likely that many languages' core developers would look at that and agree that they don't want that information badly enough to spend time trying to negotiate those hazards.

What if your plumber installed a camera in your bathroom for informed support decisions? Sure would be useful for him to see where you put those "biodegradable" baby wipes after the deed.

A more apt analogy would be a sensor which anonymously reports if a pipe starts leaking so the manufacturer has a sense of their failure rate.

Do you really think that's anything like the scenario being proposed?

Here's what I think would be a closer analogy to what's actually being proposed: the water company installs a smart meter allowing them to read usage data more frequently. They randomly sample 2% of customers' data and prepare a histogram showing the top daily usage hours and total usage over a monthly period.

The water company already has a connection to you (the pipe) and the smart meater measures that connection. The smart meter does not collect information how you use that water inside your house. This analogy would match a website collecting anonymous usage statistics for connections but would not match an otherwise offline program making connections to collect data.

Yes, that’s why I think it’s a close fit for what Russ proposed rather than the more outlandish conspiracies circulating in social media.

I always wondered how much intelligence they gather from the Go playground.

Probably the data is too wild to make any use of, but then all the folks who have a clue using the playground as a kind of proof-of-concept play area... would be great for analysis.

Anyways, I'm not sure how well it would work, regardless of if it should be a thing at all. The majority of stuff I do, and the folks at work, we all have build pipelines that control internet access, use cache systems, etc... so I'm not sure it even matters.

I was actually wondering how much this would affect many build pipelines — if you're doing your builds in a container, the 7 day threshold would never even be reached unless you enabled caching for that file.

The main thing I think this would do is help them flesh out the non-mainstream configurations. For example, I've used Go on AIX but I'd be surprised if bug reports on that platform didn't hit basically every maintainer by surprise since statistically nobody tests on it regularly or even has access to do so. I'd think most of the value of systems like this would be finding out that the change they tested exhaustively on everything Google normally uses is also going to break 100% of some niche community.

C# ( net core ) has telemetry, as well as Java so it's not that it does not exists in other very popular languages.

https://www.oracle.com/java/technologies/javase/terms-java-u...

https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

Also the idea of GCC is more used than Go and GCC does not have telemetry so GO doesn't need it is completly unrelated.

Most dev working on core tools want telemetry to improve those tools, it's invaluable data to make the right decisions.

> C# ( net core ) has telemetry, as well as Java

Which Java distribution? Maybe the Oracle JDK/JRE? I highly doubt the Oracle JDK/JRE has serious usage numbers because of it's (quite commercial) license.

> dotnet, vscode (Microsoft), golang (Google), Oracle JDK/JRE, Nextjs (Vercel), ...

I wonder if there's some trend where corporate backed, large "open source/source available" projects being more open to telemetry compared to more "open community" projects.

For non-corporate projects, the general thought process might be it's fine to leave efficiency gains and improvements on the table if it means violating some foundational principles. While in a business setting, those efficiency gains could be very tempting since it can translate to more money, market share or promotions and that way of thinking gets applied to the open source projects as well.

I think your analysis is correct, and would also add that corporate projects probably have both the culture of monitoring (they use it for everything else) and the expectation that they have to deadlines so they prioritize the idea of being able to ship something with the confidence that it either won't break anyone or they'll be able to know & react quickly if it does. Open source didn't used to have that same focus since it was rarely someone's job and there was more understanding that time was in short supply (“if it breaks, let me know or send a patch”).

It probably also helps there's more easy access to infrastructure for all of this: servers and sysadmins. Ignoring everything else, that's much harder for your more classic volunteer effort open source project: servers cost money, and maintaining them costs time (usually better spent on actually writing code and such).

> GCC is more used than Go and GCC does not have telemetry so GO doesn't need it is completly unrelated.

I mentioned that because an argument could be made that they're the most popular, or they're trying to be the most efficient language and that's why they might "need" this telemetry data.

> Most dev working on core tools want telemetry

Yet somehow, almost all open source, popular, efficient tools don't have telemetry. Like the ones I listed + python + Linux + coreutils + bash.

Of course they want this. But there are mountains of successful projects that work very well without it, and every one serves as evidence that this Isn't as important as they let on. We shouldn't subject our personal computers to google tracking because they want more tracking data.

In case anyone wants to mention that it's Google's language and they can do what they want with it, this is a perfect example of why people aren't happy with Google's control of the language

Reply on news.ycombinator.com