Go Changes (GopherCon 2023)

[@csebastian3]

Russ, thanks for being a great example for the development world, showing us how to carefully and patiently care for a project throughout the years, producing a tool and ecosystem that is consistent, stable, and reliable. "Slow and steady wins the race!"

[@wolpumba4099]

*Summary* - 0:00 - Russ Cox re-recorded his "Go Changes" talk for GopherCon 2023, discussing why Go needs to change, how changes are approached, and the role of opt-in telemetry. - 0:18 - The talk does not focus on specific changes but on the overall process of deciding on changes. - 0:26 - Reasons for change: - 0:32 - Improvement is necessary as Go isn't always right the first time. - 0:44 - Adaptation to new technologies and fixing issues that arise over time is crucial to prevent Go from becoming "dead." - 1:13 - Decisions about changes in Go are based on improving software engineering, especially at scale. - 1:43 - Software engineering involves code maintenance, testing, compatibility, tooling, and package management over time. - 6:22 - Go's proposal process involves community consensus and is aided by data collection. - 7:37 - Data is important in reaching consensus, and various sources include user surveys, VS Code integration feedback, and user experience studies. - 8:41 - Surveys and interviews can be limited; hence, code analysis is also used to inform decisions. - 9:51 - Sampling a small number of examples can accurately represent a larger population. - 13:27 - Telemetry in the Go toolchain is designed to provide additional data on usage and issues users might not report. - 13:32 - The telemetry system records counters and crashes without sensitive data and is completely opt-in. - 19:14 - Telemetry data will be publicly available to avoid information imbalance and ensure transparency. - 20:06 - Sampling helps ensure even a low opt-in rate to telemetry can yield useful data for decision-making. - 22:02 - Russ Cox encourages users to share their experiences and issues with Go to inform its evolution.

[@TheTmntmike]

Why the lack of telemetry in other programming languages ​​did not prevent it from becoming a good, popular, stable and convenient solution?

[@PedroNasser]

I wonder which languages are you referring to.

[@ronminnich]

Great talk. I opted in. Thanks for setting up telemetry, it is a great idea.

[@256k_]

Thank you for all the work and sharing! please i would absolutely love another video about acme especially regarding how to setup acme with plan9port on macOS with all its external dependencies and features, how the acme file system is structured and other more advanced demos. thank you again

[@zachend2750]

You always are the best and thank you for working on go!

[@bebobauomy1265]

I think that the best decision is to make Go self-dependent. Until now, assembly is still used in the language and the std. Why is that? Because the language is not fast enough to be used in parts that need high-performance. assembly is still in use and will continue to be used unless the language at least be sufficient to achieve maximum performance in times of need, no matter what, everything is better than assembly.

[@ooijaz6063]

What do you mean? Everything will be at the end compiled to assembly. Processors only understand assembly, which maps 1:1 to the binary code. There must be somwhere the translation layer.

[@idanbenarush]

love the shirt! where can i buy it ?

[@Antonio-yy2ec]

Excellent!

[@Ronoaldo]

I opted in too.

[@jeroendee]

Russ, thank you very much!

[@sealoftime]

Opt-In telemetry, sadly, despite all amazing benefits that it brings was a PR disaster. Still seeing people arguing against Go usage as "Google-owned", "proprietary", "telemetry ridden" language on social platforms. Nevertheless, thank you for this amazing talk, explaining real stories, where telemetry has been used to improve the Go experience!

[@rogerpeppe]

I think you mean "Opt-out telemetry" there (the original Go telemetry proposal). I don't think that opt-in telemetry will raise the same red flags with people.

[@sealoftime]

@@rogerpeppe I honestly didn't even know the original intent was opt-out one. Same goes for most people I've stumbled upon, who've been genuinely concerned about any kind of telemetry in the toolchain

[@linearz]

I want to help and I will opt-in :-)

[@edwardrf]

🎉 I've been waiting for this talk!

[@sallamasyonvidoe]

The information you provided is great, but you've become a legend in your shirt :)

[@blompinne]

Love the shirt!

[@fennecbesixdouze1794]

The John Ousterhout quote is genuinely awful. Yes you are likely to reach "consensus" that way. That's how the C++ standards committee does their work, for example. That process is definitely not how you get a language like Go.

[@fennecbesixdouze1794]

The top responses in those surveys are going to always be things like: - Lack of try/catch exception handling - Lack of async/await etc etc insert whatever popular feature users find in other language and whose absence is a subtle but defining characteristic of what makes Go unique. "Shared goals", "same problem", "smart people", surveys and "consensus" don't get you to how Go is going to avoid becoming every other language. Certainly not by reading surveys that are going to always pressure it to become every other language. The design process for Go could be described as: "Consensus among a very tiny team of hand-picked and extremely opinionated and grizzled developers known primarily for being curmudgeons and bucking trends". The unique aspects of that description isn't the word "consensus", it's the other ones.