[yalue]

Here's an idea for how to maintain Go moving forward: keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward. Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch. That's how open source software is always supposed to work. Telemetry does nothing to improve this situation. If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop. Maybe focus on accepting PRs from people with ideas and strong enough motivation to work on them. I mean, there are 5000+ issues and 330 open PRs on the go github right now, so that should be plenty to keep them occupied. On top of that, how can literal thousands of issues not be a strong enough source of actionable usage information that they saw fit to try to get more? Do they plan on wrapping up all the open issues before looking at telemetry?

[oplaadpunt]

I really appreciate this point, and I think it applies very broadly. Good design comes from a coherent, individual (or group) vision. Citing examples will only incite discussions, because everyone has a different needs and ideas, but the things I most appreciate in tech and art share this common aspect.

As I see it, relying on excessive telemetry, surveys, focus-groups, etc is a bit of an indication that nobody at the top has a strong idea of where to take the project.

[fbdab103]

Which is strange coming from ~Go~ Google. The community loudly demanded features for years which ~Go~ Google said were unnecessary (dependency management, monotonic time, etc). Weird to think that telemetry would do anything to change their opinions when the project has always done what it wants.

Edit: fighting the markup trying to get strikethrough to work

[remus]

> keep making the damn tool however you want. The thing never would have existed in the first place if they had started with an industry survey. It was created to address a perceived need, by the people with the need, for themselves. This model is perfectly fine moving forward.

I disagree, doing what you feel like is a great approach when you have no users, your building a tool that solves your needs and basically saying "Try this it, it works great for me, maybe it'll be good for you too!"

Once you have millions of users and billions of lines of code you need to think about how your changes affect those users. If you get it wrong there's a huge cost to that (c.f. early forays in to go packaging and dependency management). This is why go's comparability promise is such a big deal and a big part of why go is a very popular language.

[randomdata]

> If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop.

They did stop. "Go 1" is complete.

Since 2017, the project renewed itself by moving to what is dubbed "Go 2"[1], being built around community feedback. Decisions are made based on data collected from the community. Adding telemetry to increase the amount of data available is in line with the new project scope. Go 1.13 was the first "Go 2" release[2].

Indeed, "Go 1" is still there if you want to use the tool that was built for what was needed at Google and nothing more. You don't have to move into the "Go 2" ecosystem. But if others want to put their time into that, why not? That's their prerogative.

[1] https://go.dev/blog/toward-go2

[2] https://go.dev/blog/go2-next-steps

[em-bee]

there are 5000+ issues and 330 open PRs on the go github right now, so that should be plenty to keep them occupied

just for the sake of argument, wouldn't telemetry be useful to know which of these issues are most likely to benefit the majority of users?

whether that's worth the cost of telemetry is another issue.

[guipsp]

You say this:

> keep making the damn tool however you want.

But then you follow up with this:

> If the Go team at google no longer has any ideas for what to work on (as must be the case if they're wasting their time on dumb crap like forced google spyware in a compiler) then they should just stop.

They want to add telemetry. So they should just add it. If you dislike it, then patch it out yourself. As you say:

>That's how open source software is always supposed to work.

[mseepgood]

> if they had started with an industry survey

They already do regular surveys.

[majorhelmet]

> Some industrial user wants a new Go feature or bugfix? Great. If it's enough of a problem, they can fix it and upstream a patch.

Inbefore I go to a new job and find out that they are using outdated, custom patched go compiler.

> I mean, there are 5000+ issues and 330 open PRs on the go github right now

How do they know which ones are affecting the most users?

> forced google spyware in a compiler

go is open source, feel free to compile it yourself without the telemetry. Which distros will do if any major promises would be broken

[MrMcDowall]

There's a lot of 'just' handwaving here about compiling without telemetry. We just need to look as far as VSCode, which is riddled with unremovable telemetry, and the entire project of VSCodium which has to exist to provide telemetry free versions, and still cannot remove all of it. You're discounting the complete waste of human time and effort required to undo something that should simply not exist in the first place.

In terms of the open GH issues, people are pretty vocal about which ones they think are most important to fix, as is the case for most popular projects. It's simply not true that the Go team have no way of knowing which of the open issues are most important to the community.