2025'te Rust: Temel yazılımı hedefleyerek

• Rust, bu yıl 10. yılını kutlarken gelecekte temel (Foundational) yazılım geliştirmenin kilit dili olarak konumlanıyor
• Temel yazılım; işletim sistemi çekirdekleri, bulut platformları, gömülü cihazlar, CLI araçları gibi her şeyin temelini oluşturan katmanı ifade ediyor
• Rust, C/C++ düzeyinde performans ve güvenilirlik sunarken bellek güvenliğini garanti eden bir tip sistemiyle giriş engelini düşürdü
• Rust'ın misyonu yalnızca temel alanla sınırlı değil; Dioxus, Tauri, Leptos gibi projeler aracılığıyla üst seviye uygulama geliştirme üzerinde de etki yaratıyor
• Gelecekte dil birlikte çalışabilirliği, tip sistemi genişletmeleri ve ekosistemin güçlendirilmesi temel yatırım alanları olarak planlanıyor

---

Rust'ın vizyonu: temel yazılım

• Rust'ın temel vizyonu, temel yazılımı daha kolay yazılabilir ve sürdürülebilir hale getirmek
  • Temel yazılım; tüm sistemlerin dayanağı olan işletim sistemi çekirdekleri, bulut altyapısı, gömülü cihazlar ve CLI araçlarını kapsıyor
  • Windows ve Linux çekirdeği, VSCode arama motoru ripgrep, Deno, Python uv paket yöneticisi gibi birçok yerde şimdiden benimsenmiş durumda
• Bu tür yazılımlarda performans, güvenilirlik ve üretkenlik aynı anda kritik önemde
  • Temel katman çökerse üst katmanların tamamı etkilenir; bu yüzden kararlılık şarttır
  • Performans düşüşü üst katmanların performans sınırını belirlediği için ek yükün asgari olması gerekir

Temel yazılımda performans, güvenilirlik ve üretkenlik

• Temel yazılım da tüm yazılımlar gibi çeşitli gereksinimlere sahip, ancak burada her unsur daha da önemlidir
  • Güvenilirlik en öncelikli konudur. Temel çökerse onun üstündeki her şey de başarısız olur
  • Performans ek yükü, üst katman performansının sınırını belirlediği için en aza indirilmelidir
• Geçmişte bu gereksinimleri karşılamak için iki seçenek vardı
  • C/C++: Büyük özgürlük sunar, ancak buna karşılık kusursuzluk gerektirir
  • Java, Go gibi yüksek seviyeli diller: Performansı korumak için özel kodlama yaklaşımları gerekir; soyutlama ve kullanım kolaylığında kısıtlar vardır
• Rust, sıfır maliyetli soyutlamalar ile bellek güvenliğini garanti eden tip sistemi birleşimi sayesinde bu yaklaşımı değiştirdi
• Yüksek seviyeli kodu güvenle yazarken düşük seviye performans ve bellek güvenliğini aynı anda elde etmeyi sağlayan bir araç haline geldi

Giriş engelini düşürmek ve geliştiricileri güçlendirmek

• Rust sunumlarında tip sistemi ve statik denetimler sık sık "ıspanak" benzetmesiyle anlatılır; yani faydalı ama yenmesi istenmeyen bir şey gibi
• Gerçekte tip sistemi, geliştiriciler için çok güçlü bir araçtır
• Yeni başlayanlar, tip sistemini öğrenirken başarılı yazılım yapılarının nasıl kurulacağını da öğrenebilir
• Uzmanlar ise kendi yapılarını tasarlarken hataları daha hızlı fark edebilir

• Yehuda Katz'ın "odaklanmış halde kurduğum soyutlamalar, yorgun gelecekteki bana yardımcı olur" sözü bunu iyi özetliyor

Temel olmayan yazılım alanı

• Rust'ın misyonu temel yazılıma odaklanmış olsa da bunun dışındaki alanlar göz ardı edilmiyor
• Dioxus, Tauri, Leptos gibi projeler, Rust'ı kullanarak GUI ve web sayfaları gibi daha yüksek seviyeli uygulama alanlarına da genişliyor
• Rust'ın başlıca güçlü yanları özünde temel yazılıma odaklansa da bu girişimler göz ardı edilmemeli

