3 ms·

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 dev

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.
verdverm 4y ago
The more Go grows, the lower the probability that any one installation will send data, per the proposal. https://research.swtch.com/telemetry-intro#summary https://research.swtch.com/telemetry-intro#summary > sampling bullet point

3 ms·

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 dev

by none_to_remain 4y ago

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.
verdverm 4y ago
The more Go grows, the lower the probability that any one installation will send data, per the proposal. https://research.swtch.com/telemetry-intro#summary https://research.swtch.com/telemetry-intro#summary > sampling bullet point