Russ Cox deixa o cargo de líder técnico do Go

 (groups.google.com)
1 pontos por GN⁺ 2024-08-02 | 1 comentários | Compartilhar no WhatsApp
  • O projeto Go está fazendo a transição de uma liderança centrada em Russ Cox, mantida por mais de 12 anos, para uma nova estrutura centrada em Austin Clements e Cherry Mui
  • A partir de 1º de setembro de 2024, Austin assumirá a liderança técnica da equipe Go no Google e de todo o projeto Go, enquanto Cherry liderará o Go core, incluindo compilador, runtime e releases
  • Cox avalia que uma liderança única de longo prazo traz estabilidade, mas pode reduzir o espaço para o crescimento de novas lideranças, e vê a transição de liderança do Python em 2018 como um precedente positivo
  • Cox não está deixando o Go e permanecerá como colaborador individual em discussões de design, revisão de CLs, envio de issues, trabalho em partes da biblioteca padrão e palestras no GoLab
  • Daqui para frente, ele pretende focar mais em Gaby e Oscar para aumentar a produtividade no rastreador de issues do Go e expandir para outros projetos formas de ajudar mantenedores de código aberto

Transição de liderança no Go

  • A partir de 1º de setembro de 2024, Austin Clements assumirá como líder técnico do Go
    • Isso cobre tanto a equipe Go do Google quanto todo o projeto Go
    • Atualmente, Austin é o líder técnico da área hoje chamada de “Go core”
  • Cherry Mui sobe para o papel de líder da área Go core
    • Go core inclui a toolchain do compilador, o runtime e os releases
  • Russ Cox não está deixando o projeto Go, mas dará um passo atrás no centro das tomadas de decisão

Por que uma troca é necessária após 12 anos de liderança

  • Para Cox, o cargo de líder técnico não é honorário, mas mais próximo de um papel de serviço
    • Ao longo de mais de 12 anos liderando o projeto Go, ele se concentrou em criar as condições para que as pessoas pudessem fazer um bom trabalho
  • Projetos grandes se beneficiam de uma liderança estável, mas em algum momento também passam a precisar dos pontos fortes e da perspectiva renovada de novos líderes
  • Cox considera que o Go já acumulou estabilidade suficiente com mais de 12 anos de liderança única
  • Ele vê o modelo BDFL como algo pouco saudável tanto para a pessoa quanto para o projeto
    • É difícil abrir espaço para novos líderes
    • Cria um ponto único de falha
    • Reduz o potencial de crescimento do projeto
  • O Python é citado como um caso que se beneficiou muito quando Guido van Rossum deixou o cargo em 2018 e outras pessoas passaram a liderar

Confiança em Austin Clements e Cherry Mui

  • Austin trabalha com Go no Google desde 2014, e Cherry desde 2016
  • Cox avalia que os dois têm excelente julgamento e profundo conhecimento do Go e dos sistemas em que ele roda
  • Ele diz que vem contando com Austin e Cherry quando precisa entender melhor questões gerais de design ou detalhes do compilador, linker e runtime
  • Os líderes atuais de outras áreas também continuarão à frente de seus domínios
    • Roland Shoemaker continuará liderando a segurança do Go
    • Rob Findley e Hana Kim continuarão liderando as ferramentas do Go e o suporte a IDEs

O papel que Russ Cox terá daqui para frente

  • Cox pretende se afastar deliberadamente das decisões para abrir espaço para que Austin e outros líderes avancem
  • Dentro do Go, ele continuará como colaborador individual
    • Participação em discussões de design do Go
    • Revisão de CLs
    • Respostas a perguntas sobre histórico antigo
    • Apoio quando necessário
    • Envio de issues e criação de CLs
    • Trabalho em algumas possíveis novas partes da biblioteca padrão
    • Defesa e promoção do Go em toda a indústria
    • Palestra sobre Go no GoLab, na Itália, em novembro
  • Os detalhes da transição ainda não foram definidos e foram compartilhados na lista de e-mails para discussão pública
  • Cox e Austin querem que essa mudança não pareça um grande acontecimento além de tornar o projeto Go mais forte e melhor

