Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming Open Source

Go Tech Lead Russ Cox Steps Down to Focus on AI-Powered Open-Source Contributor Bot (google.com) 12

Thursday Go's long-time tech lead Russ Cox made an announcement: Starting September 1, Austin Clements will be taking over as the tech lead of Go: both the Go team at Google and the overall Go project. Austin is currently the tech lead for what we sometimes call the "Go core", which encompasses compiler toolchain, runtime, and releases. Cherry Mui will be stepping up to lead those areas.

I am not leaving the Go project, but I think the time is right for a change... I will be shifting my focus to work more on Gaby [or "Go AI bot," an open-source contributor agent] and Oscar [an open-source contributor agent architecture], trying to make useful contributions in the Go issue tracker to help all of you work more productively. I am hopeful that work on Oscar will uncover ways to help open source maintainers that will be adopted by other projects, just like some of Go's best ideas have been adopted by other projects. At the highest level, my goals for Oscar are to build something useful, learn something new, and chart a path for other projects. These are the same broad goals I've always had for our work on Go, so in that sense Oscar feels like a natural continuation.

The post notes that new tech lead Austin Clements "has been working on Go at Google since 2014" (and Mui since 2016). "Their judgment is superb and their knowledge of Go and the systems it runs on both broad and deep. When I have general design questions or need to better understand details of the compiler, linker, or runtime, I turn to them." It's important to remember that tech lead — like any position of leadership — is a service role, not an honorary title. I have been leading the Go project for over 12 years, serving all of you, and trying to create the right conditions for all of you to do your best work. Large projects like Go absolutely benefit from stable leadership, but they can also benefit from leadership changes. New leaders bring new strengths and fresh perspectives. For Go, I think 12+ years of one leader is enough stability; it's time for someone new to serve in this role.

In particular, I don't believe that the "BDFL" (benevolent dictator for life) model is healthy for a person or a project. It doesn't create space for new leaders. It's a single point of failure. It doesn't give the project room to grow. I think Python benefited greatly from Guido stepping down in 2018 and letting other people lead, and I've had in the back of my mind for many years that we should have a Go leadership change eventually....

I am going to consciously step back from decision making and create space for Austin and the others to step forward, but I am not disappearing. I will still be available to talk about Go designs, review CLs, answer obscure history questions, and generally help and support you all in whatever way I can. I will still file issues and send CLs from time to time, I have been working on a few potential new standard libraries, I will still advocate for Go across the industry, and I will be speaking about Go at GoLab in Italy in November...

I am incredibly proud of the work we have all accomplished together, and I am confident in the leaders both on the Go team at Google and in the Go community. You are all doing remarkable work, and I know you will continue to do that.

This discussion has been archived. No new comments can be posted.

Go Tech Lead Russ Cox Steps Down to Focus on AI-Powered Open-Source Contributor Bot

Comments Filter:
  • Is he still a major contributor to Go?
  • Somebody I never heard of - and couldn't care less about - is changing roles (at google?).

    • Comment removed based on user account deletion
      • If you're used to a language with a conventional object model, Go's encapsulation will be a major sore point. Specifically, overridden methods don't work the way you'd expect [dev.to], nor is there an easy way to make them work like you would.
        • Comment removed based on user account deletion
          • Simplifying the compiler and project management should never be language design goals. Simplifying programming in the language should always be the goal. Agree that inheritance wasn't broken.
          • by gweihir ( 88907 ) on Saturday August 03, 2024 @01:43PM (#64678216)

            I tend to disagree on the idea. No clue what actually happened in the design of Go, but the traditional object model is deeply broken and always has been deeply broken. Its main promises were software reuse and better software structure by direct use of design patterns. These advantages frankly never materialized because it is too hard to make that work in the traditional model. It is no accident that Python, Rust, Go and others do not use the traditional OO model and, quite frankly, the traditional model needs to die. It has massively overpromised and massively underdelivered. It has made things more complex for very little advantage. It confuses people into thinking everything has to be OO and OO is the only true way, which is very much not the case.

            • Comment removed based on user account deletion
              • by gweihir ( 88907 )

                Well, yes. Bad tech often takes a long time to die and serves as technological debt until it does. Accumulate too much of that and everything comes crashing down on some problem that would normally only be a minor disruption. There is reason to believe Microsoft and its products are approaching that point or have already reached it.

  • will the AI bubble be over please?

One good suit is worth a thousand resumes.

Working...