Rust’a yatırım yapalı 10 yıl oldu; bundan sonra beklediklerim

 (tably.com)
18 puan yazan GN⁺ 2025-06-12 | 5 yorum | WhatsApp'ta paylaş
  • Rust 1.0’ın çıkışından hemen sonra Rust’ı 10 yıl boyunca gerçek işlerde kullanma deneyimini ve gelecek 10 yıla dair beklentileri derleyen bir yazı
  • İlk dönemde sürüm uyumluluğu sorunları, derleme süreleri ve borrow checker’a uyum sağlama zordu
  • Rust topluluğu ve ekosistemi, “üstün programlama sezgisi” ve güçlü topluluk kültürü sayesinde hızla gelişti; yetenekli geliştiricilerin Rust’a yönelmesi özellikle dikkat çekici
  • Artık genel sistemler ve backend alanında Rust “güvenli bir tercih” haline geldi; standart kütüphanenin gelişmesi ve crate ekosisteminin olgunlaşmasıyla belirsizlik büyük ölçüde azaldı
  • Derleme hızı, taşınabilirlik, const özellikleri, eşzamanlılık, farklı alanlara genişleme gibi Rust’ın çözmesi gereken kalan sorunlar ve gelişim yönleri somut biçimde ortaya konuyor
  • Önümüzdeki 10 yılda daha hızlı derleme, daha geniş alanlara yayılma ve geliştirici deneyiminde yenilikler yaşanacağı; Rust ekosistemindeki olumlu geri bildirim döngüsünün hızlanacağı öngörülüyor
  • 2015 Haziran’ında, Rust 1.0’ın duyurulması etrafındaki heyecan yatıştıktan yaklaşık bir ay sonra ilk Rust kodu yazıldı
  • C, Python ve JavaScript kullandıktan sonra Rust’la tanışınca, bir daha geriye dönüp bakılmadı
  • Rust tabanlı iki girişim ve 500 binden fazla satır kod yazma deneyimine dayanarak 10 yıllık bir değerlendirme paylaşılıyor

İlk yıllar zorluydu - The early days were painful

  • Rust’ın ilk benimsenme döneminde crate’ler ile derleyici arasındaki sürüm uyumluluğu çok kırılgandı; küçük bir hata düzeltmesi için bile tüm derleme ortamını zorunlu olarak güncellemek gerekirdi
  • Borrow checker kavramı ve lifetime yönetimi öğrenmesi zordu; karmaşık tipler arttıkça derleme sürelerinin keskin biçimde uzaması ciddi bir sorundu
  • Yeni bir özellik ya da hata düzeltmesi gerektiğinde “dünyadaki bütün sürümleri” güncellemek gerekirdi ve uyumlu sürümleri bulmak için çok zaman harcanırdı

Rust topluluğunun üstünlüğü - The people were and are exceptional

  • Rust ekosisteminde basit ve zarif uygulamaları, hızlı ve sağlam performansı hedefleyen üstün bir programlama kültürü yerleşmiş durumda
  • TypeScript ya da Python kullanmaya kıyasla Rust’taki bağımlılık yapısı çok daha temiz, derleme süreci çok daha sade
  • Topluluk gönüllülerinin adanmış katkıları ve “şimdi değil/henüz değil” şeklindeki temkinli yaklaşım belirleyici rol oynadı
  • Londra’da Rust geliştiricisi işe almak büyük bir avantaj sağladı ve Rust geliştiricilerinin ortalama yetkinliği çok yüksek

Rust, (bazı alanlarda) güvenli bir tercih haline geldi - Rust has become a safe bet (in some domains)

  • İlk dönemde standart kütüphanenin (std) yetersizliği nedeniyle yardımcı işlevleri ve yamaları elde yazmak gerekirdi; bugün ise işlevlerin çoğu std ve crate’lerde yer aldığından belirsizlik büyük ölçüde azaldı
  • Derleme ve yükseltmelerde öngörülebilirlik, daha az dış bağımlılık, semver uyumu, borrow checker ve çıkarım motorundaki iyileşmeler sayesinde Rust kullanma deneyimi çok daha istikrarlı hale geldi
  • Yeni crate’ler (ör. jiff, polars, tauri) geçmişteki deneme-yanılmalardan öğrenilerek geliştiriliyor; tokio, hyper, regex gibi projeler ise sahada kendini kanıtladı
  • Eskiden “tekerleği yeniden icat etmek” kaçınılmazdı; bugün ise iş mantığına odaklanarak yüksek performanslı ve sağlam uygulamalar geliştirmek mümkün

Günümüz Rust’ının sunduğu geliştirme ortamı - Rust today feels like what programming should be

  • Rust; yalın ve sağlam bir derleme sistemi, çok iyi hata mesajları ve lint’ler, güçlü dokümantasyon ve IDE entegrasyonu, sağlam CI/gerileme testleri ile programcı odaklı empatiye sahip bir dil
  • Büyük açık kaynak projeleri arasında Rust kadar programcı dostu bir dil çok az
  • Çok sayıdaki topluluk ve katkıcının “uzun vadeli yatırımı” bugünkü Rust’ı yaratan temel etken