Mudança de foco para Gaby e Oscar

  • Cox pretende se concentrar mais em Gaby and Oscar daqui para frente
  • O objetivo é gerar contribuições úteis no rastreador de issues do Go e ajudar quem trabalha no Go a ser mais produtivo
  • Com o trabalho em Oscar, ele espera encontrar formas de ajudar mantenedores de código aberto e ver essas práticas adotadas também em outros projetos
  • Oscar tem três objetivos principais
    • Criar algo útil
    • Aprender algo novo
    • Abrir caminho para outros projetos
  • Esses objetivos se conectam com metas mais amplas que ele sempre perseguiu no Go, por isso Oscar lhe parece um próximo passo natural

Reação da comunidade e pedido por transparência

  • Daniel Martí cita modules e generics como grandes mudanças e marcos do Go na última década, e avalia que Cox teve papel central no sucesso de longo prazo do projeto
  • Junto da discussão sobre a transição, ele propôs maneiras de aumentar a transparência em torno de compilador e runtime
  • Cherry Mui respondeu que as notas de reunião e as office hours são uma boa oportunidade para aumentar a transparência e a participação entre a equipe de compilador/runtime do Google e a comunidade
    • Ela pretende publicar uma atualização na lista de e-mails quando a próxima office hours for marcada
  • Vários participantes agradeceram a Cox por seus 12 anos de liderança e por suas contribuições ao Go, além de parabenizar Austin e Cherry por seus novos papéis

Leituras relacionadas

