Russ Cox, Go teknik liderliği görevinden ayrılıyor

 (groups.google.com)
1 puan yazan GN⁺ 2024-08-02 | 1 yorum | WhatsApp'ta paylaş
  • Go projesi, 12 yılı aşkın süredir Russ Cox merkezli liderlikten Austin Clements ve Cherry Mui merkezli yeni bir yapıya geçiyor
  • 1 Eylül 2024’ten itibaren Austin, Google Go ekibinin ve tüm Go projesinin teknik liderliğini üstlenecek; Cherry ise derleyici, runtime ve sürümleri kapsayan Go core’a liderlik edecek
  • Cox, uzun süreli tekil liderliğin istikrar sağladığını ancak yeni liderlerin gelişebileceği alanı daraltabileceğini düşünüyor; Python’ın 2018’deki liderlik geçişini olumlu bir emsal olarak görüyor
  • Cox, Go’dan ayrılmıyor; tasarım tartışmaları, CL incelemeleri, issue açma, bazı standart kütüphane çalışmaları ve GoLab sunumu gibi konularda bireysel katkıcı olarak kalacak
  • Bundan sonra Gaby ve Oscar’a daha fazla odaklanarak Go issue tracker verimliliğini artırmayı ve açık kaynak bakımcılarına yardımcı olan yaklaşımları diğer projelere yaymayı hedefliyor

Go liderlik geçişi

  • 1 Eylül 2024’ten itibaren Austin Clements, Go’nun teknik liderliğini üstlenecek
    • Bu hem Google’ın Go ekibini hem de tüm Go projesini kapsıyor
    • Austin şu anda “Go core” olarak adlandırılan alanın teknik lideri
  • Cherry Mui, Go core alanını yöneten role yükseliyor
    • Go core; derleyici toolchain’i, runtime’ı ve sürümleri kapsıyor
  • Russ Cox, Go projesinden ayrılmıyor ancak karar alma merkezinden bir adım geri çekiliyor

12 yıllık liderliğin ardından değişimin gerekli olma nedeni

  • Cox’a göre teknik liderlik onursal bir görevden çok hizmet rolüne yakın
    • 12 yılı aşkın süredir Go projesine liderlik ederken, ekip üyelerinin iyi işler çıkarabileceği koşulları oluşturmaya odaklandı
  • Büyük projeler istikrarlı liderlikten fayda sağlar; ancak bir noktada yeni liderlerin güçlü yanlarına ve taze bakış açılarına da ihtiyaç duyar
  • Cox, Go’nun 12 yılı aşan tekil liderlik dönemiyle yeterli istikrar biriktirdiğine karar verdi
  • BDFL modelinin hem birey hem de proje için sağlıklı olmadığını düşünüyor
    • Yeni liderlere alan açmayı zorlaştırıyor
    • Tekil hata noktası oluşturuyor
    • Projenin daha fazla büyüme olanağını azaltıyor
  • Python, Guido van Rossum’un 2018’de geri çekilip başkalarının liderlik etmesine imkân tanımasıyla büyük fayda sağlayan bir örnek olarak anılıyor

Austin Clements ve Cherry Mui’ye duyulan güven

  • Austin 2014’ten, Cherry ise 2016’dan beri Google’da Go üzerinde çalışıyor
  • Cox, ikisinin de muhakeme gücünün ve Go ile Go’nun çalıştığı sistemlere dair bilgisinin çok güçlü olduğunu değerlendiriyor
  • Genel tasarım sorularında ya da derleyici, linker ve runtime ayrıntılarını daha derin anlaması gerektiğinde Austin ve Cherry’ye güvendi
  • Mevcut liderler de kendi alanlarını yönetmeye devam edecek
    • Roland Shoemaker Go güvenliğine liderlik etmeyi sürdürecek
    • Rob Findley ve Hana Kim Go araçlarına ve IDE desteğine liderlik etmeyi sürdürecek

