Ubuntu'nun Rust kullanması ne anlama geliyor?

• Ubuntu'nun Rust benimsemesi, teknoloji benimseme döngüsünde Rust'ın erken benimseyenlerden uçurumu aşıp ana akım aşamaya geçtiğini gösteriyor
• Canonical, Rust'ı yeni temel yazılımlar için varsayılan dil olarak benimseyerek C, C++ ve kısmen Python kullanımının yerini alıyor; ayrıca bellek güvenli yardımcı araç geliştirmeye hem finansal hem de itibari açıdan yatırım yapıyor
• Erken çoğunluk kullanıcıları "endüstri standardı"nı ve mevcut iş akışlarıyla uyumluluğu istediği için, drop-in tarzı yardımcı araç değişimleri uçurumu aşmanın temel stratejisi haline geliyor
• Rust'ın standart kütüphaneyi genişletme sorunu yeniden gündeme geldi; 2016'da reddedilen "Rust Platform" kavramının erken çoğunluk için aslında daha uygun olabileceği yeniden değerlendiriliyor
• Benimsemenin yatırıma dönüşmesini sağlayan yapı ile açık kaynak topluluğunun empati temelli kapsayıcılığı, Rust'ın bir sonraki büyüme aşaması için kritik

---

Rust için 'uçurumu aşmak' alana göre değişiyor

• Rust'ın Technology Adoption Life Cycle içinde uçurumu aşıp aşmadığı, alana göre değişiyor
• Amazon içinde Rust, büyük ölçekli data plane ya da kaynak farkındalıklı ajanlar geliştirmede sağlam biçimde yer edinmiş olsa da, genel geliştirme için hâlâ fazla ağır görülebiliyor
• Safety Critical Software alanında başarı örnekleri var, ancak sektörün büyük kısmı hâlâ "bekle-gör" modunda

"Referans müşteriler"in önemi

• Uçurumu aşmanın anahtarı, referans müşteriler (reference customers) kazanmak
• Erken benimseyenler "değişim aktörü (change agent)"nü satın alır; buna karşılık erken çoğunluk mevcut operasyonların verimliliğini artırmak ister ve süreksizliği en aza indirmeye çalışır
• Kendilerine benzer bir organizasyonun başarıya ulaştığını görmek, yeni bir teknolojiyi benimsetmede en ikna edici unsurdur
• Örneğin S3 ekibinin Rust başarısı büyük hizmet ekipleri için ikna edici olabilirken, CRUD hizmet ekipleri için doğrudan aynı etkiyi yaratmıyor

Ubuntu (Canonical) için Rust benimseme stratejisi

• Rust Nation'da Canonical Mühendislikten Sorumlu Başkan Yardımcısı Jon Seager, "Rust Adoption At Scale with Ubuntu" başlıklı bir keynote sundu
• Canonical şimdiye kadar iç geliştirmede Python, C/C++ ve Go ile sınırlıyken, yakın zamanda Rust'ı da ekleyerek onu yeni temel işler için varsayılan dil olarak benimsedi
• Bu yaklaşım, Lars Bergstrom'un Google içinde Rust benimsenmesine dair keynote'una benzer biçimde, vizyon ile pratikliği aynı anda taşıyor
  • Bu da erken benimseyenlerden erken çoğunluğa geçiş için gereken tam özellik

Bellek güvenli yardımcı araçlara yatırım

• Jon Seager, Ubuntu'nun bellek güvenliği odaklı yardımcı araçların geliştirilmesini "pay it forward" anlayışıyla desteklemesi gerektiğini söyledi
• Canonical, Trifecta Tech Foundation tarafından geliştirilen sudo-rs ve ntpd-rs ile uutils içindeki coreutils çalışmalarına finansal destek sağlıyor
• Yapı şu şekilde işliyor: Ubuntu önce yeni şeyleri deneyip doğruluyor, ardından diğer dağıtımlar da bundan faydalanabiliyor
• Mevcut iş akışlarına doğrudan oturan drop-in yardımcı araçlar, erken çoğunluğun "süreksizliği en aza indirme" beklentisine uyuyor

Yeni benimseyenlerin talebi: standart kütüphanenin genişletilmesi

