Rust'ı yeniden yazacak olsaydım

 (josephg.com)
1 puan yazan GN⁺ 2024-09-27 | 1 yorum | WhatsApp'ta paylaş
  • Rust, bellek güvenliği ve performans, cebirsel tipler ve Cargo'nun avantajlarına rağmen, stable kanalda dil evriminin yavaşlaması nedeniyle “henüz tamamlanmamış bir 1. nesil ürün” gibi hissettirdiği düşüncesinden yola çıkıyor
  • Topluluk büyüdükten sonra uzlaşma temelli karar alma bir darboğaz haline geldi ve coroutine gibi, uygulanmış olsa bile stable Rust'ta uzun süre kullanılamayan özellikler birikmeye devam ediyor
  • Varsayımsal bir “seph edition”, mevcut Rust ve Cargo ekosistemini korurken breaking change'lere izin vererek effect system, derleme zamanı yetkileri, struct alanı borrow, comptime gibi fikirleri denemeyi amaçlıyor
  • Tedarik zinciri riskini azaltmak için dosya yazma, ağ, FFI, unsafe gibi hassas işlevlere capability eklenmeli ve çağıran taraf bunlara açıkça izin vermeli
  • Önerilerin çoğu mevcut Rust ile uyumlu değil; yalnızca capability eklemek bile semver uyumluluğunu bozan yeni hata koşulları doğurduğu için yeni bir edition veya derleyici fork'u gerekiyor

Rust neden “1. nesil bir ürün” gibi hissettiriyor?

  • Rust başlangıçta cebirsel tipler, performans kaybı olmadan bellek güvenliği ve modern bir paket yöneticisi sayesinde son derece çekici bir dil olarak öne çıktı
  • Yaklaşık 4 yıl kullandıktan sonra dilin “hep biraz eksik kalmış” bir durumda kaldığı hissi oluşuyor
  • Asıl şikayet, stable Rust'a yeni özelliklerin geliş sıklığının azalması ve dilin evrim hızının ciddi biçimde yavaşlaması
  • Rust unstable book içinde yaklaşık 700 unstable feature bulunuyor ve bunların önemli bir kısmı standart kütüphane değişikliklerinden oluşuyor
  • Coroutines, RFC'si 7 yıllık bir özellik; derleyicide uygulanmış olmasına rağmen stable Rust kullanıcıları hâlâ kullanamıyor
  • Rust RFC süreci, iyi fikirlerin uzun süre bekletildiği bir alan gibi görünüyor
    • Mutex iyileştirmesi tartışması, 25 kişinin 2 yıl boyunca 200'den fazla yorum bırakmasına rağmen belirgin bir sonuca ulaşmayan bir örnek olarak anılıyor

Varsayımsal “seph edition” fikri

  • Mevcut Rust kodunu olduğu gibi bırakıp derleyiciyi fork ederek ayrı bir Rust edition olan “seph” ekleme fikri hayal ediliyor
  • Bu edition'da breaking change'lere izin verilirken, derleyici ana Rust hattını derlemeye devam edebildiği sürece Cargo'daki mevcut crate'ler kullanılmaya devam edebilir
  • Değiştirilmek istenen ana eksenler beş başlıkta toplanıyor
    • function trait'leri ve effect system
    • derleme zamanı capability
    • Pin, move ve struct borrow tasarımının yeniden ele alınması
    • Zig tarzı comptime
    • küçük sözdizimi ve standart kütüphane iyileştirmeleri

Function trait'leri ve effect system

  • Rust'ta struct'lar için trait'ler var, ancak işlevlere de daha zengin trait/effect tanımları eklenebilmesi gerektiği öneriliyor
  • Bir fonksiyonun sahip olabileceği özellikler şöyle sıralanıyor
    • panic üretip üretemediği
    • sabit stack boyutuna sahip olup olmadığı
    • sona kadar çalışıp çalışmadığı, yield ya da await yapıp yapmadığı
    • coroutine ise continuation tipi
    • saf fonksiyon olup olmadığı
    • dolaylı olarak unsafe kod çalıştırıp çalıştırmadığı
    • sonlanma garantisi olup olmadığı
  • Fonksiyonun parametre ve dönüş tipleri, fonksiyona ait associated type gibi dışa açılırsa, bugün stable Rust'ta mümkün olmayan tip başvuruları mümkün hale gelebilir
  • Örnek olarak some_iter::Output benzeri şekilde fonksiyonun dönüş tipine doğrudan ad verip struct alanına koyan bir kod gösteriliyor
  • Linux kernel'de olduğu gibi belirli kod bloklarının asla panic etmeyeceğinin garanti edilmesi gerektiğinde, #[disallow(Panic)] benzeri bir işaretle özyinelemeli çağrılar dahil panic olasılığı denetlenebilir
  • Derleyici zaten Fn, FnOnce, FnMut gibi fonksiyonla ilgili trait'leri ele alıyor, ancak mevcut yapının fazlasıyla yetersiz olduğu savunuluyor
  • Daha ayrıntılı referans olarak Yoshua Wuyts'nin effect system yazısı ve sunumu bağlantısı veriliyor