Zorlayıcı hedefler ve büyüme

• Temel yazılım düşük seviye ayrıntılar üzerinde denetim gerektirdiğinden, genelde erişilebilirlik ve kullanım rahatlığı (ergonomics) daha az önemli görülür
• Oysa gereken ayrıntılı denetim ne kadar fazlaysa, kullanım rahatlığı da o kadar önemli hale gelir
• Geliştiricinin yalnızca gerçekten önemli kısımlara odaklanmasına yardımcı olmak, üretkenliği büyük ölçüde artırır

• Rust'ın yüksek seviyeli kullanımını ilerleten projeler, Rust programlamayı daha rahat hale getirecek iyileştirmeler için fırsat sunuyor
• Bu iyileştirmeler temel yazılım geliştirmeye de doğrudan yansıyor
• Buradaki ana nokta, denetim ve güvenilirliği kaybetmeden kullanım rahatlığını artırmak

Tam yığın desteğinin önemi

• Rust'ta yüksek seviyeli uygulama geliştirmeyi cazip kılan bir başka neden, tam yığını tek bir teknolojiyle kurabilmek
• Başta Rust'ı yalnızca veri düzlemi servisleri gibi bazı bölümlerde kullanmayı planlayan geliştiriciler, zamanla bunu tüm alana yayabiliyor
• Bunun nedeni Rust'ın yüksek üretkenlik sunması ve tek bir dille kütüphane ile kod paylaşımını mümkün kılması
• Özünde basit olan kod, hangi dilde yazılırsa yazılsın basit kalır

Kademeli derinleşme (Iterative Deepening) deneyimi

• İdeal olarak Rust ile ilk kullanıcı deneyimi basit olmalı; proje ilerledikçe daha fazla denetim yerel olarak ve kademeli biçimde genişletilebilmelidir
• Bu kulağa basit gelse de pratikte oldukça zor bir hedeftir
• Birçok proje, yeni başlayanlar için giriş eşiğinin yüksek olması ya da daha ileri denetim düzeylerini öğrenmek için çok fazla bilgi gerektirmesi nedeniyle başarısız olur
• Rust her zaman bunda başarılı olmasa da, bunu iyileştirmek için sürekli çalışıyor

Bundan sonraki planlar

• Bu yazı serinin ilk bölümü; devamındaki dört yazıda Rust'ın temel yazılıma daha uygun hale gelmesi için gerekli yatırım alanları ele alınacak
  • Dil birlikte çalışabilirliği (smooth language interop) ve genişletilebilirlik (extensibility)
  • Tip sistemi yoluyla amacın netleşmesi (clarity of purpose)
  • Ekosistemin güçlendirilmesi: daha iyi yönergeler, araçlar ve Rust Foundation'dan yararlanma
  • Son yazıda ise Rust açık kaynak organizasyonunun işletilmesi, katkı ve bakım süreçlerinin mümkün olduğunca erişilebilir ve keyifli bir etkinlik haline getirilmesi ele alınacak

[yeorinhieut]

Rust bir şekilde fena görünmese de, toksik hayran kitlesi(?) yüzünden mesafeli durduğum tek dil gibi geliyor.

[aer0700]

Keşke C ya da C++ için standart bir paket yöneticisi olsaydı. Cargo'ya bakınca hep bunu düşünüyorum.

[cosine20]

Ispanak ne kadar lezzetli ama....

[t7vonn]

Bugünlerde Rust'ın kullanılmadığı neredeyse hiçbir yer yok.

[lostid]

Oldukça büyük bir şirkette çalışıyorum ama Rust kullanılan bir alan yok. Lütfen insanları yanlış yönlendirmeyin.

[t7vonn]

Lütfen sataşmayın

[bobross0]

Vay beeeee;;

[crawler]

Lütfen sataşmayın, vay canına

[shakespeares]

Vay canına ;;

[qwas5544]

Vay be be be be;;;

[lostid]

