> For sure it may have a few digits less of accuracy in some dashboards but who cares.

You could argue that it's ultimately the users who suffer. Telemetry helps guide development, so it's harder for developers to know what to focus their efforts on.

But the users can still report issues.

And Golang also has the yearly survey that gives much more valuable inputs than telemetry could track IMHO.

Assuming every Go user on the planet fills it out.

They don’t have to care about the super rare cases, and in practice they never did. The survey has already a more than big enough sample to take the right decisions.

> But the users can still report issues.

They can, but do they? Russ' very first blog post gave several examples where major issues slipped under the radar because they went unreported. The example that sticks in my mind is that they accidentally introduced a dependency on a c compiler on Mac that was not reported for over a year simply because users assumed it was meant to be a dependency.

Several counterexamples were listed in the article.

Reminds me of the whole walrus operator python thing.

People were using it, they took it away (IIRC, could be wrong about that), people whined, they brought it back as an explicit operator, people really whined and the BDFL walked away.

Telemetry would have told them what exactly?

The walrus operator did not exist before 3.8, there was no real alternative before. The backlash was from people who dislike the idea and would prefer Python didn't add it.

The operator didn’t exist but the functionality did. It was just a side effect of python’s wonky variable scoping which they gave an operator.

I’m not familiar with how it works now but the example I remember was the variables escaping from list comprehension statements, like:

  x = [y for y in z]
  if y != z[-1]:
    bad_stuff_happened()

Or something like that, maybe I’m wrong, honestly never had a use for the walrus.

Python’s scoping rules are wonky, but the walrus is generally useful in two cases. The first one is to define a variable in an `if` and only run the contents of the `if` if the variable is truey — for example, re.search returns a Match object or None:

    if (m := re.search("regex is(n't)? fun")):
        print("there was a match")
        # do something with m

The other would be defining a variable in the `if` clause of a list comprehension and using it in the output (which is not necessary in languages where map/filter is a first-class citizen, because you could just map before you filter):

    [y for x in xs if (y := f(x)) == 5]

I can’t think of a way to define a variable in either of those cases without using the walrus and without significantly extending the code (you can define the `m` object and then do `if m:` on two lines, or you can nest two list comprehensions).

There's also:

  while data := fh.read(131072):
    # do stuff

which is a lot nicer than:

  while True:
    data = fh.read()
    if not data: break
    # do stuff

Taking it to the extreme: Would be even better if they know what you write so send the whole code.

It's just a programming language not organ donation.

While I agree that going with what the users want is the correct approach, but "a few digits less of accuracy" really undersells how much the data quality will suffer.

It will pretty much become useless (how many people are going to opt-in, realistically?) - and that's fine if it's what the community wants.

Users wishes would be respected in both opt-in and opt-out scenarios.

They really didn’t wish for opt out in the discussions I read.