Derleme zamanı capability ile tedarik zinciri riskini azaltmak

  • Çoğu Rust projesi çok sayıda üçüncü taraf crate kullanıyor ve küçük utility crate'ler bile kötü niyetli güncellemeler yoluyla tedarik zinciri riski yaratabiliyor
  • Bellek güvenliğinde unsafe nasıl açık bir opt-in ise, dosya sistemi, ağ, FFI ve raw pointer ile ilgili hassas işlevler de açıkça izin verilmesi gereken alanlar olmalı
  • Standart kütüphanedeki güvenlik açısından hassas fonksiyonlara marker tag eklenmesi öneriliyor
    • Örn: std::fs::write(path, contents), rastgele bir yola dosya yazabildiği için #[cap(fs_write)] benzeri bir etiket taşır
    • Derleyici bu fonksiyonu çağıran tüm call tree'yi otomatik olarak taint eder
  • Bir üçüncü taraf crate fs_write capability'sine ihtiyaç duyuyorsa, çağıran taraf bunu Cargo.toml içinde veya çağrı noktasındaki annotation ile açıkça izinli hale getirmelidir
  • İzin verilmezse derleyici, foo::do_stuff() işlevinin yerel dosya sistemine yazdığını ancak foo crate'ine ilgili capability için güvenilmediğini belirten bir hata verebilir
  • human-size veya serde gibi pek çok utility crate özel capability gerektirmez; bu yüzden yazarı kötü niyetli kod eklese bile dosya yazma ya da ağ davranışı derleme aşamasında engellenebilir
  • Alternatif olarak hassas API'lerin ayrı bir Capability parametresi alacak şekilde değiştirilmesi de düşünülüyor
    • Örn: std::fs::write, bir FsWriteCapability değeri gerektirir
    • Capability nesnesinin oluşturulması yalnızca root crate ile sınırlandırılır
  • Bu yaklaşım boilerplate'i artırır ama daha esnektir; ayrıca build.rs betikleri ve unsafe block'ları için de benzer bir ele alış gerekir
  • crates.io hack'lenip serde içine cryptolocker kodu eklense bile, capability yaklaşımında bu kod çeşitli geliştirici makinelerinde çalışmadan veya binary içine girmeden önce derleme hatası üretir

Pin, move ve struct borrow'un yeniden tasarlanması

  • Pin, borrow checker'daki boşlukları aşmak için kullanılan karmaşık bir hack olarak görülüyor ve geriye dönük uyumluluğu koruma çabasının ürettiği bir band-aid olarak değerlendiriliyor
  • Aslında gereken şeyin, taşınabilir tipleri işaretleyen bir Move marker trait'ine daha yakın olduğu savunuluyor
  • Bugünkü Rust'ta Pin trait'i yok; bunun yerine Unpin ve !Unpin var ve bu çifte olumsuz yapı kavramı daha da zorlaştırıyor
  • Pin yalnızca referans tiplerine uygulanabildiği için her yerde Box ile sarmalanmış kodlar ortaya çıkıyor eleştirisi yapılıyor
    • Örnek olarak Tokio stream wrapper, ouroboros, async-trait, self_cell gibi helper library'lere bağlantı veriliyor
  • Future::poll(self: Pin<&mut Self>, ..) gibi pinned değer alan fonksiyonlar da karmaşıklaşıyor ve projection ile uğraşmak için ayrı crate'ler gerekiyor
  • Fonksiyon içinde borrow checker değişkenleri “owned”, “borrowed”, “mutably borrowed” durumlarıyla takip ediyor, ancak bu durumlar programcıya doğrudan görünmüyor
  • async fn, duraklama durumunu saklamak için derleyicinin gizli bir struct üretmesine yol açıyor; bu sırada bir alanın başka bir alanı borrow etmesi gibi durumlar oluşabiliyor
  • Rust'ta bir struct alanının borrowed state'te olduğunu ifade edecek sözdizimi yok ve alanlar arası lifetime da doğrudan ifade edilemiyor
  • Önerilen yön, borrow checker'ı genişleterek struct alanı borrow ifadesinin doğrudan yazılabilmesini sağlamak
    • Örn: y: &'Self::x Vec<usize> gibi bir “local borrow” sözdizimi
    • Derleyici x'in borrow edildiğini bilir ve fonksiyon içindeki borrowed değişkenlerdekiyle aynı kısıtları uygular
  • Bu sözdizimi, self-referential struct'lar veya source: String ile ast_nodes: Vec<&'Self::source str> biçimindeki AST yapıları için de kullanılabilir
  • Borrow edilmiş alan içeren struct'lar taşınamaz olacağı için Move uygulamaz; daha ileri bir adım olarak kendini güvenle taşıyabilen bir Mover trait'i de düşünülebilir