Her şeyi bir kenara bırakırsak, şu sıralar Rust fanatikleri yüzünden çıldıracak gibi oluyorum. Offline ortamda azınlık içinde bile daha da küçük bir gruplar ama online'da neredeyse ISIS gibiler... Ah, keşke bir yerde toplanıp sadece kendi aralarında takılsalar...

[ifmkl]

Rust'ı din gibi savunanlar arasında bile, aslında önce kendilerinin onu düzgün kullanıp kullanmadığı şüpheli olan çok kişi var.

[skageektp]

Yine de... Rust'ı seviyorsunuz, değil mi?
Rust fanatiklerinden nefret edebilirsiniz ama lütfen Rust'ı sevin gözyaşları içinde

[taeunlee99]

FFmpeg yüzünden sağlam dayak yeseniz bile tüm kodun Rust ile yazılması gerektiğini falan söylüyorlar.

[GN⁺]

Hacker News görüşleri

• Temel yazılımlardan söz ederken Rust’taki en büyük eksikliğin ABI olduğunu düşünüyor. Rust ile bir işletim sistemi yapıp zengin hizmetler sunmak için, OS yükseltilse bile uygulamaların kütüphaneleri yeniden derlemeden çalışabilmesi gerekir. Windows bunu COM ile, Apple bir dönem ObjC’nin dynamic dispatch’iyle (ve şimdi Swift ABI ile), Android ise JVM ve bytecode ile çözüyor. Rust ise fiilen yalnızca extern "C" desteklediği için dinamik kütüphane kullanımı sınırlı. VM katmanı (JVM, .NET) olmadan ABI sağlamak inanılmaz derecede zor ve bir kez belirlenen uygulama ayrıntılarını asla değiştirmemek gerektiğinden önceliğinin düşük kalması anlaşılır. Gerçekte bu modelde başarılı olanlar Swift ve COM gibi az sayıdaki örnek. Rust’a tam bir ABI gelirse neredeyse kusursuz bir dile yaklaşacağını düşünüyor. (Bağımlılıkları ikili biçimde yönetmek derleme sürelerini de ciddi biçimde azaltır)

  • Rust’ın temelde isteğe bağlı (opt-in) ABI kararlılığına yönelmesinin sebebinin zero-cost abstraction hedefi olduğunu açıklıyor. Kararlı ABI’nin performans kaybı getirdiğini C++ örneği de destekliyor (C++ ABI açıklaması). Rust-Rust eklentilerini dinamik olarak yüklemek (dlopen) için stabby, abi_stable gibi araçlar var ve epey iyi çalışıyorlar. Daha genel diller arası birlikte çalışabilirlik için crABI (crABI önerisi) gelecekte bir alternatif olabilir. Ama bu yalnızca Rust’ın tek başına çözebileceği bir sorun değil; başka dillerin ve Linux dağıtımları gibi toplulukların desteği ve işbirliği de gerekiyor. Rust’ın I/O ve bellek tahsisi yöntemlerini açıkça seçtiren bir dil olması nedeniyle, Swift’teki gibi her şeyi paylaşılan kütüphanelerle çözme yapısının ona tam uymayabileceği de belirtiliyor.
  • Neredeyse aynı sorun Wasm Components ile çözülmeye çalışılıyor. WebAssembly taşınabilir bir komut biçimiyse, WebAssembly Components de taşınabilir bir çalıştırma/bağlama biçimi. Tam olarak repr(wasm)/extern "wasm" kadar kolay değil ama wit-bindgen ya da wasm32-wasip2 hedefiyle çok zorlanmadan kullanılabiliyor. Wasm Components tanıtım videosu
  • Bunun gerçekten gerekli olup olmadığından emin değil. Daha çeşitli “şeyleri” (slices, trait objects vb.) arayüz üzerinden geçirebilmek elbette daha rahat olurdu ama pratikte extern "C" ABI ile de gereken her şey yapılabiliyor. Ayrıca extern ABI’yi daha fazla türe genişletmeye dair öneriler de gördüğünü söylüyor
  • Bir Rust konferansında bu konuda Swift’in yaklaşımını güçlü biçimde örnek alan bir sunum gördüğünü, muhtemelen ileride bu yöne evrileceğini düşündüğünü söylüyor
  • Aslında böyle bir şeyin zaten var olduğunu, adının da doğrudan “C” olduğunu belirtiyor

