Git: Rust’un Benimsenmesi ve Derleme Sisteminde Zorunlu Hale Getirilmesi Duyuruldu

 (lore.kernel.org)
15 puan yazan GN⁺ 2025-09-21 | 1 yorum | WhatsApp'ta paylaş
  • Git projesi, bundan sonra Rust’u çekirdeğe dahil edeceğini ve Git 3.0’dan itibaren Rust’un derleme için zorunlu bir gereksinim olacağını resmen duyurdu
  • Bu yama serisi, geçmişte C99 özelliklerinin benimsenmesinde olduğu gibi deneysel bir adım (test balloon) niteliğinde ilerliyor; amaç Rust benimseme altyapısını kademeli olarak hazırlamak
  • İlk adım olarak, neredeyse hiç bağımlılığı olmayan varint.c modülü Rust’a dönüştürülerek C-Rust birlikte çalışabilirliği ve derleme araçları doğrulanıyor
  • Şu anda yalnızca Meson derlemesi destekleniyor; ileride Makefile desteği ile CI’da Rust derleme doğrulaması ve cargo format tabanlı biçim tutarlılığı denetimi eklenmesi planlanıyor
  • Bu, Git topluluğuna ve dağıtımcılara yeni Rust toolchain gereksinimlerine uyum sağlamak için zaman verirken, uzun vadede kod güvenliğini ve genişletilebilirliği artıracak önemli bir değişim

Rust benimsenmesinin arka planı

  • Git, kararlılık ve sürdürülebilir bakım için dil düzeyinde evrimi değerlendiriyordu
  • Rust’un benimsenmesi, bellek güvenliğinin güçlendirilmesi, modern toolchain’lerden yararlanılması ve performans optimizasyonu olasılığının kazanılması anlamına geliyor
  • Ayrıca modern bir dil benimseyerek daha sağlam bir kod tabanı oluşturulmak isteniyor
  • Git 3.0 sürümüyle birlikte Rust’un zorunlu hale geleceği önceden duyurularak ekosistemin hazırlanması için zaman kazanılması amaçlanıyor
  • Rust kodunun uygulama kapsamı aşamalı olarak genişletilecek ve nihayetinde bazı çekirdek işlevlerin de Rust ile yeniden uygulanması planlanıyor

Deneysel yama serisi

  • Rust’un ilk uygulandığı modül olarak varint.c seçildi
    • Oldukça basit ve bağımlılığı yok
    • C ↔ Rust interop doğrulaması mümkün
    • Git’in genel işlevselliğini etkilemeden deney yapılabiliyor
  • Tüm testler varint.rs sürümünde başarıyla geçti

Derleme sistemi değişiklikleri

  • Şu anda Rust desteği yalnızca Meson derleme sistemine eklendi
  • Gelecekte Makefile’a da Rust desteği eklenmesi planlanıyor
  • CI ile ilgili çalışmaların da hazırlanması gerekiyor
    • Rust derlemesinin ve çalışmasının doğrulanması
    • cargo format ile kod stili tutarlılığının sağlanması
    • Diğer araçlar ve bakım otomasyonları

Gelecek planları

  • Bu çalışmada odak noktası, Rust özelliklerinin kendisinden çok benimseme sürecinin denenmesi
  • Sonrasında xdiff modülü dahil Git’in daha fazla iç işlevi Rust ile yeniden yazılabilir
  • Rust kademeli olarak daha geniş alanda uygulanırken, tüm ekosistemin Rust tabanlı derleme ortamına uyum sağlaması teşvik edilecek