1 comentários

 
GN⁺ 2024-08-02
Opiniões no Hacker News

  • rsc, obrigado por todo o trabalho ao longo desses anos. Nos últimos 12 anos, desenvolver em Go ficou muito mais agradável com o detector de condições de corrida, o empacotamento padronizado de erros, módulos, genéricos, atualizações da cadeia de ferramentas etc.
    Ainda há coisas que eu gostaria de ver. Pessoalmente, tenho na minha lista de desejos tipos soma, enums/tipos de intervalo melhores, imutabilidade e impossibilidade de nil, mas, mesmo assim, Go é um dos ecossistemas mais agradáveis em que já desenvolvi

    • Eu apontaria o versionamento de módulos como a maior contribuição técnica do RSC. É algo absolutamente fundamental para um ecossistema de linguagem
      https://research.swtch.com/vgo-intro
    • Ao ver non-nilness, ainda me lembro desta thread
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • É uma boa lista de coisas que tornaram Go uma linguagem melhor nos últimos anos. Eu também acrescentaria os iteradores, que Russ tem impulsionado bastante recentemente
    • Acho que Go teria sido muito mais popular se tivesse tido tipos nullable ou tipos soma desde o início
    • Também não dá para esquecer a mudança de semântica do loop for tradicional de três partes: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      Por causa dessa mudança, vejo o Go 1.22 como a primeira versão de Go que, na prática, quebrou seriamente a compatibilidade com Go 1, mesmo que o projeto oficial não reconheça isso

  • Pessoalmente, vejo Go como um dos projetos open source mais bem geridos até hoje. Também tiro o chapéu para o Google por apoiá-lo

    • Fico curioso para saber quais elementos fariam dele um projeto bem gerido
    • Fico curioso para saber quem, realisticamente, tem a “propriedade” de Go
      Em teoria, seria algo como uma entidade ou comitê independente, mas fico curioso sobre quem paga pelos custos da maioria das pessoas que de fato trabalham nele. É o Google?
    • Parece um efeito colateral de Go ter falhado na missão de substituir C++ ou Java e ter virado uma linguagem que substitui Ruby/Python etc. no lado de APIs
      Com isso, o objetivo do projeto deixou de ser dominar o mundo e passou a se alinhar melhor aos usuários, enquanto Rust, Zig etc. ficaram com essa guerra
    • Apoiar só o comportamento da glibc e ignorar o padrão ELF à vontade certamente é requisito de um projeto “mais bem gerido”. /s

  • Achei interessante o trecho “não acredito que o modelo BDFL (ditador benevolente vitalício) seja saudável para pessoas ou projetos”. Os melhores projetos têm um BDFL, e os melhores BDFLs parecem ser céticos em relação ao próprio poder

    • Muitas vezes parece que pessoas competentes que não têm interesse em liderança acabam sendo os melhores líderes
      Em contrapartida, pessoas que querem se tornar líderes porque querem ser conhecidas como “líderes” às vezes não têm nem competência nem senso de responsabilidade
    • Concordando ou não com toda a primeira parte, não é tão surpreendente que os melhores BDFLs sejam céticos quanto ao próprio poder
      A principal vantagem de uma única pessoa ter autoridade para decidir unilateralmente, a meu ver, é conseguir contornar impasses quando há muitos interessados. Se um projeto permitir que um líder se sinta legitimado a reverter decisões que contam com forte consenso, será muito mais difícil formar uma comunidade grande o suficiente para que as pessoas a conheçam
    • Não acho que isso esteja certo. Python teve um BDFL, mas não parece ter se beneficiado muito disso. Também não sei bem de quais outros projetos essa atitude vem
      Olhando por alto, parece uma forma parecida com outras burocracias: pode reduzir drama, mas não aumenta a qualidade de maneira visível. Por outro lado, há montes de projetos que fracassaram porque um único dono não foi flexível o bastante, mas isso simplesmente é tratado como algo que não vale a pena discutir
    • As únicas pessoas que deveriam ter poder são as que não o desejam
      Isso vai muito além de projetos open source
    • A própria ideia de BDFL é uma piada, e isso aparece no nome
      Era uma expressão que reconhecia a “realidade no chão” do papel que GvR tinha como criador do Python, não algo pensado seriamente como princípio de gestão de projetos. Era uma descrição, não uma prescrição, mas o conceito acabou sendo reificado demais

  • rsc, muito obrigado por todo o esforço dedicado a esta linguagem, que me levou à engenharia de software
    Já mexi com várias linguagens de programação, mas Go ainda parece minha casa. A experiência de desenvolvimento é excelente, e valorizo muito o fato de a linguagem e seus criadores defenderem a simplicidade e a responsabilidade sem pedir desculpas por isso. Desejo sorte e bons resultados em tudo o que vier pela frente

    • De nada. E obrigado por este comentário
      Quando começamos Go, eu nunca imaginei que a linguagem teria um impacto tão positivo na vida das pessoas e atrairia novas pessoas para programação e engenharia de software. Esse impacto é a parte de que mais me orgulho

  • O blog do RSC é muito bom: https://research.swtch.com/

    • Só agora percebi que rsc pode ser uma sigla desse blog
    • É um blog incrível. Já disse isso antes neste site, mas a série dele sobre expressões regulares tem uma qualidade absurda, e é um grande privilégio que ele simplesmente a tenha colocado ali para todos verem

  • Obrigado por todas as contribuições para Go
    Mas há uma coisa sem relação com Go da qual discordo. Python não se beneficiou da saída de GvR. A nova “liderança” é não técnica e autoritária, e fez a maioria dos verdadeiros contribuidores open source ir embora
    O desenvolvimento está estagnado, exceto por algumas contribuições corporativas de qualidade duvidosa; o clima é opressivo, e a única coisa que importa é estar em uma posição de poder na Microsoft/Instagram/Bloomberg. Talvez a culpa nem seja necessariamente dessas empresas. Elas talvez não saibam que sua generosidade está sendo explorada

  • Só o gofmt provavelmente já economizou uma quantidade enorme de tempo no mundo todo. Na prática, ele está na origem de praticamente todos os outros ecossistemas de linguagem dizendo “beleza, vamos simplesmente usar formatação automática”
    Eu odeio o que formatadores automáticos fazem com o meu código, mas gosto de não precisar mais falar sobre espaços em branco

    • Curiosamente, em todas as outras linguagens eu detesto formatadores automáticos e uso espaços em vez de tabs, mas em Go me acostumei desde o começo com a forma como o gofmt formata o código
      Depois disso, você passa a apreciar não precisar gastar muito tempo com isso, e, pelo menos para a maioria, não é um problema

  • Hoje soube do projeto no qual ele pretende se concentrar: https://go.googlesource.com/oscar/+/refs/heads/master/README...
    Dizem que é uma arquitetura baseada em LLM para ajudar na manutenção de projetos open source. Parece bacana

  • https://www.youtube.com/watch?v=wwoWei-GAPo — o projeto avançou muito desde essa época
    Fico feliz que ainda esteja vivo e prosperando. Em 2009, acho que eu não esperava que chegasse a isso. Sem Russ, não creio que Go estaria onde está hoje. As contribuições dele para o projeto foram enormes

  • Obrigado ao Russ. Colocar o suporte a ferramentas como elemento de primeira classe foi revolucionário e ainda é uma das características mais marcantes de Go