• Bir akşam yemeğinde Jon Seager, Rust'ın küçük standart kütüphane politikasının yeniden gözden geçirilmesi gerektiğini söyledi
• Bu, yıllardır tekrar edilen bir talep ve mesele yalnızca daha büyük bir standart kütüphane sunmak değil; bunun yerine "Battery Packs" adlı proje biçiminde bir alternatif düşünülüyor
• 2016'da önerilen Rust Platform (belirli crate'leri genişletilmiş standart kütüphane olarak tanıma fikri), o dönemde erken benimseyenler tarafından reddedilmişti; ancak erken çoğunluk için uygun olabilir diye yeniden değerlendiriliyor
  • O dönemde baskın görüş, Cargo.toml içine bağımlılık eklemenin yeterli olduğu yönündeydi

Büyümek için değişim ihtiyacı

• Erken benimseyenlerden erken çoğunluğa geçmek için, "en ileri seviye (state-of-the-art)" değil "endüstri standardı (industry standard)" mesajı gerekiyor
• Rust, sektörde bilinirlik kazanmayı başardı; şimdi ölçüt, "olabilecek şey" değil "gerçekte ne olduğu" üzerinden en iyi seçenek haline gelmesi olmalı
  • Bu ikisi zaman zaman gerilim yaratabiliyor
• Pragmatistlere pazarlama yapmak; sabır, ilgili sektör sorunlarını anlama ve sektör konferanslarına katılım gerektiriyor

Benimsemeyi yatırıma dönüştüren yapı

• Rust benimsenmesinin artması, Rust projesi ve ekosistemine yönelik talebin de artması anlamına geliyor
• Canonical gibi açık kaynak kuruluşları için $$'dan çok kurumlar arası ilişki kurmak ve katkı sunmak daha önemli
  • Örneğin Rust for Linux geliştiricileri başlangıçta Rust maintainer'larından yardım aldı, ancak zamanla hataları doğrudan kendileri düzeltmeye başladı ve maintainer'lar daha çok mentorluk rolüne geçti
• İlginç bir eğilim olarak, fonlar çoğu zaman Rust'ı zaten benimsemiş şirketlerden değil, benimsemeyi değerlendiren şirketlerden geliyor
  • Şirket içindeki erken benimseyen bireyler organizasyonel benimsemeyi ilerletirken, "table stakes" özelliklerin geliştirilmesi için bütçe ayırıyor
• Rust Foundation Silver Member Directory'den Alexandru Radovici'ye göre, birçok güvenlik açısından kritik yazılım şirketi, Rust'ın eksiklerini kapatacak bütçeye sahip ama bunu nasıl kullanacağını bilmiyor

Açık kaynağın rolü ve empatinin önemi

• Açık kaynak, uçurumu aşmak için harika bir platform; ancak klikler (cliques) ve "sözlü gelenekler (oral traditions)" giriş için engel oluşturabiliyor
• Yanlış terminoloji kullanımı yüzünden bir fikir reddedilebilir ya da tek bir kaba yanıt yeni bir katkı sağlayanı uzaklaştırabilir
• Rust'ın bir sonraki büyüme aşamasında en çok ihtiyaç duyduğu şey, açık kaynakta empati (Empathy in Open Source)
• Esas olan, Rust'ın insanlara yardımcı olabileceği yerlere gidip destek olmak ve onları güçlendirmek

[GN⁺]

Hacker News yorumları

• Ubuntu’nun GPL olmayan lisanslı bir userland kullanması, Linux ekosisteminde daha fazla TiVoization’a izin verilebileceği anlamına geliyor
  systemd tarafındaki Amutable’ın gittiği yönle birleşirse, kullanıcının değiştiremediği kapalı Linux dağıtımları ortaya çıkabilir
  Şirketler açısından tam imza doğrulaması yapılabilen kapalı bir ortam cazip olabilir. “ls” ya da “cd”nin bile kapalı kaynak olduğu bir dünya, tuhaf biçimde kıyametvari hissettiriyor

  • util-linux ya da BSD ortadan kalkmıyor. Ubuntu hoşuna gitmiyorsa kullanmazsın. Debian çok daha istikrarlıydı
  • Aslında buna GNU/Linux denmesinin bir sebebi vardı. Android/Linux da GPL userland kullanmıyor, gömülü taraftaki rakiplerin de çoğu GPL değil. Sonuçta Linux sadece çekirdektir
  • Tarihsel açıdan bakınca saf davranıyor olabilirim ama bu tür değişimlerin mutlaka kötü olduğunu düşünmüyorum. Açık kaynak araçları tercih etsem de, spesifikasyona uyan kapalı alternatiflerin var olması da bence sorun değil. Şirketler bu sayede açık kaynak projelere daha fazla kaynak aktarabilir
  • Dürüst olmak gerekirse Ubuntu, kalite yerine pazarlamayla yarışan Linux’un Apple’ı gibi. Debian türevleri düşük bakım maliyeti yüzünden kullanılıyor; ben şahsen geleceğin Fedora ya da OpenSUSE olduğunu düşünüyorum
  • Eğer bu değişim Linux kullanıcılarının %95’inin aynı işletim sistemini kullanmasına yol açarsa, o kadar da kötü olmayabilir