Çıkarımlar

  • Git, tarihindeki en önemli dilsel dönüşümlerden birine hazırlanıyor
  • Rust’un zorunlu hale gelmesiyle güvenlik, bakım kolaylığı ve uzun vadeli gelişim potansiyeli güvence altına alınabilir
  • Dağıtımcılar ve geliştiriciler için gelecekte Git ekosisteminde Rust geliştirme ortamı kurmak zorunlu hale gelecek

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-21
Hacker News görüşleri
  • Başka bir başlıkta Rust’ın zorunlu olarak benimsenmesine dair tartışma hakkında, yazar Rust’ı hemen zorunlu kılmak yerine önce isteğe bağlı bir bağımlılık olarak ekleyip, daha sonra gcc’ye Rust desteği geldiğinde zorunlu hale getirmenin daha iyi olacağını söylüyor
    İlgili tartışma bağlantısı
    • gcc derleyicisinin tutarsız olduğuna vurgu yapıyor; örneğin gcj (Java için gcc) neredeyse hiç kimse tarafından kullanılmıyor
      Rust desteğinin de standartları oturmamış bir dil olduğu için zamanla uygulamasının çok geride kalabileceğinden (eskiden Java’da olduğu gibi) şüphe ediyor
  • Git’e neden Rust eklenmek istendiğini merak ediyor
    Git zaten oldukça olgun bir araç gibi görünüyor ve yeni bir dil eklemeyi gerektirecek kadar büyük ölçekli yeni koddan ziyade bakım ve iyileştirme ihtiyacı varmış gibi duruyor
    Linux’ta olduğu gibi sürekli yeni sürücülere ihtiyaç duyulan bir durumun aksine, Git’te bunu gerektirecek bir neden görmüyor
    Kaçırdığı bir şey varsa bunu açıklayabilecek birini istiyor
    • Git çok görünür olmasa da sürekli yeni özellikler kazanıyor
      Git’teki değişiklikler RelNotes’ta görülebilir ya da daha anlaşılır bir özet için GitHub blogundaki Git kategorisine bakılabilir
    • jj veya git-branchless gibi araçları kullanırsanız git’in tamamlanmış olduğu fikriniz değişebilir
      Örneğin git-branchless, Rust ile yazılmış bellek içi birleştirme gibi özellikler içeriyor
    • Bu yazıda çok sayıda yanıt var, bakmaya değer
      Rust ile ilgili daha fazla içerik o e-posta listesinde bulunabilir
      (Bunun lehine ya da aleyhine bir değerlendirme yapmıyor, birilerinin bunu yapacağını söylüyor)
    • Eski C projelerine yeni geliştirici akışı giderek azalıyor
      Git’i C ile geliştirmek isteyen neredeyse kimse yokken, Rust ile yeniden yazıma ilgi duyan geliştiriciler katılmaya hevesli
    • C güvenli değil
  • Rust’ın neden sürekli farklı yerlere sokulmak istendiğini sorguluyor
    Git oldukça olgun görünüyor, dolayısıyla büyük miktarda yeni kodun eklenmesi de pek olası değil
    Rust, C’ye kıyasla çok daha karmaşık
    Gerçekten nesne yönelimli özellikler gerekiyorsa yalnızca C++98 kullanmak bile modern C++ ya da Rust’tan çok daha basit ve anlaşılır olurdu
  • Başlığın biraz yanıltıcı ifade edildiğini söylüyor
    Rust gelecekteki yamalar için değil, derleme sistemi içinde zorunlu olacak
    • Teşekkür ederek başlığın buna göre güncellendiğini söylüyor
      Eğer yanlışsa tekrar düzeltilebileceğini ekliyor
    • Bunun ne anlama geldiğini soran bir takip yorumu geliyor
      Derleme sisteminin kendisini derlemek için mi gerekli olduğu, yoksa uygulamayı derlemek için de zorunlu olup olmadığı merak ediliyor
  • Biraz yaşlandığını ve değişimi kabul etmesi gereken bir noktada olduğunu düşünse de, eskiden yalnızca C bilerek Git ya da çekirdek geliştirmeye katkı verilebilirken artık buna Rust’ın da eklenmesi ve araç zincirinin giderek karmaşıklaşmasının giriş eşiğini yükselttiğinden yakınıyor
    Git’e çok emek verdiğini ve çeşitli projeler yaptığını, Git’in hacklenebilirliğini kaybetmek istemediğini söylüyor
    • Yeni şeyler öğrenmek istemeyen bir tutumun bu sektör için uygun olmadığını düşünüyor
      Hatta Rust’ın genel C’den (özellikle hataya açık C’den) öğrenmesi daha kolay olduğunu, Git ya da Linux kaynak kodunu öğrenmekten ise kesinlikle daha kolay olduğunu söylüyor
    • Git istemcisi ve web sunucusunu kendiniz yazsanız bile Git depo formatı değişmeyeceği için hacklenebilirlik etkilenmez
    • Ayrıca Git’in zaten birden fazla dilden oluştuğunu hatırlatıyor
      GitHub verisine göre C %50, Shell %38, Perl %4, kalanı ise TCL/Python vb.
      Perl/TCL aslında daha da istisnai kalıyor
      Proje büyürken sağa sola eklenmiş çok sayıda hack kod birikti ve artık güvenlik/performans iyileştirmeleriyle birlikte eski hack kodları temizleme zamanı geldi
      Rust’ın buna uygun olduğunu düşünüyor
    • Bir yazılım mühendisi için birden çok dili rahatça kullanabilmenin normal olduğunu, dolayısıyla yeni bir dil eklenmesinin büyük bir sorun olmadığını belirtiyor
    • Kendisi dahil birçok genç geliştiricinin Rust’ı tercih ettiğini ve C öğrenmek istemediğini söylüyor
      Git’in kısmen Rust kullanmasının, kendi yazdığı Git istemcisi ya da sunucusunu geliştirmesini engellemeyeceğini düşünüyor
  • Rust’ın bazı platformlarda kullanılamadığı ve başka yerlerde de zor olduğuna dair görüşe ek açıklama isteniyor
    • Linux sistemlerinde her kütüphanenin sistem kütüphanesi olarak kullanılabilmesi gerekir, ancak Rust’ın kararlı bir ABI’si olmadığı için gerçek bir paylaşımlı kütüphane olarak kullanılamıyor
      Debian sürüm notlarında da Rust/Go paketleriyle ilgili sorunlar açıkça belirtiliyor
      Rust paketleri derlenirken statik bağlama sorunları yüzünden sık sık yeniden derleme gerekebiliyor; bu da pratik kullanımda rahatsızlık yaratıyor
      Linux işletim sistemlerinde gerekli olan kararlı ABI/paylaşımlı kütüphane sorununu Rust tarafı görmezden gelirse, C’den daha fazla şikâyet üretebilir
      Büyük yazılım mimarilerinde daha dikkatli olunması gerektiğini düşünüyor
    • Görünmeyen bazı özel platformlar kendi C derleyicilerini destekliyor ama LLVM desteği mümkün değil
      Örnekler için bu yazıda NonStop anahtar sözcüğünü aratmayı öneriyor
    • Bunun nedeni Rust derleyicisinin bazı platformları (OS/mimari birleşimleri) desteklememesi
      RESF gibi yerlerde “platform Rust’ı desteklemiyor” deniyor ama gerçekte çalışabilmesi için Rust derleyicisinin destek vermesi gerekiyor
    • Rust LLVM tabanlı olduğu için GCC’nin desteklediği platformlardan daha sınırlı
    • Rust’ın resmi belgelerindeki platform destek listesinde 'Tier 3' bölümüne bakılması öneriliyor
  • git 3.0’da ne gibi değişiklikler olacağını merak ediyor
    git 2.x artık oturmuş göründüğü için uyumluluğu kıracak bir neden yokmuş gibi geliyor
    • Buna yanıt olarak git 3.0 Breaking Changes belgesine bakılması öneriliyor
    • Varsayılan hash işlevi SHA-256’ya geçecek
  • Geçmişte çapraz derleme ortamlarında derleme, çalıştırma ve kod düzenlemenin birbirinden farklı olduğu durumun temel varsayım olduğunu söylüyor
    Son dönem geliştirme kültürünün bu tür araç zinciri kullanımından uzaklaşıp uzaklaşmadığını sorguluyor
    Kaynak kontrolü, derleme ve çalışma ortamları farklıydı; uzak kopyalama ya da uzaktan çalıştırma gerekiyordu ve derleme kurallarında hedef platform tespiti şarttı
    • Buna karşılık Rust araç zincirinin, derlenen diller arasında çapraz derlemeyi en kolay yapanlardan biri olduğu söyleniyor
      Tek bir --target bayrağıyla yaklaşık 100 platform için ciddi bir sorun yaşamadan derleme yapılabildiği belirtiliyor
      Asıl sorunun bazı Git geliştiricilerinin eski/sabit geliştirme makinelerine bağlı kalması olduğu düşünülüyor
    • Çoğu geliştiricinin gerçekte çapraz derlemeyi hiç düzgün öğrenmediği düşünülüyor
      Çapraz derleme her zaman ikinci sınıf vatandaş muamelesi görüyor ve harici projelerde düzgün çalışması zaten beklenmiyor
      Bazı Linux dağıtımları Raspberry Pi gibi sistemlerde yalnızca gerçek donanım üzerinde derlemeyi tercih ediyor
      Bu yüzden kimse bunu doğru dürüst desteklemek için çaba harcamıyor
    • Rust ile ilgisi olsun ya da olmasın, günümüzde çapraz derlemenin durumu neredeyse “felaket” olarak görülüyor
      Özellikle Linux tarafı kötü durumda; glibc yapısı eskidiği için herhangi bir donanımda en düşük ortak glibc hedefini tutturmak zorlaştı
      Çoğu proje çapraz derleme desteğini denemeye bile kalkmıyor
      Zig bunu iyileştirmeye çalışıyor
  • gcc ile ilgili Rust ön yüzü yeterince olgunlaşana kadar benimsemenin ertelenmesi gerektiğini savunuyor
    Git proje ekosisteminin çekirdek araçlarından biri olduğu için, değişimin riskli olduğunu ve 6 ay gibi kısa bir sürede zorunlu bağımlılık yapılmasının tehlikeli olacağını düşünüyor
  • Rust’ın işlevsel dillere benzer biçimde zor bir öğrenme eğrisi ve yüksek karmaşıklık getirdiğini söylüyor
    Bu karmaşıklık derleme zamanında daha fazla hatayı yakalama amacı taşısa da, sonuç olarak dilin kendisini oldukça karmaşık hale getiriyor
    Bu yüzden benimsenmesini önermiyor
    Çekirdeğin de benzer şekilde Rust’ı reddettiğini sandığını ekliyor
    Zaten karmaşık olan çekirdeğe Haskell düzeyinde bir tip sistemi ve Lisp seviyesinde bir makro sistemi eklenirse karmaşıklığın daha da artacağını düşünüyor
    serde üzerinden Rust kodunu takip etmenin zor olduğunu söylüyor
    Buna karşılık Go’daki Unmarshal’ın takibinin çok daha kolay olduğunu belirtiyor
    • Buna karşılık bir başkası, işlevsel dillerin ve Rust’ın C ya da Go’dan daha açık olduğunu düşündüğünü söylüyor
      Çünkü derleyiciye daha fazla bilgi yüklenebiliyor
      Serde ile büyük bir sorun yaşamadığını, hatta Go’daki Unmarshal’ı daha sık debug ettiğini belirtiyor
      Çekirdeğin Rust’ı reddettiği iddiasının da aslında iki geliştirici arasında header’ların nereye konacağına dair bir anlaşmazlık olduğunu söylüyor
    • C basit olabilir ama güvenli ve yüksek performanslı C son derece karmaşıktır
      Rust’ın giriş eşiği C’den daha yüksek olsa da, “asgari Rust” ile “hızlı ve güvenli Rust” arasındaki fark, C’de olduğundan çok daha küçüktür
    • Rust’ın karmaşık olduğu söyleniyor ama C’nin de azımsanmayacak derecede karmaşık olduğu vurgulanıyor
    • Derleme zamanındaki bu denetim kolaylığı, Rust’ı farklı kılan şey olarak görülüyor
      borrow checker kadar önemli bulunuyor
    • Typescript deneyimi olan ve bir linter ile referanslar ya da Result açma/hata işleme gibi konulara alışkın kişiler için Rust’ın oldukça öğrenilebilir olduğu söyleniyor
      Sözdizimi de hoşgörülü bulunuyor
      Linux çekirdeği gerçekte Rust’ı reddetmiş değil