Re-recording of my "Go Changes" talk at GopherCon 2023 (USA). See research.swtch... for more.
Пікірлер: 22
@csebastian39 ай бұрын
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!"
@wolpumba40999 ай бұрын
*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.
@ronminnich3 ай бұрын
Great talk. I opted in. Thanks for setting up telemetry, it is a great idea.
@zachend27509 ай бұрын
You always are the best and thank you for working on go!
@256k_5 ай бұрын
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
@TheTmntmike9 ай бұрын
Why the lack of telemetry in other programming languages did not prevent it from becoming a good, popular, stable and convenient solution?
@PedroNasser7 ай бұрын
I wonder which languages are you referring to.
@Antonio-yy2ec9 ай бұрын
Excellent!
@Ronoaldo9 ай бұрын
I opted in too.
@jeroendee9 ай бұрын
Russ, thank you very much!
@edwardrf9 ай бұрын
🎉 I've been waiting for this talk!
@user-lk6vu6hw8b9 ай бұрын
love the shirt! where can i buy it ?
@sallamasyonvidoe9 ай бұрын
The information you provided is great, but you've become a legend in your shirt :)
@linearz9 ай бұрын
I want to help and I will opt-in :-)
@blompinne9 ай бұрын
Love the shirt!
@sealoftime9 ай бұрын
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!
@rogerpeppe9 ай бұрын
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.
@sealoftime9 ай бұрын
@@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
@bebobauomy12657 ай бұрын
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.
@ooijaz60632 ай бұрын
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.
@fennecbesixdouze17947 ай бұрын
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.
@fennecbesixdouze17947 ай бұрын
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.