• Rust’ın aşması gereken asıl uçurum (chasm), güvenli ABI’ye sahip dinamik bağlama desteği
  Tek bir kütüphaneyi değiştirsen bile güvenlik garanti edilmeli ve C düzeyinde ABI kararlılığı sağlanmalı ki C/C++ tarafında Rust benimsenebilsin

  • Rust zaten C ABI ile iletişim kurabiliyor. C++ ile aynı düzeyde dinamik bağlama yetenekleri sunuyor
  • C++’ın ABI kararlılığı, dilin gelişimini engelleyen başlıca etken. STL’nin sınıf yerleşimini değiştiremiyorsun ve header içinde tanımlanan şablonları sonradan optimize etmek de zor. Rust “stable ABI” desteği vermemeli
  • Rust’ın verimliliği derleme zamanında monomorfizasyona dayanıyor. Bir ABI oluşturmak için bağlama zamanı özelleştirmesini de düşünmek gerekir. Bu sadece kod üretimini linker’a taşımak meselesi değil; fonksiyon parametrelerinin “shape”ini dikkatle ele almak gerekiyor
  • Dinamik bağlama, debug build’lerde derleme süresini kısaltma açısından da avantajlı. Değişmeyen kütüphaneleri yeniden derlemek gerekmiyor ve çalışma zamanı ek yükü de çok az
  • Rust topluluğunun GPL yerine MIT’i tercih etmesi üzücü. GPL kullanıcı dostu, MIT ise şirket dostu. “Rewrite-it-in-Rust” hareketinin kullanıcıyı korumaktan çok dilin yayılmasına odaklanması bence sorunlu

• Ubuntu’nun Rust benimsemesinden daha büyük sorun, hâlâ önemli build’leri curl|bash scriptleri ile yürütüyor olması
  firefox-snap’in snapcraft.yaml dosyasına bakınca bu açıkça görülüyor

  • “curl|bash” denince akla genelde rastgele ayar değişiklikleri ya da .bashrc oynamaları gelir, ama burada yapılan şey sadece statik toolchain kurulum scripti çalıştırmak. 90’lardan kalma bir yöntem ama görece güvenli
  • Rust sürümü çok eski kalan pek çok dağıtım var. Debian ya da Ubuntu LTS’teki Rust, çağın gerisinde kalmış sürümler olduğu için statik bağlamayı sevmiyor gibiler
  • curl ile bir şey çalıştırıyor olsan bile hash doğrulaması düzgün yapılırsa sorun olmaz

• Rust Coreutils projesinin MIT lisanslı olması beni rahatsız ediyor
  FSF’nin felsefesi eleştirilse de, GPL açık kaynağı korur. Canonical Ubuntu genelini MIT’ye çevirirse ne olacağını kestiremiyorum

  • GPL eskiden güçlüydü ama artık otomatik telif hakkı aklama sistemleri sayesinde kod sık sık MIT/BSD ya da ticari koda dönüştürülüyor. FSF’nin de buna çözümü yok
  • Lisans tartışmaları hiç bitmez. GPL benimsenmeyi sınırlar ama MIT daha esnektir. Sonuçta mesele hedefin ne olduğu — herkesin kullanabileceği bir OSS mi istiyorsun, yoksa şirketlerin katkı yapmadan kâr etmesini engellemek mi
  • Coreutils’in MIT olması somut olarak ne tür bir “kötülüğe” kapı açıyor, merak ediyorum

