Russ Cox deja el cargo de líder técnico de Go

 (groups.google.com)
1 puntos por GN⁺ 2024-08-02 | 1 comentarios | Compartir por WhatsApp
  • El proyecto Go pasa de un liderazgo centrado en Russ Cox durante más de 12 años a una nueva estructura encabezada por Austin Clements y Cherry Mui
  • A partir del 1 de septiembre de 2024, Austin asumirá como líder técnico del equipo de Go en Google y del proyecto Go en su conjunto, mientras que Cherry encabezará el núcleo de Go, incluyendo compilador, runtime y lanzamientos
  • Cox considera que, aunque un liderazgo único de largo plazo aporta estabilidad, también puede reducir el espacio para que crezcan nuevos líderes, y ve la transición de liderazgo de Python en 2018 como un precedente positivo
  • Cox no dejará Go: seguirá como colaborador individual en discusiones de diseño, revisión de CL, presentación de issues, trabajo en partes de la biblioteca estándar y charlas en GoLab
  • En adelante, se enfocará más en Gaby y Oscar para mejorar la productividad en el issue tracker de Go y extender a otros proyectos formas de ayudar a mantenedores de código abierto

Transición de liderazgo en Go

  • Desde el 1 de septiembre de 2024, Austin Clements asumirá como líder técnico de Go
    • Esto abarca tanto al equipo de Go de Google como al proyecto Go en su conjunto
    • Austin actualmente es el líder técnico del área conocida como “Go core”
  • Cherry Mui asciende para liderar el área de Go core
    • Go core incluye la toolchain del compilador, el runtime y los lanzamientos
  • Russ Cox no deja el proyecto Go, pero da un paso atrás del centro de la toma de decisiones

Por qué hacía falta un relevo tras 12 años de liderazgo

  • Para Cox, el rol de líder técnico no es un cargo honorífico, sino más cercano a un rol de servicio
    • Durante más de 12 años al frente del proyecto Go, se ha enfocado en crear las condiciones para que otras personas hagan buen trabajo
  • Los proyectos grandes se benefician de un liderazgo estable, pero en cierto momento también necesitan las fortalezas y la perspectiva fresca de nuevos líderes
  • Cox considera que Go ya acumuló suficiente estabilidad tras más de 12 años de liderazgo unipersonal
  • El modelo BDFL no le parece saludable ni para la persona ni para el proyecto
    • Hace difícil abrir espacio para nuevos líderes
    • Se convierte en un punto único de falla
    • Reduce el margen para que el proyecto siga creciendo
  • Menciona a Python como un caso que se benefició enormemente cuando Guido van Rossum dejó el cargo en 2018 y permitió que otras personas tomaran el liderazgo

Confianza en Austin Clements y Cherry Mui

  • Austin trabaja en Go en Google desde 2014 y Cherry desde 2016
  • Cox evalúa que ambos tienen un criterio sobresaliente y un gran conocimiento de Go y de los sistemas donde Go se ejecuta
  • Ha confiado en Austin y Cherry cuando necesitaba una comprensión más profunda de preguntas generales de diseño o de detalles del compilador, el linker y el runtime
  • Los líderes actuales seguirán al frente de sus respectivas áreas
    • Roland Shoemaker seguirá liderando la seguridad de Go
    • Rob Findley y Hana Kim seguirán liderando las herramientas de Go y el soporte para IDE

El papel que asumirá Russ Cox a partir de ahora

  • Cox planea apartarse deliberadamente de la toma de decisiones para abrir espacio a que Austin y otros líderes den un paso al frente
  • Dentro de Go, seguirá como colaborador individual
    • Participación en discusiones de diseño de Go
    • Revisión de CL
    • Responder preguntas sobre historial antiguo
    • Brindar apoyo cuando haga falta
    • Presentar issues y escribir CL
    • Trabajar en algunas posibles nuevas partes de la biblioteca estándar
    • Promover Go en toda la industria
    • Dar una charla sobre Go en GoLab en Italia en noviembre
  • Los detalles de la transición todavía no están definidos y se compartieron en la lista de correo para discusión pública
  • Cox y Austin quieren que este cambio no se perciba como un gran acontecimiento, salvo por el hecho de que hará al proyecto Go más fuerte y mejor

