Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



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?).

    • by mmell ( 832646 )
      It's news if you program in Go (although even then, probably pretty uninteresting). Go's got a tick-box or two left to go before it'll be ready for prime time; but I personally think it's well on target. This guy's stepping down, not being asked to leave or forced out. Sounds like good (if uninteresting) news to me.
      • 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.
        • by mmell ( 832646 )
          Yeah, that's the main one, and it's (unfortunately) implicit in every Go language design choice - their departure from the traditional object model was intentional, the justification being that they wanted to simplify the compiler and project management. Their methodology works as well as what it replaces and it does have a certain charm, but it basically fixes something that wasn't broke and requires me to make a very large effort I didn't previously need to. Highly annoying.
          • 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 @02: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.

            • by mmell ( 832646 )
              Yeah, but it's like getting rid of Insecure Exploder - some stuff just plain needs it to be there. IE's still in Windoze for that reason, if you know where to look. In this case, the object model has been baked into so many business processes, this isn't just a facelift, it's a heart-lung transplant.
              • 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.

                • How's that going, BTW? There shouldn't be anybody left using the old v4 IP stack after all this time. Only . . . how much no longer manageable or maintainable stuff's gonna get lost, and are you sure the world's okay with losing it? The same thing applies here - there's too much wrapped up in the existing way of doing things to just punt it all away and dive in on somebody else's scheme. I like where Google's head is at, but unless it can be made to work and play nice with others, Go will remain a bit s

  • will the AI bubble be over please?

8 Catfish = 1 Octo-puss

Working...