• Rust’ı gerçekten çok seviyor ama birkaç can sıkıcı, kronik sorunun daha fazla ilgi görmesini istiyor

  • 1. self-referencing struct sorunu var. Örneğin kaynak dosya ile parse edilmiş AST’yi aynı struct içinde tutmak istese, bunu bugün yapmak kolay değil. offset reference gibi bir şeyin faydalı olacağını düşünüyor
  • 2. orphan rule (yetim trait kuralı). Gerekçesini anlıyor ama yine de rahatsız edici bir kural. Yeni özelliklerle (bazen 2-3 kat sarmalama gerekiyor!) aşılabiliyor ama bunun gerçekten gerekli olup olmadığını sorguluyor
  • 3. Makul derleme süreleri elde etmek için projeyi çok sayıda küçük crate’e bölmek gerekiyor. Sebebini anlıyor ama sonuç iyi değil. Crate tek bir derleme birimi gibi ele alınıyor ve bunun nedeni döngüsel bağımlılıklara izin verilmesi. Oysa çoğu kod tabanında gerçekte döngüsel bağımlılık yok; bunun isteğe bağlı hale gelmesi ya da crate içindeki öğelerin/dosyaların bağımlılık grafiğine göre otomatik olarak derleme birimlerine ayrılması iyi olurdu
  • Aklına ilk gelenleri yazdığını ama muhtemelen daha fazlası olduğunu ekliyor. Rust buna rağmen hayatındaki en iyi dil; eleştirileri yapıcı eleştiri olarak görülmeli
    • Rust’ın crate’ler arasında döngüsel bağımlılığa izin vermediğini ama crate içi modüller arasında verdiğini hatırlatıyor. Çoğu kodda döngüsel bağımlılık olmadığını düşünse de, örneğin test alt modülü bulunan herhangi bir modülde bu durum ortaya çıkıyor. Testleri tam anlamıyla ayırmak için tüm test fonksiyonlarını crate kökünde tanımlamak gerekir ki bu da pratikte verimsiz
    • 1 ve 2. maddelere tamamen katılıyor. 4. madde olarak partial self borrowsun (metotların struct’ın sadece bir kısmını ödünç alabilmesi) olmasını da istiyor. 3. madde içinse önce birden çok crate’i tek seferde yayımlayabilme gibi daha iyi desteklerin gelmesi gerektiğini düşünüyor
    • orphan rule konusunda, Rust’ın daha iyi başka bir alternatife ihtiyaç duyduğunu mu kastettiğini yoksa bunun yerine geçebilecek özellikler istediğini mi daha açık anlatmasını istiyor
    • orphan rule’a tamamen katılıyor. Uygulama crate’lerinde bunun devre dışı bırakılabilmesi ya da proc macro gibi araçlarla yeterli hijyen garanti edildiğinde kuralın gevşetilebilmesi iyi olurdu