Russ Cox’un bundan sonraki rolü

  • Cox, Austin ve diğer liderlere öne çıkabilecekleri alan yaratmak için karar alma süreçlerinden bilinçli olarak geri çekilecek
  • Go içinde bireysel katkıcı olarak kalmaya devam edecek
    • Go tasarım tartışmalarına katılım
    • CL incelemeleri
    • Eski geçmişe ilişkin soruları yanıtlama
    • Gerektiğinde destek verme
    • Issue açma ve CL yazma
    • Bazı potansiyel yeni standart kütüphane çalışmaları
    • Sektör genelinde Go’yu savunma
    • Kasım ayında İtalya’daki GoLab’de Go ile ilgili sunum
  • Geçişin ayrıntıları henüz belirlenmedi ve açık tartışma için posta listesinde paylaşıldı
  • Cox ve Austin, bu değişimin Go projesini daha güçlü ve daha iyi hale getirmesi dışında büyük bir olay gibi görünmemesini istiyor

Odağın Gaby ve Oscar’a kayması

  • Cox bundan sonra Gaby and Oscar’a daha fazla odaklanacak
  • Amaç, Go issue tracker’da faydalı katkılar üreterek Go üzerinde çalışanların daha verimli çalışmasına yardımcı olmak
  • Oscar çalışmasıyla açık kaynak bakımcılarına yardımcı olacak yollar bulmayı ve bunların başka projelerde de benimsenmesini umuyor
  • Oscar’ın üst düzey hedefleri üç tane
    • Faydalı bir şey yapmak
    • Yeni bir şey öğrenmek
    • Diğer projeler için bir yol çizmek
  • Bu hedefler, Go’da her zaman izlenen daha geniş hedeflerle bağlantılı olduğu için Oscar, Cox açısından doğal bir sonraki adım gibi görünüyor