Gelecek 10 yıla dair beklentiler - What I’m looking forward to over the next 10 years

Daha sade ve daha hızlı derlemeler - Simpler and faster builds

  • Karmaşık ya da yavaş bağımlılıkların daha basit ve hızlı alternatiflerle değiştirilmesi yönündeki çalışmaların süreceği bekleniyor
  • Saf Rust standart kütüphanesi, sistem linker’ı ve kütüphane bağımlılıklarının azaltılması, pure-Rust kriptografi, kalıcı BTreeMap, Rust tabanlı oyun motorları gibi yeni girişimler umut veriyor
  • Tably’de de son birkaç ayda frontend/backend derleme hızı %60 iyileşti

Daha fazla taşınabilirlik ve daha az #[cfg()] - Improved portability and less #[cfg()]

  • Farklı platform ve seçenek kombinasyonlarını test etmek zor; #[cfg()] nedeniyle test edilmemiş kod, eksik dokümantasyon ve IDE sorunları ortaya çıkabiliyor
  • #[cfg()]’nin trait sisteminin içine taşınmasıyla platform/seçenek garantileri, daha az yeniden derleme, MIR önbelleği ve daha hızlı CI mümkün olabilir

Her şeyin const olması - Everything being const

  • Daha fazla işin derleme zamanında önceden yapılması, makro ve build script bağımlılığını azaltabilir; çalışma zamanı hatalarını da daha erken önleyebilir
  • Şu anda sınırlı olsa da, gelecekte “tüm kodun const context içinde çalışabildiği” bir Rust hedefleniyor

Daha sade eşzamanlılık - Simpler concurrency

  • Bugünkü Rust’ın asenkron (Async) modeli; static bound, cancellation-safety, trait kısıtları gibi nedenlerle gerçek işlerde yüksek karmaşıklık yaratıyor
  • Geçmişteki user-space green thread (libgreen) yaklaşımında olduğu gibi, dil seviyesinde daha sade bir eşzamanlılık modeline ihtiyaç var

Daha fazla alanda öne çıkmak - Excelling in more domains

  • Rust’ın web tarayıcısı içindeki kullanımı (özellikle wasm/rustwasm) hâlâ tam anlamıyla keşfedilmemiş durumda; tarayıcılar arası stack trace gibi pek çok sorun çözüm bekliyor
    • leptos, sycamore gibi framework’ler gelişmeye devam ediyor, ancak hâlâ iyileştirme alanı var
  • Rapid prototyping, iş mantığı, GUI, makine öğrenimi, oyun geliştirme gibi Rust’ın henüz tamamen yarıp geçemediği alanlarda da sürekli ilerleme bekleniyor

Sonuç

  • Rust’ın büyüme geleceği çok açık ve umut verici
  • Benimsenme arttıkça mühendislik ve test kapasitesi büyüyor; bu da daha geniş kullanım ve daha fazla iyileşme için olumlu bir döngü yaratıyor
  • Önümüzdeki 10 yılda daha hızlı derleme, daha farklı alanlarda kullanım ve daha akıcı bir geliştirici deneyimi gerçeğe dönüşecek
  • Rust’ın yeni 10 yılı heyecan verici görünüyor

İlgili okumalar

5 yorum

 
ndrgrd 2025-06-12

Rust her yönüyle iyi ama dilin talep ettiği şeyler fazla.
Rust kullanırken, sanki fikrin hayata geçirilmesine odaklanmaktan çok Rust adlı dili çalışıyormuşum gibi geliyor.

C++'tan taşımak gibi, zaten yapılmış projeleri aktarmakta pek sorun olmaz herhalde
yama yeni fikirleri hayata geçirirken kullanmanın ne kadar rahat olduğundan emin değilim.
 
felizgeek 2025-06-12

Prototipleme için Python öneririm.
 
ndrgrd 2025-06-12

Kişisel olarak tip sistemini tercih ettiğim için şu anda C# kullanıyorum ve bu düzeyin yeterince tatmin edici olduğunu düşünüyorum.
 
codemasterkimc 2025-06-12

Kişisel olarak, dünya çevresini düşünüyorsanız RUST. Legacy Spring kodunu Axum’a !!!
 