Zig tarzı comptime ve Rust macro sorunu

  • Rust derleyicisi fiilen Rust, Rust macro dili ve proc macro dahil birden çok dili birlikte ele alan bir yapı gibi görünüyor
  • Temel eleştiri, Rust'ın kendisinin iyi ama macro dilinin iyi olmaması
  • Zig'in comptime yaklaşımı, derleyicinin küçük bir interpreter ile kodun bir kısmını derleme zamanında çalıştırmasına dayanıyor
  • Fonksiyonlar, parametreler, if ve loop'lar derleme zamanı kodu olarak işaretlenebiliyor; non-comptime kod ise gerçek programa emit ediliyor
  • Zig'in std print case study örneğinde, format string comptime parametresi olarak alınıyor ve comptime loop içinde parse edilerek çıktı kodu üretiliyor
  • Rust'taki println!() uygulaması format_args_nl gibi iç fonksiyonları çağırıyor ve bunun derleyiciye hardcode edildiği tahmin ediliyor
  • Hatta Rust derleyicisini yazanların bile Rust macro dilini kullanmak istemiyor gibi göründüğü eleştirisi yapılıyor

Sözdizimi ve standart kütüphanede küçük değişiklik önerileri

  • Range<T> tipinin T: Copy olduğunda Copy uygulamasıyla ilgili sorununu düzeltme isteği var
  • associated type içeren derive sorunu da düzeltilmesi istenen konular arasında
  • if let ifadesinin logical AND desteklemesi gerektiği öneriliyor
    • İstenen biçim: if let Some(x) = some_var && some_expr { }
    • Mevcut dolaylı çözüm (some_var, check_foo()) tuple matching, ancak some_var None olsa bile check_foo() çalıştığı için normal if short-circuit davranışıyla aynı değil
    • Örnek: Playground
  • raw pointer ergonomics de iyileştirilmesi gereken alanlardan biri olarak anılıyor
    • Referanslarda myref.x yazılabilirken pointer'larda (*myptr).x veya (*(*myptr).p).y yazmak gerekiyor
    • Görüşe göre unsafe kod mümkün olduğunca kolay okunur ve yazılır olmalı
  • built-in collection type'ların küresel allocator yerine kurucuda Allocator'ı açıkça alacak şekilde değiştirilmesi öneriliyor
  • async için de iyileştirmeler gerektiği, ancak bunun ayrı bir yazı gerektirecek kadar geniş bir konu olduğu belirtiliyor

Uyumluluk ve uygulanabilirlik

  • Önerilerin çoğu mevcut Rust ile uyumlu değil
  • Güvenlik capability'lerinin eklenmesi bile crate'ler için semver uyumluluğunu bozan yeni türde hata koşulları yarattığından yeni bir Rust edition gerektiriyor
  • Birkaç yıl önce olsa RFC yazılabileceği, ancak uzun GitHub RFC yorum süreçlerinden geçip bir başka hayata geçmemiş fikir haline gelmekten kaçınılmak istendiği söyleniyor
  • Sonunda düşünce yine derleyiciyi bizzat fork etme fikrine dönüyor, ancak yapılması gereken çok fazla proje olduğu için bunun önünde gerçekçi kısıtlar bulunduğu kabul ediliyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-27