Topluluk tepkileri ve şeffaflık talebi

  • Daniel Martí, son 10 yıldaki Go’nun büyük değişimleri ve dönüm noktaları olarak modules ve generics’i göstererek Cox’un uzun vadeli başarıda kilit rol oynadığını değerlendirdi
  • Geçiş tartışmalarıyla birlikte derleyici ve runtime tarafında şeffaflığı artıracak yollar önerdi
  • Cherry Mui, toplantı notları ve office hours’ın Google’ın derleyici/runtime ekibi ile topluluk arasında şeffaflığı ve katılımı artırmak için iyi bir fırsat olduğunu söyledi
    • Bir sonraki office hours takvimi belirlendiğinde posta listesine güncelleme koyacak
  • Birçok katılımcı, Cox’un 12 yıllık liderliği ve Go’ya katkıları için teşekkür etti; Austin ve Cherry’nin yeni rollerini kutladı

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-02
Hacker News yorumları

  • rsc, bugüne kadarki tüm çalışmaların için teşekkürler. Son 12 yılda Go ile geliştirme; yarış durumu algılayıcısı, standartlaştırılmış hata sarmalama, modüller, generics, araç zinciri güncellemeleri gibi yeniliklerle çok daha keyifli hale geldi.
    Hâlâ istediğim şeyler var. Kişisel olarak sum type’lar, daha iyi enum/aralık tipleri, değişmezlik ve nil olamazlık istek listemde; ama yine de Go, şimdiye kadar geliştirme yaptığım ekosistemler arasında en keyiflilerden biri

    • RSC’nin en büyük teknik katkısı olarak modül sürüm yönetimini göstermek isterim. Bir dil ekosistemi için mutlak anlamda temel bir unsur.
      https://research.swtch.com/vgo-intro
    • non-nilnessi görünce hâlâ şu thread’i hatırlıyorum
      https://groups.google.com/g/golang-nuts/c/rvGTZSFU8sY/m/R7El...
    • Son yıllarda Go’yu daha iyi bir dil yapan unsurların iyi derlenmiş bir listesi. Buna Russ’ın son dönemde güçlü biçimde öne ittiği iteratorları da eklemek isterim
    • Go en baştan nullable type’lara veya sum type’lara sahip olsaydı çok daha popüler olurdu diye düşünüyorum
    • Geleneksel 3 parçalı for döngüsünün anlam değişikliğini de unutmamak gerek: https://go101.org/blog/2024-03-01-for-loop-semantic-changes-...
      Bu değişiklik yüzünden Go 1.22’nin, Go resmi olarak kabul etmese de, gerçekte Go 1 uyumluluğunu ciddi biçimde bozan ilk Go sürümü olduğunu düşünüyorum

  • Kişisel olarak Go’nun şimdiye kadarki en iyi yönetilen açık kaynak projelerinden biri olduğunu düşünüyorum. Bunu destekleyen Google’ı da takdir ediyorum

    • İyi yönetilen bir proje sayılmasını sağlayan unsurların neler olduğunu merak ediyorum
    • Pratikte Go’nun “sahipliği” kimde, merak ediyorum.
      Teoride bağımsız bir kuruluş ya da komite gibi bir şey olabilir, ama işi fiilen yapan insanların çoğunun maliyetini kim karşılıyor, merak ediyorum. Google mı?
    • Go’nun C++ veya Java’nın yerini alma görevinde başarısız olup API tarafında Ruby/Python vb. yerine geçen bir dile dönüşmesinin yan etkisi gibi.
      Böylece proje hedefi artık dünyayı fethetmek değil, kullanıcılarla uyumlu hale geldi; o savaşı da Rust, Zig gibi diller almış oldu
    • Sadece glibc davranışını destekleyip ELF standardını keyfine göre yok saymak gerçekten “en iyi yönetilen” proje olmanın şartıdır herhalde. /s

  • “BDFL (ömür boyu iyiliksever diktatör) modelinin insanlar veya projeler için sağlıklı olduğuna inanmıyorum” kısmı ilginç. En iyi projelerde BDFL var ve en iyi BDFL’ler kendi güçlerine şüpheyle yaklaşıyor gibi görünüyor

    • Liderliğe ilgi duymayan yetkin insanlar çoğu zaman en iyi liderler oluyor gibi görünüyor.
      Tersine, “lider” olarak bilinmek istedikleri için lider olmaya çalışan kişilerde bazen ne yetkinlik ne de sorumluluk duygusu oluyor
    • Ön kısmın tamamına katılıp katılmadığım ayrı, ama en iyi BDFL’lerin kendi güçlerine şüpheyle yaklaşması pek şaşırtıcı değil.
      Tek bir kişinin tek taraflı karar verebilme yetkisinin başlıca avantajı, çok sayıda paydaş olduğunda ortaya çıkan kilitlenmeyi aşabilmek bence. Eğer bir projede liderin, güçlü bir mutabakat bulunan kararları meşru şekilde tersine çevirebileceği düşünülüyorsa, insanların tanıyacağı kadar bir topluluk oluşması çok daha zor olur
    • Bunun doğru olduğunu düşünmüyorum. Python’da BDFL vardı ama bundan büyük fayda gördüğünü sanmıyorum. Bu tutumun başka hangi projelerden çıktığını da pek bilmiyorum.
      Kabaca bakınca, dramayı azaltan ama kaliteyi gözle görülür biçimde artırmayan, başka bürokrasilere benzer bir yapı gibi görünüyor. Öte yandan tek sahibinin yeterince esnek olmaması yüzünden başarısız olan yığınla proje var; ama bunlar tartışmaya değer görülmüyor
    • Güce sahip olmayı hak eden tek kişi, gücü istemeyen kişidir.
      Bu, açık kaynak projelerinin çok ötesine geçen bir mesele
    • BDFL fikrinin kendisi bir şaka; adı da bunu gösteriyor.
      GvR’nin Python’un yaratıcısı olarak sahip olduğu “sahadaki gerçeği” kabul eden bir ifadeydi; proje yönetim ilkesi olarak ciddi biçimde amaçlanmış değildi. Reçete değil, betimlemeydi; ama kavram fazlasıyla somutlaştırıldı

  • rsc, beni yazılım mühendisliğine çeken bu dile verdiğin tüm emek için gerçekten teşekkür ederim.
    Birçok programlama diliyle uğraştım ama Go hâlâ ev gibi hissettiriyor. Geliştirme deneyimi harika; dilin ve yaratıcılarının sadelik ile sorumluluk duygusunu mazeretsiz biçimde korumasını gerçekten çok takdir ediyorum. Bundan sonraki her şeyde bol şans ve iyi sonuçlar dilerim

    • Rica ederim. Bu yorum için de teşekkürler.
      Go’ya başladığımızda, Go’nun insanların hayatlarında bu kadar olumlu etki yaratacağını ve yeni insanları programlamaya ve yazılım mühendisliğine çekeceğini hiç beklemiyorduk. En çok gurur duyduğum şey de bu etki

  • RSC’nin blogu gerçekten harika: https://research.swtch.com/

    • rsc’nin o blogun akronimi olabileceğini şimdi fark ettim
    • Muazzam bir blog. Daha önce de bu sitede söylemiştim; onun düzenli ifade serisi inanılmaz derecede kaliteli ve bunu herkesin görebilmesi için öylece yayımlamış olması büyük bir nimet

  • Go’ya tüm katkıların için teşekkürler.
    Ancak Go ile ilgisi olmayan bir konuda katılmıyorum. Python, GvR çekildikten sonra bundan fayda görmedi. Yeni “liderlik” teknik olmayan, baskıcı bir yapıda ve gerçek açık kaynak katkıcılarının çoğunu uzaklaştırdı.
    Geliştirme, kalitesi tartışmalı bazı kurumsal katkılar dışında durdu; atmosfer baskıcı ve önemli olan tek şey Microsoft/Instagram/Bloomberg’de güçlü bir pozisyonda olup olmadığınız. Bu şirketlerin suçu olmak zorunda değil. Cömertliklerinin suistimal edildiğini bilmiyor olabilirler

  • Sırf gofmt bile dünya çapında muazzam zaman kazandırmış olmalı. Fiilen diğer tüm dil ekosistemlerinin “tamam, sadece otomatik biçimlendirelim” demesini sağlayan üst akımda duruyor.
    Otomatik biçimlendiricinin koduma yaptığı şeylerden hoşlanmıyorum, ama artık boşluklar hakkında konuşmak zorunda olmamak güzel

    • İlginç biçimde, diğer tüm dillerde otomatik biçimlendiricilerden hoşlanmıyor ve tab yerine boşluk kullanıyorum; ama Go’da en başından beri gofmtin kodu biçimlendirme şekline alıştım.
      Sonra buna artık çok zaman harcamak zorunda kalmadığınıza minnettar oluyorsunuz ve en azından çoğu kişi için sorun olmuyor

  • Bugün onun odaklanmak istediği projeyi öğrendim: https://go.googlesource.com/oscar/+/refs/heads/master/README...
    Açık kaynak projelerinin bakımına yardımcı olan LLM tabanlı bir mimari olduğu söyleniyor. Harika görünüyor

  • https://www.youtube.com/watch?v=wwoWei-GAPo — proje o zamandan bu yana gerçekten çok yol kat etti.
    Hâlâ yaşıyor ve gelişiyor olmasına sevindim. 2009’da bunun böyle olacağını beklemiyordum sanırım. Russ olmadan Go’nun bugünkü konumuna gelemeyeceğini düşünüyorum. Projeye katkıları muazzamdı

  • Russ’a teşekkürler. Araç desteğini birinci sınıf bir unsur yapmak devrim niteliğindeydi ve hâlâ Go’nun en ayırt edici özelliklerinden biri