• “Smooth, iterative deepening” ifadesi üzerinde düşünürken, Rust’ın diller arası uyumluluğa fazla önem vermesinin karmaşıklığı artırıp güvenliği zedeleyebileceğini düşünüyor. Böyle durumlarda asıl faydalı olanın libc gibi sistemin en alt katmanlarını değiştirmek olacağını savunuyor. Go neredeyse hiç cross-language çağrı yapmıyor. Google temel kütüphaneleri bizzat geliştirerek sağlam bir zemin kurdu ama Rust tarafında çok sayıda farklı temel kütüphane sürümü var ve bunların çoğu eksik kalıyor

  • Son 20 yılda bilgisayar biliminin temel sorunlarından birinin aynı makinedeki birden fazla programın verimli biçimde iletişim kurması olduğunu söylüyor. Çoğu yaklaşım ya Microsoft’un DLL modelini kaynak kod ve durumla dolanarak geçmeye çalıştı ya da CORBA gibi nesne istek aracılarının yerleşememesiyle sonuçlandı. QNX tarzı RPC de benzer şekilde. Bu yüzden bugün hâlâ birbirine tam uymayan şeyleri zorla bir arada kullanmaya çalışıyoruz
  • Aslında her şey soketler üzerinden de yapılabilir ama soketler ham bayt akışı oldukları için yanlış bir soyutlama; buna rağmen kullanışlı oldukları için vazgeçilemiyor
    • Kendi görüşüne göre gönderide anlatılan şey, DLL/COM/Wasm Components gibi gerçek bir diller arası paylaşılan kütüphane ikamesi yaratmaktan çok, C++’ı adım adım Rust’a taşıma yönündeki pratik ihtiyaç. Genel bellek güvenliğini artırmak için “mevcut programlarla ne yapılacak?” sorusu büyük bir mesele ve şu an Rust ile C++ arasındaki birlikte çalışabilirlik yetersiz. İki dil kaynak kod düzeyinde sorunsuz işbirliği yapabilirse Rust’ın C++’ın önemli bir bölümünün yerini alma ihtimali de ciddi biçimde artar
    • Bazen sadece soketlerin ve protokolün uyuşmasının neredeyse en iyi diller arası soyutlama olabileceğini düşünüyor. Bu yüzden gerçekten ideal görülen cross-language çağrı soyutlamasının ne olduğunu merak ediyor

• “Tahsislerden kaçınmak, GC’yi tetiklememek” yaklaşımının modern GC ve JIT anlayışıyla pek uyuşmadığını vurguluyor. Modern GC’de stop-the-world gecikmesi çoğu zaman neredeyse yok denecek kadar az; toplam GC CPU kullanımı da ağırlıklı olarak resident set ile heap boyutunun oranına bağlı. JIT ise AOT’ye göre daha fazla optimizasyon fırsatı sunabiliyor ve daha agresif arama yapabiliyor (spekülatif optimizasyon sayesinde). Gerçekte önemli olan başlangıç/ısınma gecikmesi ve bellek ek yükü ile, kötüleşmiş en kötü durum performansı değil; ortalama performans. Ayrıca elle bellek yönetiminin mutlaka daha verimli olduğu da söylenemez; gerçek RAM kullanımı 3 kat artsa bile maliyet farkı sıfır olabilir. Konuyu iyi ele alan şu ISMM sunumu da öneriliyor

  • JIT’in daha fazla optimizasyon fırsatı gördüğü ifadesiyle tam olarak ne kastedildiğini daha somut biçimde soruyor. Sonuçta JIT, AOT’nin bir tamamlayıcısı
  • Burada “modern GC” ile tam olarak hangi uygulamaların kastedildiğini soruyor