GN⁺ 2025-06-12
Hacker News görüşü
  • Çok olumlu bir yazı ve benim deneyimimle de örtüşüyor. Yine de karanlık bir öngörü seçmem gerekirse şu nokta olurdu:
    "async; static bound, cancellation safety, trait ve dyn ile ilgili kısıtlar gibi nedenlerle görece yüksek bir karmaşıklık maliyetine sahip. Şu an için bu sorunun çözüleceğine dair pek işaret yok. Senkron/asenkron primitifler arasındaki ayrım ve ekosistemin kendine özgü özellikleri async tax'i (ek maliyeti) artırıyor. Effects tabanlı çözümler de pek umut verici görünmüyor."
    "Rust 1.0 öncesinde libgreen diye bir çözüm vardı. Bifurcation (ayrışma) olmadan user-space içinde eşzamanlılık sağlıyordu, ancak performans, taşınabilirlik ve bakım maliyeti yüksekti; sonunda kaldırıldı. Yeterli mühendislik kapasitesi varsa bunun yeniden düşünülmeye değer olduğunu düşünüyorum. Bir gün std::{fs, net} ile fiber::{spawn, select}'i generator ile zero-cost wrapping yapan bir PoC hazırlamak istiyorum"
    • "'static bound karmaşıklığı artırıyor" tartışmasının, Rust'ın genel tasarımından çok Tokio async runtime'ın bir tasarım tercihi olduğu görüşündeyim. Embassy async runtime böyle bir bound olmadan da çalışıyor, ama bunun karşılığında pinning'i doğrudan yönetmek gerekiyor. Aslında 'static bound'un amacı karmaşıklığı azaltmak
  • 2022 sonlarında Rust'a kapılıp öğrenmeye başlayan biri olarak, 2015 gibi daha zorlu bir dönemde dili öğrenenlerin deneyimlerini duymak her zaman ilginç geliyor. Rust'ı daha olgun bir aşamada öğrenebilmiş olmak, zaten dik olan öğrenme eğrisinin bir miktar yumuşamış olması anlamına geldi ve bu açıdan şanslı olduğumu düşünüyorum. Bugünlerde yazıda anlatılan erken dönem Rust deneyimlerini Zig'de yeniden yaşıyormuşum gibi geliyor. Zig sanki Rust'ın ilk dönemlerine benzer bir noktada. Yine de şimdiden keyifle kullanıyorum
    • "Bulduğundan daha iyi durumda bırak" kültürü çok güçlü. Bir araç ya da dil kafa karıştırdıysa bunun kullanıcının suçu olmadığı düşüncesi yerleşmiş durumda. Ben kafamı karıştırdıysa başkalarının da karıştıracaktır; bu yüzden fark ettikçe iyileştirmek herkes için büyük kazanç. Ağaç dikmek için en iyi ikinci zaman bugündür sözü burada geçerli. Bu kültür sayesinde, geçmişte Rust'ı deneyip hayal kırıklığı yaşayan biri bir yıl sonra geri döndüğünde çok daha iyi bir deneyim yaşayabiliyor. Bu yüzden Rust'a yeni başlayanlara verilecek en iyi tavsiye "6 ay bekle" olurdu
    • MSFT, Google gibi büyük teknoloji şirketleri ya da Linux gibi büyük açık kaynak projeleri tarafından benimsenmiş bir dilse, bu zaten ekosistemin yeterince olgunlaştığının kanıtı. Ama Zig, mevcut araçlara kıyasla henüz böyle bir güven verecek kadar belirgin bir (büyük) değişim göstermedi
  • Rust'ın fonksiyonel programlamayı teşvik ettiğini hissediyorum. Başta her advance çağrısında iç durumu değiştiren bir parser yazıyordum ama mutability ve borrowing sistemi yüzünden zorlanınca stateless bir parser'a geçmek zorunda kaldım. İç indeksleri güncellemek yerine, indeks döndüren bir yapıya dönüştü. Rust'ta mevcut yaklaşımın işlemediği ve bambaşka düşünmek gerektiği durumlar sık mı yaşanıyor diye merak ediyorum
    • Bende de benzer bir deneyim oldu. Basit durumlarda mutable, imperatif tarz gayet işe yarıyor ama karmaşıklık arttıkça fonksiyonel tarafa kayıp değişimi olabildiğince azaltıyorum. Borrow checker ve lifetime'lar yüzünden geleneksel kalıplar zorlaşıyor ve doğal olarak fonksiyonel yöne gidiliyor. Fonksiyonel şekilde yazmaya alışık değilsen zor gelebilir ama derleyici açısından çok daha tatmin edici bir deneyim oluyor
  • Async/await, Rust kullanmamamın tek sebebi
    • Aslında async/await, Rust kullanmak için başlıca nedenlerden biri bence. Çünkü eşzamanlılık kalıplarını çok daha basit hale getiriyor. Başta, sanki kötü huylu bir salgın gibi bütün kodun sonunda async olmak zorundaymış gibi geliyordu; ama async kodla nasıl etkileşime girileceğini öğrenince rahatladı. Genelde spawn, spawn_blocking, futures::stream kullanımın %90'ını karşılıyor ve uygun "sınırlar" koyunca async'in her yere yayılması da gerekmiyor
    • Belli ölçüde anlıyorum. Ama bende Rust'taki async/await tam yerine oturduğu için dili kullanma nedenlerimin en büyüğü haline geldi. Sözdizimini seviyorum ve function colouring sorununu da pek dert etmiyorum. Özellikle tokio kullanırken ihtiyaç duyduğum standart fonksiyonların async sürümleri de mevcut olduğu için çözümün rahat aktığını hissediyorum. Bu tür şeyler bir bariyer yaratabiliyor ama eşzamanlı program yazmayı çok kolaylaştırıyor ve performans da gayet iyi, o yüzden memnunum. Cancellation gibi konularda biraz zorlandığım oluyor ama bunu daha çok kendi beceri eksiğim olarak görüyorum
    • Artık hepsi sağlanmıyor mu?