Un nuevo enfoque hacia Gaby y Oscar

  • En adelante, Cox se enfocará más en Gaby and Oscar
  • El objetivo es generar contribuciones útiles en el issue tracker de Go para ayudar a que quienes trabajan en Go sean más productivos
  • A través del trabajo en Oscar, espera encontrar formas de ayudar a mantenedores de código abierto y que otros proyectos también las adopten
  • Oscar tiene tres objetivos principales
    • Construir algo útil
    • Aprender algo nuevo
    • Trazar un camino para otros proyectos
  • Estos objetivos se conectan con las metas amplias que siempre ha perseguido en Go, por lo que Oscar le parece a Cox un siguiente paso natural

Reacción de la comunidad y pedido de transparencia

  • Daniel Martí mencionó modules y generics como grandes cambios e hitos de Go durante la última década, y valoró que Cox tuvo un papel clave en su éxito a largo plazo
  • Junto con la discusión sobre la transición, propuso formas de aumentar la transparencia en torno al compilador y el runtime
  • Cherry Mui respondió que las notas de reuniones y las office hours son una buena oportunidad para aumentar la transparencia y la participación entre el equipo de compilador/runtime de Google y la comunidad
    • Publicará una actualización en la lista de correo cuando se defina la próxima fecha de office hours
  • Varias personas agradecieron a Cox por sus 12 años de liderazgo y sus contribuciones a Go, y felicitaron a Austin y Cherry por sus nuevos roles

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-08-02
Opiniones de Hacker News

  • rsc, gracias por todo el trabajo de todos estos años. En los últimos 12 años, desarrollar en Go se volvió mucho más agradable gracias al detector de condiciones de carrera, el wrapping de errores estandarizado, los módulos, los genéricos, las actualizaciones de la cadena de herramientas y más.
    Todavía quedan cosas que me gustaría ver. Personalmente, en mi lista de deseos están los tipos suma, mejores enums/tipos de rango, inmutabilidad e imposibilidad de nil, pero aun así Go sigue siendo uno de los ecosistemas más agradables en los que he desarrollado hasta ahora.

    • Diría que una de las mayores contribuciones técnicas de RSC es la gestión de versiones de módulos. Es un elemento absolutamente fundamental para el ecosistema del lenguaje.
      https://research.swtch.com/vgo-intro
    • Al ver non-nilness, todavía recuerdo este hilo:
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • Es una lista bien resumida de los elementos que hicieron de Go un mejor lenguaje en los últimos años. También agregaría los iteradores, algo que Russ impulsó con fuerza recientemente.
    • Creo que Go habría sido mucho más popular si hubiera tenido tipos nullable o tipos suma desde el principio.
    • Tampoco hay que olvidar el cambio de semántica del bucle for tradicional de tres partes: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      Por ese cambio, considero que Go 1.22 es, en la práctica, la primera versión de Go que rompe seriamente la compatibilidad con Go 1, aunque el proyecto oficial de Go no lo reconozca.

  • Personalmente, creo que Go es uno de los proyectos open source mejor gestionados hasta ahora. También mis respetos a Google por apoyarlo.

    • Me da curiosidad qué elementos permiten considerarlo un proyecto bien gestionado.
    • Me pregunto quién tiene, en la práctica, la “propiedad” de Go.
      En teoría sería algo como una entidad o comité independiente, pero me pregunto quién paga los costos de la mayoría de las personas que realmente trabajan en él. ¿Google?
    • Parece un efecto secundario de que Go fracasó en su misión de reemplazar a C++ o Java y terminó siendo un lenguaje que reemplaza a Ruby/Python y otros en el lado de las API.
      Así que el objetivo del proyecto dejó de ser conquistar el mundo y pasó a encajar con sus usuarios, mientras que esa guerra quedó en manos de Rust, Zig y otros.
    • Claro, apoyar solo el comportamiento de glibc e ignorar a gusto el estándar ELF es lo que califica a un proyecto como “el mejor gestionado”. /s

  • Me parece interesante la parte de “no creo que el modelo BDFL (dictador benevolente de por vida) sea sano para las personas ni para los proyectos”. Los mejores proyectos tienen un BDFL, y los mejores BDFL parecen ser escépticos respecto de su propio poder.

    • Parece que muchas veces las personas capaces que no tienen interés en liderar terminan siendo los mejores líderes.
      En cambio, las personas que quieren ser líderes porque quieren que se las conozca como “líderes” a veces no tienen ni la capacidad ni el sentido de responsabilidad.
    • Más allá de si estoy de acuerdo con toda la primera parte, no sorprende mucho que los mejores BDFL sean escépticos respecto de su propio poder.
      Creo que la principal ventaja de que una sola persona tenga autoridad para decidir unilateralmente es que puede evitar los bloqueos que aparecen cuando hay muchos interesados. Si un proyecto siente que su líder puede revertir legítimamente decisiones con un consenso fuerte, será mucho más difícil formar una comunidad lo bastante grande como para que la gente la conozca.
    • No creo que esto sea correcto. Python tuvo un BDFL, pero no parece haber obtenido grandes beneficios. Tampoco sé de qué otros proyectos sale esta actitud.
      A grandes rasgos, parece una forma similar a otras burocracias: reduce el drama, pero no mejora visiblemente la calidad. Por otro lado, hay montones de proyectos que fracasaron porque un único dueño no fue lo bastante flexible, solo que se considera que no vale la pena discutirlos.
    • Las únicas personas que deberían tener poder son las personas que no quieren poder.
      Esto va mucho más allá de los proyectos open source.
    • La idea misma de BDFL es una broma, y eso se ve en el nombre.
      Era una expresión que reconocía la “realidad sobre el terreno” del rol de GvR como creador de Python, no algo pensado seriamente como principio de gestión de proyectos. Era una descripción, no una prescripción, pero el concepto terminó reificándose demasiado.

  • rsc, muchísimas gracias por todo el esfuerzo dedicado a este lenguaje que me llevó a la ingeniería de software.
    Probé varios lenguajes de programación, pero Go todavía se siente como casa. La experiencia de desarrollo es excelente, y valoro muchísimo que el lenguaje y sus creadores hayan defendido sin excusas la simplicidad y la responsabilidad. Te deseo suerte y buenos resultados en todo lo que venga.

    • De nada. Y gracias también por este comentario.
      Cuando empezamos Go, nunca imaginé que tendría un impacto tan positivo en la vida de la gente ni que atraería a nuevas personas a la programación y la ingeniería de software. Ese impacto es lo que más me enorgullece.

  • El blog de RSC es muy bueno: https://research.swtch.com/

    • Recién ahora me doy cuenta de que rsc puede ser un acrónimo de ese blog.
    • Es un blog tremendo. Ya lo dije antes en este sitio, pero su serie sobre expresiones regulares tiene una calidad absurdamente alta, y que simplemente la haya publicado para que todos puedan verla es un gran privilegio.

  • Gracias por todas las contribuciones a Go.
    Sin embargo, no estoy de acuerdo con una cosa que no tiene que ver con Go. Python no se benefició después de que GvR se retiró. El nuevo “liderazgo” es no técnico y autoritario, e hizo que la mayoría de los verdaderos contribuidores open source se fueran.
    El desarrollo está estancado salvo por algunas contribuciones corporativas de calidad dudosa, el ambiente es opresivo, y lo único importante es si estás en una posición de poder en Microsoft/Instagram/Bloomberg. Puede que no sea necesariamente culpa de estas empresas. Quizá no sepan que se está abusando de su generosidad.

  • Solo gofmt probablemente ahorró una cantidad enorme de tiempo en todo el mundo. En la práctica, fue lo que hizo que casi todos los demás ecosistemas de lenguajes dijeran “bueno, simplemente hagamos formateo automático”.
    No me gusta lo que los formateadores automáticos le hacen a mi código, pero sí me gusta no tener que hablar más sobre espacios en blanco.

    • Curiosamente, en todos los demás lenguajes detesto los formateadores automáticos y uso espacios en lugar de tabs, pero en Go me acostumbré desde el principio a la forma en que gofmt formatea el código.
      Después uno termina agradeciendo no tener que dedicarle mucho más tiempo, y al menos para la mayoría no es un problema.

  • Hoy me enteré del proyecto en el que quiere enfocarse: https://go.googlesource.com/oscar/+/refs/heads/master/README...
    Dice que es una arquitectura basada en LLM para ayudar al mantenimiento de proyectos open source. Se ve genial.

  • https://www.youtube.com/watch?v=wwoWei-GAPo — el proyecto avanzó muchísimo desde entonces.
    Me alegra que siga vivo y prosperando. Creo que en 2009 no esperaba que llegara a esto. Sin Russ, no creo que Go hubiera llegado a donde está hoy. Sus contribuciones al proyecto fueron enormes.

  • Gracias a Russ. Poner el soporte de herramientas como elemento de primera clase fue revolucionario, y sigue siendo una de las características más destacadas de Go.