• İşaretlenmiş yorumların ve tartışmanın meseleyi iyi yakaladığını düşünüyor. “Resmî spesifikasyonu olan bir dil standardı yapalım”, “birden fazla uygulama olmalı” gibi noktaların pratikte önemli sorular olduğunu söylüyor. Özellikle @infogulch’un, bir dilin sanayinin temeli olabilmesi için resmî bir spesifikasyona ihtiyaç duyulduğunu çok iyi vurguladığını belirtiyor (ilgili yorum)

  • Neden işaretlendiğinin net olmadığını, ayrıca pratikte standart spesifikasyonu ya da birden fazla uygulaması olmadan da sektör temeli hâline gelmiş birçok dil bulunduğunu esprili biçimde örnekliyor. Örneğin Ruby’nin eski bir ISO standardı var ama o yalnızca ilgili sürüm için geçerli; Python’da ise fiilen uygulamanın kendisi standart. Rust için de benzer durum geçerli ve ana akım kullanıcıların böyle bir nedenle dil değiştireceğini düşünmüyor
  • “Resmî dil standardı”nın ne olduğunu merak edip arayınca rust-lang/reference belgesini bulduğunu söylüyor. Rust projesi dili spesifiye etme işine oldukça ciddi yaklaşıyor. Yakın tarihli vizyon yazısında kaydedilen ilerleme ayrıntılı biçimde anlatılıyor. Spesifikasyon çalışması çok büyük ve zor ama hafta sonları bile master branch’e PR merge edilecek kadar aktif biçimde ilerliyor
  • Birden fazla uygulama gerekliliği konusunda da gccrs gibi alternatif Rust derleyicileri resmî olarak geliştirildiği için bunun yardımcı olacağını umuyor
  • LLM’lere ve Rust’a kuşkuyla yaklaşıyor; ikisinin de temelde bazı kesimleri memnun edip üretkenlikte küçük artışlar sağladığını düşünüyor. Ama topluluğun, etkisini sorumsuzca büyütme tavrına katılmıyor
  • “published language standard”ın tam olarak ne anlama geldiğini ve pratikte ne fayda sağladığını daha ayrıntılı açıklamasını istiyor
  • Rust’ın kendisine karşı bir şikâyeti yok ama bazı kullanıcıların biçimsel spesifikasyonun ne kadar önemli olduğunu kavramamasını üzücü buluyor. Tüm hesaplamalı sistemlerin ömrü ve güvenilirliği, spesifikasyona ne kadar biçimsel yaklaşıldığıyla belirlenir. Açık bir tanım yoksa yalnızca “bir uygulamanın tesadüfen belli bir girdide çalışmış olmasına” güvenmek zorunda kalınır; bu kadar zayıf bir temele sistem kurmak tehlikelidir. Bilgisayımda sistemin kendisi spesifikasyondur (uygulama ise ikincil bir optimizasyondur)

• İnsanların sık sık Rust’ın bir spesifikasyona sahip olması gerekip gerekmediği sorusunu bile sorguladığını, bunun da yazılım mühendisliğinde gerçek mühendisliğin ne kadar az olduğunun göstergesi olduğunu söylüyor

  • Yazılım mühendisliğinin gerçek mühendislik olmadığını düşünüyor. Köprü ya da gökdelenlerde bir şeyi üç kez inşa edip sonra doğrusunu yapmak gerekmez ama yazılımda bu yaklaşım bazen gerçekten işe yarıyor

• Rust’ı “yalnızca programcı gibi görünmek isteyenlerin kullandığı bir dil” diye niteleyen yoruma karşılık, kendisinin gerçekten programlamayı seven biri olarak Rust’ı çok tazeleyici bulduğunu söylüyor. C++’ın aşırı sancılı olduğu günlere dönmek istemiyor. Ayrıca dil standardının (Ferrocene spesifikasyon bağışı) ya da uygulama sayısının o kadar önemli olmadığını düşünüyor. Python ve Java da tek bir merkezî uygulamaya büyük ölçüde bağımlı biçimde gayet iyi işliyor. C++ ise çoklu derleyici desteğini korumaya çalışırken platforma özgü karmaşıklıkları daha da büyüttü. Cargo’nun “berbat” tarafının tam olarak ne olduğunu anlamadığını, C++ tarafını çok daha zahmetli bulduğunu belirtiyor

  • Cargo hakkında tam olarak hangi noktaların sorunlu bulunduğunu soruyor
  • Dil ve araçlar için standartların/uygulama çeşitliliğinin gerçekten ne kadar önemli olduğunu, bunun erken bir beklenti olup olmadığını ve Rust bu alanlara daha en baştan enerji harcasaydı bugünkü kadar başarılı olup olamayacağını sorguluyor. İlgili yazının da aslında her şeyin yerini alacak kapsamlı bir ikameyi değil, belirli hedef kullanımlar için destek ve uygunluğu öne çıkarmaya çalıştığını düşünüyor
  • Cargo’nun bugün dünyadaki büyük diller arasında en iyi paket yöneticisi olduğunu düşünüyor. Geçmiş paket yöneticilerinin başarısız olduğu noktaları iyi öğrenmiş, hem tasarım hem altyapı açısından çok olgun. Namespace ve tam tekrar üretilebilir derleme gibi birkaç iyileştirme yapılabilir ama bugünkü Cargo’yu başka bir dile neredeyse olduğu gibi taşımak bile çok zor olurdu. Bu seviyede altyapısı olan dil çok az