Hacker News yorumları

  • Rust RFC sürecinin iyi fikirlerin mezarlığı olduğu söylenir ama bunun aksine, Rust çekirdek ekibinin programlama diline yeni özellik eklemeyi zorlaştırmasının doğru yönde olduğunu düşünüyorum
    Dilin yüzeyinin şişkin, tutarsız ve öngörülemez hale gelmesi engellenmeli. Swift’i de başta sevmiştim, ama isMultiple(of:) gibi mükerrer fonksiyon adları, SwiftUI için süslü parantez ayrıştırma kuralları, referans/değer tipi ve değiştirilebilirlik kuralları, closure argümanları için kısa gösterimler derken bunlar sürekli arttı ve sonunda vazgeçtim. İyi fikirler bol; Rust’ın mümkün olduğunca yalın kalmasını isterim

    • Asıl yazının yazarıyım. Rust kullanırken X özelliği ve Y özelliği ayrı ayrı desteklense de birlikte kullanılamadıkları boşluklar sık sık karşınıza çıkıyor
      Örneğin impl Trait döndüren fonksiyonlar kullanılabiliyor ve struct’lar rastgele alanlara sahip olabiliyor, ama impl Trait ile döndürülen bir değeri bir struct alanına koyamıyorsunuz. Çünkü tipe ad veremiyorsunuz. if a && b ve if let Some(x) = x çalışıyor, ama if let Some(x) = x && b çalışmıyor. Bunların düzeltilmesini isterim. Derleyici kod satırı sayısı açısından Rust büyür; ama öğrenme ve kullanım karmaşıklığı açısından bu tür özellik boşlukları dili aslında daha karmaşık hale getiriyor. Pin’i standart kütüphanede uygulamak büyük bir iş değildi, ama hiç de yalın bir özellik değil ve bilişsel yükü muazzam. Basit bir derleyici ve kullanması zor bir dil yerine, karmaşık bir ödünç alma denetleyicisi ve okunması kolay Rust kodu bana daha iyi geliyor
    • RFC yazmak, onu uygulamaktan daha kolaydır; ayrıca RFC yazabilecek kişi sayısı da daha fazladır. Bu yüzden popülerlik seviyesi ne olursa olsun RFC kuyruğu kaçınılmaz olarak iyi fikirlerin mezarlığı gibi görünür
      Bekleyen fikirlerin %100’ü kabul edilip eninde sonunda üzerinde çalışılsa bile, içeri girme hızıyla dışarı çıkma hızı arasındaki fark yüzünden böyle görünür. RFC yazarlarının önüne geçmek istiyorsanız RFC yazmak yerine, belgeleri ve testleriyle birlikte üretime hazır bir uygulama yapıp ağaca temiz biçimde birleştirilebilir hale getirmek daha iyi olur
    • Genel olarak katılıyorum, ancak trait’lerdeki generic ilişkili sabitler kararlı hale gelmişken gerçek sabitler gibi kullanılamadıkları paradoksal bir durumda
      Ne başka bir tipin const generic’i olarak ne de dizi uzunluğu olarak kullanılabiliyorlar. Sadece bir değere ihtiyacınız varsa bir fonksiyon tanımlayıp döndürebilirsiniz; dolayısıyla şu an pek işe yaramıyorlar. Düzgün desteklenirse kriptografi kütüphanelerindeki generic_array, typenum gibi yardımcı crate’ler ortadan kalkabilir. Yine de Rust ekibinin özellik eklerken temkinli olması gerektiğine katılıyorum
    • Rust, zaten belli ölçüde ana akım olan programlama dilleri arasında Wagyu gibi bir durumda; yenemeyecek kadar fazla yağ eklenmemeli
    • İyi fikirler tanım gereği nadir ve değerli şeylerdir

  • Bağımlılık durumu oldukça ciddi, ama bunu kabul etmeye pek istekli olan yok gibi görünüyor. Yakın zamanda gördüğüm örnek cargo-watch crate’i
    Özünde dosya değişikliklerini izleyip derleyiciyi yeniden çalıştıran basit bir uygulama ve implementasyonu 1.000 satır bile değil. Ama bağımlılıkları vendoring yaparsanız, 8.000’den fazla dosyaya yayılmış Rust kodu neredeyse 4 milyon satıra çıkıyor. Basit bir dosya izleyici için fazla
    https://crates.io/crates/cargo-watch

    • Geçişli bağımlılıkları kolayca oluşturursanız ve “bir kütüphane varsa mutlaka kullanılmalı” kültürü varsa, kaçınılmaz olarak böyle olur
      C/C++, yaygın kullanılan diller arasında npm tarzı bir paket yöneticisinin popüler olmadığı neredeyse tek örnek; bu yüzden çoğu kütüphane kendi kendine yeterli ya da az ve çoğunlukla isteğe bağlı bağımlılığa sahip. efsw, bağımlılığı olmayan 7.000 satırlık bir C++ dosya sistemi izleyicisi. Oyun programlama tarafındaki tek header’lı kütüphaneler olan stb_*, cgltf ve Dear ImGui, kullandıklarım arasında en rahat olanlardı. Yeni bir paket yöneticisinde geçişli bağımlılık yasağının genel olarak faydalı olabileceğini düşünüyorum. Büyük kütüphane bağımlılıkları kullanıcıya doğrudan kurdurulabilir, callback sağlanabilir ya da standart özellik hâline getirilebilir
      https://github.com/SpartanJ/efsw
      https://github.com/nothings/stb
      https://github.com/jkuhlmann/cgltf
      https://github.com/ocornut/imgui
    • Günümüzde bağımlılık cangılı işleri bitirmenin olağan yolu. Bir runtime’ın yapabileceği en iyi şey bunu kabullenmek, olabildiğince hızlı ve güvenli hâle getirmek ve standart kütüphaneyi genişleterek minimum bağımlılıklı projeleri de desteklemek
      Dosya izleyicilerin, özellikle birden fazla platform destekliyorsa, hiç de basit olmadığını düşünüyorum
    • Doğal ve çok da korkutucu olmayan bir olgu. Tüm kodlar, kullandığından çok daha fazla işlev barındıran bir bağımlılık sıradağının üzerinde duruyor
      cargo watch’ın bir kısmı Win32 API wrapper kütüphanesini getiriyor; bu, Win32 çağrıları için otomatik üretilmiş binding’ler olduğundan devasa olmak zorunda. Çoğu dilin standart kütüphanesi de milyonlarca satırdır ve uygulama bunun yalnızca bir kısmını kullanır. C++’taki Boost da canavar gibi büyük, ama geliştiriciler yalnızca bazı uzantılarını alıp kullanıyor. Hatta isOdd ya da is even gibi tek bir paketin ekosistemi bozabildiği npm tarzı cehennem yerine, birçok kişinin bakımını yaptığı ve bağımlı olduğu daha az sayıda büyük bağımlılık daha iyi; Rust da genel olarak buna daha yakın
    • İş yerinde bilinçli olarak çeşitli bağımlılıkları kaldırıp yeniden yazıyoruz, ama bu proje için uygun kod satırı sayısını tahmin etmek açısından 1.000 satır da 4 milyon satır da hatalı görünüyor
      cargo-watch’ın bağımlılıklarının çoğu clap, cargo_metadata, watchexec adlı üç doğrudan gereksinimden geliyor gibi. clap platforma özgü birçok CLI öğesini içeri çekiyor, cargo_metadata ise kaçınılmaz olarak serde ailesinden çok şey getiriyor. watchexec tarafında iyileştirme alanı var: aynı organizasyonun yönettiği command-group’a bağımlı ve bu da koşulsuz olarak Tokio gerektiriyor. Daha büyük sorun, başka crate’lerin aşırı bağımlılıklarını kolayca düzeltememek. Eski bir watchexec’e bağlı bir crate varsa bunu Cargo.lock ayarıyla uydurabildiğiniz durumlar olabilir, ama genelde zor ve [patch] ile etrafından dolaşmak gerekir. Belirli bir crate sürümünün yerine geçecek bir “stand-in”i kolayca tanımlamanın bir yolu olsa iyi olurdu; ancak mevcut paket yöneticileri için büyük bir araştırma problemi gibi duruyor
    • Satırların çoğu muhtemelen üretilmiş Windows API crate’lerinden gelmiştir. Bunlar devasa olmalarıyla kötü ünlü

  • Rust artık ilginç ve yeni bir dil değil; geniş çaplı benimsenmeye doğru ilerleyen bir aşamada. Özellik geliştirmesinin yavaşlaması doğal ve sağlıklı
    Şu anda tasarım hataları düşük hızdan çok daha zararlı. Rust’ı ilginç kılan şey havalı özellikleri değil; bellek güvenli, garbage collection’sız ve production’a hazır yeni bir dil sınıfı olması. Önemli yerlerde fiilen benimsenmesi, dili daha iyi yapmaktan daha ilginç; bunun kolaylaşması için de dikkatli yönetildiğine dair güven gerekiyor

    • JavaScript de benzer bir yaşam evresinde sayılabilir, ama son 10 yılda harika yeni özellikler yığınla eklendi
      Spread operatörü, generator fonksiyonları, async, arrow function’lar, leftpad, yeni Date vb. önemli özelliklerin listesi bitmiyor. JS, Rust’tan çok daha eski ve çok daha yaygın kullanılıyor; ayrıca birden fazla production implementasyonu var, dolayısıyla yeni özelliklerin hepsini uyumlu biçimde uygulamaları gerekiyor. ES5 civarında bir duraklama dönemi vardı, ama fark ECMAScript standart komitesinin aklını başına toplamasında gibi görünüyor
    • Ada/SPARK çok eskiden beri vardı; gerçekten yeni bir dil sınıfı mı emin değilim. SPARK, biçimsel doğrulamayı da içererek güvenliği daha ileri taşıyor

  • Rustacean’ların her şeyi Rust ile yeniden yazma konusunda takıntılı olması yüzünden, Rust’ı yeniden yazmakla ilgili bir yazının meta hiciv şakası olacağını gerçekten düşünmüştüm

    • Bu zaten tarih öncesi çağlarda olmuş bir şey. Rust başlangıçta OCaml ile yazılmıştı, ama sonunda Rust ile yeniden yazıldı
    • Orijinal yazının yazarıyım. Başlıkta hedeflediğim gönderme tam da buydu
    • Onlar her şeyi Rust ile yeniden yazdırmak istiyor; size, ya da bize. Kendilerine değil
    • Programlama dili insanları bootstrapping’i de sever. Rust’ı Rust ile yazmak o kadar da saçma değil

  • Önce yavaş karar alma süreçlerinden şikâyet edip, sonra da kararlı hale gelmeme nedenleri karar alma ile pek ilgisi olmayan özellikleri sıralaması biraz tuhaf
    Örneğin coroutine'ler, düzgün çözülmesi zor uç durumlar olduğu için takılmış durumda. Derleyicinin içinde “sadece açınca çalışan” tamamlanmış bir uygulama yok; birçok durumda çalışan ama kararlı sürümde etkinleştirilemeyecek tamamlanmamış bir uygulama var. Fonksiyon trait’leri de çeşitli teknik nedenler ve gelecekteki özelliklerle etkileşimleri yüzünden mevcut halleriyle kararlı hale getirilmemesine açıkça karar verilmiş durumda. Geçmişe dönülse farklı tasarlanacak kısımlar olabilir, ama çoğu, Rust’ın ilk dönemlerinde ekip ve kaynakların çok daha küçük olduğu zamanlarda alınan kararlarla ilgili. Bugün daha iyi seçimler yapılabilir diye Rust 2.0 tarzı bir kopuş yaratma fikri de düşünülebilir; ancak Python 2’den 3’e geçişteki felaket çok büyük olduğu için birçok kişi pürüzlü kenarlara katlanmanın daha iyi olduğunu düşünüyor. Rust haftalık bültenine bakarsanız RFC onayları ve kararlı hale getirme kararları her hafta işleniyor. Çok uzun süren durumlar elbette var, ama insan, koordinasyon ve zaman eksikliği sorunlarını çözmek çoğu zaman teknik sorunları çözmekten daha zor

  • Bu yazı, Josh Triplett’in Reddit yanıtıyla birlikte okunmalı. Yazıdaki temel örneklerden biri olan Mutex basbayağı yanlış
    https://old.reddit.com/r/rust/comments/1fpomvp/rewriting_rus...
    Düzeltme: Aynı yorum burada da var
    https://news.ycombinator.com/item?id=41655268

  • Rust’ı öğrenirken ilk hissettiğim şey, hayal edilebilecek neredeyse her özelliğin zaten içinde varmış gibi görünmesiydi
    Bu, Rust ekibinin hiçbir şeyi reddetmediği anlamına gelmiyor; ama yine de insanlar daha fazla özellik istiyor. Bazıları haklı olabilir, ama bazıları geliştiricilerin %2’sinin kullanacağı bir özelliğin, geliştiricilerin yalnızca %1’inin anladığı bir dile mutlaka eklenmesi gerektiği gibi görünüyor. Karmaşık bir dilin daha da karmaşık hale gelmesine gerek yok. Zig daha basit ve muhtemelen daha hızlı; topluluk dramı da çok daha az. Zig’e daha fazla fon gitmesini isterim

    • Rastgele kişilerin önerip Rust topluluğu tarafından reddedilen epey özellik olduğunu öğrenince şaşırabilirsiniz
      Rust mümkün olan her özelliği eklemeye çalışmıyor. Ancak GAT veya TAIT gibi şeylerin hangi sorunu çözdüğünü net bilmiyorsanız böyle hissedilebilir. Zig iyi ve modern bir dil olabilir, ama hedefiniz bellek güvenliği ise bir seçenek değil
    • Asıl yazının yazarıyım. Rust’ın karmaşıklık bütçesinin büyük ölçüde yanlış yerlere harcandığını düşünüyorum
      Örneğin Pin ile future’ların etkileşimi dile akıl almaz bir karmaşıklık ekliyor ve bunun bir kısmının gereksiz olduğunu düşünüyorum. Pin’in hiç olmadığı Rust benzeri bir dil olmasını isterdim. Ödünç alma denetleyicisini de hem sözdizimi hem uygulama tarafında basitleştirmenin yolları olabilir gibi geliyor, ama henüz somut olarak düşünmedim. Şimdilik dili fork’lamadıkça bunu değiştirmek zor olur; ancak ödünç alma denetleyicisi kullanan son dil Rust olmayacak. Bir sonraki nesilde daha büyük bir dil yaratmadan da iyileştirme için çok yer olacağını umuyorum
    • Daha fazla fon gelmesi, kötü türden insanları çekebilir. Onların berbatlığı ve zarar verme potansiyeli bazen ancak çok geç ortaya çıkıyor
    • Rust topluluğundaki hangi dramdan bahsedildiğini merak ediyorum
      Rust ile ilgili dram görüyorum, ama genelde Rust’ın kullanımına veya benimsenmesine direnen taraftan çıkıyor. Yakın zamandaki Rust for Linux gürültüsü gibi. Topluluk içinde yaygın bir şey gibi görünmüyor; belki kaçırdığım bir şey vardır. Zig harika, ama henüz prodüksiyona hazır değil
    • Nightly’de gömülü duran özellik mezarlığı gerçekten epey büyük. Specialization gibi önemli özellikler de sonsuza dek orada takılı kalmış durumda

  • Bağlantısı verilen yorumun yazarı, çeşitli dillerdeki senkronizasyon temel öğelerini kapsamlı biçimde analiz ettikten sonra Rust’ın Mutex ve RwLock gibi senkronizasyon temel öğelerini, her büyük işletim sisteminde alttaki OS primitive’lerini doğrudan kullanacak şekilde yeniden yazmış
    Linux’taki futex gibi şeyleri kullanarak bunları daha hızlı, daha küçük ve genel olarak daha iyi hale getirmiş; bu süreçte fiilen Rust paralel programlama kitabını da yazmış. Rust dışındaki paralel programlama için de faydalı
    https://www.oreilly.com/library/view/rust-atomics-and/978109...
    7 yıl boyunca coroutine tarafında sadece oyalanmış da değiller. Async fonksiyonlar, async fonksiyonlar içerebilen trait’ler, AsyncWrite ve AsyncRead standartlaştırması için gereken çeşitli özellikler eklediler; nightly’de generator uygulaması da var. Tam anlamıyla genel coroutine’lerin karmaşıklığını üstlenip üstlenmemek ya da generator’larda durmak da tartışılıyor. AsyncIterator gibi bazı özellikler yavaş ilerliyor ama aktif çalışma da çok. Bir tarafta dilin fazla yavaş olduğunu, diğer tarafta fazla hızlı olduğunu söyleyip şikâyet edilmesi her zaman ilginç
    Function trait’leri ve effect system konusunda da yakın zamanda büyük tasarım keşifleri yapıldı; async, try, const kombinasyonlarının her biri için fonksiyonları tekrar tekrar yazdırmayacak bir çözüm üretmek istiyorlar. Kötü niyetli crate’leri sandbox’a almak dil düzeyinde bir mesele değil; doğrulayıcı ile runtime sandbox kombinasyonu gerektiriyor ve WebAssembly component’leri daha olası görünüyor. Buna karşın allocator veya async runtime seçimi, 64-bit platform varsayımı gibi derleme zamanı capability’lerine çok ilgi var; proc macro sandboxing’i ise kötü niyeti önlemek için değil, doğru caching için istiyorlar
    Kendine referans veren struct’lar bir sözdizimi sorunu değil, borrow checker’ın işlemesi çok zor olan bir sorun. Kısmi ödünç alma closure capture’da zaten destekleniyor; ancak bunu public API’ye açarken kararlı semantik sürümlemeyi nasıl koruyacağımız kilit nokta. İsimli “borrow group” gibi yaklaşımlar güçlü aday. comptime tarafında da çeşitli yönlerde çalışmalar sürüyor ve macro_rules’u güçlendiren bir RFC de yakın zamanda yazıldı. Range için impl, edition üzerinden uyumsuz değişiklikle birlikte zaten ilerliyor. if let ile mantıksal AND birleşimi için unstable bir özellik var ve stabilize edilmeye yakın. Pointer field erişim sözdizimini iyileştirmeye yönelik birkaç öneri de vardı; ancak dil yüzeyini daha da büyütmenin kazanç mı kayıp mı olduğu açık bir soru. Rust edition’ları sayesinde, yeterince ikna edici bir tasarım varsa değiştirilebilecek çok şey var. 700 unstable özellik gerçek bir sorun; stabilize edilme olasılığı düşük olanları temizlemek için büyük bir çalışma gerekiyor

    • Standart kütüphane düzeyindeki temel paket geliştirme böyle yapılmalı. Bugün kullandığımız diller önümüzdeki onlarca yıl boyunca kullanılacak ve bugün yavaş ama iyi kararlar almak, ileride çok daha fazla zaman kazandırır
    • proc macro ve build script sandboxing üzerine çok tartışma oldu
      Daha deklaratif macro’lar, -sys crate mantığının paylaşımlı kütüphanelere devredilmesi, cfg(version) / cfg(accessible) kullanıcı tarafında implementasyon ihtiyacını epey azaltacaktır; ancak runtime yine de kalır. Üzerinde düşündükçe cackle’ın ACL’i, proc macro, build script ve runtime kodunun tamamında işlemleri izlemek ve dependency tree kullanımını denetlemek için ölçeklenebilir bir yöntem olarak iyi görünüyor. cargo-redpen’in de çağrı denetim aracı olarak gelişmekte olduğunu duydum ama cackle gibi daha yüksek bir seviyeyi hayal ediyorum
      https://github.com/cackle-rs/cackle
    • Orijinal yazının yazarıyım. İçeriden bakışı ayrıntılı dinleyebilmek güzel
      İnsanların Rust’ın büyük bir dil olduğundan ve daha da büyümesini istemediklerinden şikâyet etmesini anlıyorum; ama mevcut yarı pişmiş async implementasyonunu korumak dili daha küçük ya da daha basit yapmıyor. Sadece dili daha kötü yapıyor. Kısmi ödünç alma public API’de değilse bile en azından aynı crate içinde çalışsa iyi olurdu. Gerçek programlama sırasında sürekli karşılaşılan bir sorun. Kötü niyetli crate sandboxing’inin neden dil düzeyinde imkânsız olduğu da benim için soru işareti. Çağrı ağacında unsafe üçüncü taraf kodu olmayan ve sistem çağrısı da yapmayan bir fonksiyon, zaten yalnızca kendisine iletilmiş argümanlarla, yerel değişkenlerle ve scope içindeki global’lerle uğraşabilir. Bu duvar güçlendirilip bir güvenlik sınırı olarak kullanılabilirse, dependency supply chain riskini ciddi ölçüde azaltabilir gibi görünüyor

  • Rust’ın görevi en başından beri performans, güvenlik ve ifade gücünü birleştiren zor bir işti; Mozilla’nın çekilmesiyle kurucu modunu kaybetti ve ilk çekirdek ekibin de çoğu ayrıldı, bu yüzden ilerlemenin yavaşlaması şaşırtıcı değil
    Kişisel olarak bunun yanlış yola sapmaktan daha iyi olduğunu düşünüyorum

  • Rust’ı yeniden yazsaydım, daha fazla özellik eklemekten çok azaltma yönüne giderdim
    QBE’nin LLVM’e karşı yaptığı gibi, kodun %10’uyla Rust’ın %70’ini sunmak gibi. Macro’lar ve nadiren kullanılan bazı özellikler çıkarılırsa belki mümkün olabilir
    https://c9x.me/compile/

    • QBE’yi küçümsemek istemem ama QBE’nin ilk hedefi kodun %10’uyla performansın %90’ını sunmaktı; daha sonra %70’e değişti
      Rust ya da başka bir şey için, gerçekten denemeden bunun ne kadar mümkün olduğunu bilmek zor