• rust-coreutils yüzünden CUDA Toolkit kurulamadı. İlgili sorun NVIDIA forumunda var

  • Bağlantı verilen başlık sanki gzip ile ilgili bir sorundu. dd yüzünden değildi galiba
  • Açıkçası rust-coreutils’in varlık sebebi yok. Ubuntu kurduktan sonra yapılacak ilk şey gerçek coreutils ve sudo’yu yeniden kurmak olmalı

• “Crossing the chasm” kavramı ilginç. Rust’ın aşmaya çalıştığı uçurum sadece Ubuntu’nun coreutils örneğiyle sınırlı değil
  Rust for Linux ya da otomotiv sektörü için Rust gibi girişimler var ama şimdilik daha çok sürücü seviyesinde kalıyor gibiler

  • Rust birçok yöne doğru genişliyor. pyo3 (Python modülü yerine geçme), Dioxus (React benzeri web framework’ü), Ferrocine (otomotiv için compiler) bunların başlıcaları. DARPA TRACTOR projesi de Rust benimsenmesini hızlandırıyor
  • Rust’ın Project Goals belgesine (bağlantı) bakarsan topluluğun hangi yönlere odaklı yatırım yaptığını görebilirsin
  • Rust’ın kendisi harika ama topluluğun bir kısmının mevcut, istikrarlı yazılımları sadece “Rust’ta yeniden yazıp” markayı sahiplenmeye çalışması sorunlu. Ubuntu da bu tür bir erdem gösterisine (virtue signaling) kapılmış gibi görünüyor

• Standart kütüphaneyi sonradan değiştiririz mantığı tehlikeli. Kullanıcılar “uçurum”lardan çok istikrarlı ve yüksek kaliteli sistemler istiyor

  • Rust tarafında stdlib’i “değiştirmekten” ziyade ekleme yapmak kolay. Her 6 haftada bir yeni sürüm çıkıyor ve her seferinde 10’dan fazla özellik ekleniyor. Zaten yüzlerce özellik stdlib’e girdi

• Rust ekosisteminin olgunlaşmamış olması benimsenmeyi engelleyen etkenlerden biri. Birçok crate ya 1.0 öncesi sürümde ya da basit bir C wrapper düzeyinde. Kriptografi tarafı fena değil ama SAML gibi şeyleri bulmak zor

  • pre-1.0 sürümler için fazla endişelenmemek lazım. SemVer’e sıkı bağlılık kültürü yüzünden insanlar 1.0 ilanını geciktirebiliyor. libc gibi API’ye derinden bağlı crate’lerde sürüm yükseltmek de zor oluyor. Ben şahsen blessed.rs gibi küratörlü listelere bakıyorum
  • gettext de 30 yıl sonra 1.0 oldu
  • Python’un cryptography modülü Rust toolchain istediği için Termux ortamında kurulamıyordu. Rust bağımlılığı yüzünden Python projelerinin bile ağırlaşması can sıkıcı

• C++ kodunu Rust’a sadece “hissiyatla çevirip (vibe-translate)” lisans değiştirme yönünde bir hareket var. Mesela sudo-rs, C sürümünden daha kötü bir güvenlik siciline sahip

  • Rust, yapay zeka ve güvenlik etrafındaki propaganda fazlasıyla abartılıyor. Başta Rust’ı seviyordum ama MIT lisansı tartışmaları ve aşırı tanıtım giderek yorucu gelmeye başladı

• .NET’in devasa standart kütüphanesi gerçekten çok konforlu. Çoğu iş standart yöntemlerle yapılabiliyor ve tuhaf bir implementasyon varsa çoğunluk bunu standartlaştırmaya çalışıyor

  • Rust’ın küçük stdlib’i bence bir hata. stdlib her zaman mevcut olan tek bağımlılık olduğu için, kusursuz olmasa bile daha fazla araç içermeli
  • Ama sistem programcıları açısından büyük bir stdlib tersine sorun yaratabilir. .NET GC tabanlı olduğu için sorun değil ama Rust ya da C++ bare metal ortamlarda da çalışabilmeli. Büyük stdlib, bellek kısıtlı (<64K) ortamlarda yük oluşturur
    Rust’ın std/core’u zaten çok büyük; mikrokontrolcülerde weak symbol gibi hilelere ihtiyaç duyuluyor.
    Küçük bir stdlib, API kararlılığını koruma ve bakım yükünü azaltma açısından avantajlı. C++ bu konuda çok çektiği için Rust’ın temkinli olması gerekiyor