Graydon Hoare’ın 2006’daki deneyinden günümüz Rust ekosistemine: çöp toplayıcı olmadan bellek güvenliğinin sistem programlamayı nasıl yeniden şekillendirdiğini görün.
Bu makale odaklı bir köken hikâyesi anlatır: Graydon Hoare’ın kişisel deneyi nasıl Rust’a dönüştü ve neden Rust’ın tasarım seçimleri sistem programlama beklentilerini değiştirecek kadar önemliydi.
“Sistem programlama” makineye ve ürününüzün riskine yakın çalışır. Tarayıcılarda, oyun motorlarında, işletim sistemi bileşenlerinde, veritabanlarında, ağda ve gömülü yazılımlarda karşımıza çıkar—genellikle şunlara ihtiyaç duyduğunuz yerlerde:
Tarihsel olarak bu kombinasyon ekipleri C ve C++’a yönlendirdi; ayrıca bellekle ilgili hataları azaltmak için kapsamlı kurallar, incelemeler ve araçlar kullanıldı.
Rust’ın başlıktaki vaadi söylemesi kolay ama uygulaması zor bir şeydir:
Çöp toplayıcı olmadan bellek güvenliği.
Rust, use-after-free, double-free ve birçok veri yarışı türü gibi yaygın hataları önlemeyi hedefler—bunu programı periyodik olarak durduran bir çalışma zamanı yerine, sahiplik ve ödünç alma yoluyla derleme zamanında yapar.
Tarihçeyi (erken fikirlerden Mozilla’nın katılımına), ana kavramları (sahiplik, ödünç alma, yaşam süreleri, safe vs unsafe) sade bir dille alacaksınız.
Almayacağınız şey tam bir Rust eğitimi, sözdizimi turu ya da adım adım proje kurulumu. Bunu Rust’ın tasarımının “neden”i olarak düşünün; fikirleri somut yapan yeterli örneklerle.
Yazar notu: tam metin ~3.000 kelime hedefli; kısa örneklere yer verilecek ancak bir referans kılavuzuna dönüşmeyecek.
Rust, bir komite tarafından tasarlanmış “yeni C++” olarak başlamadı. 2006’da Graydon Hoare’ın kişisel bir deneyi olarak başladı—daha geniş ilgi çekmeden önce bağımsız yürüttüğü bir çalışma. Bu köken önemli: birçok erken tasarım kararı, dil teorisini “kazanmak” için değil, günlük acıları çözmek için yapılmış gibi okunuyor.
Hoare, çöp toplayıcıya güvenmeden düşük seviyeli, yüksek performanslı yazılım yazmanın yollarını araştırıyordu—aynı zamanda C ve C++’taki en yaygın çökme ve güvenlik hatalarından kaçınmak istiyordu. Bu gerilim sistem programcılarına tanıdık:
Rust’ın “çöp toplayıcı olmadan bellek güvenliği” yönü başlangıçta pazarlama sözü değil, bir tasarım hedefiydi: sistem işi için uygun performans özelliklerini koruyun, ama birçok bellek hatasını ifade etmeyi zorlaştırın.
Neden bunun “sadece C/C++ için daha iyi bir derleyici” olmadığını sormak makul. Statik analiz, sanitizer’lar ve daha güvenli kütüphaneler birçok sorunu önler, ama genellikle bellek güvenliğini tamamen garanti edemezler. Altta yatan diller, dışarıdan tamamen denetlenmesi zor kalıplara izin verir.
Rust’ın iddiası, kilit kuralları dilin ve tip sisteminin içine taşımaktı ki güvenlik bir varsayılan sonuç olsun; yine de açıkça işaretlenmiş kaçış kapılarıyla manuel kontrol sağlanabilsin.
Rust’ın ilk günlerine dair bazı ayrıntılar anekdot olarak dolaşır (konuşmalarda ve röportajlarda sıkça tekrarlanan). Bu köken hikâyesini anlatırken, 2006 başlangıç tarihi ve Rust’ın daha sonra Mozilla Research tarafından sahiplenilmesi gibi geniş belgelenmiş dönüm noktalarını kişisel anılardan ve ikincil aktarımlardan ayırmak faydalı olur.
Birincil kaynaklar için erken Rust belgeleri ve tasarım notları, Graydon Hoare konuşmaları/röportajları ve projeyi neden benimsediklerini anlatan Mozilla/Servo dönemi yazılarına bakabilirsiniz; ilgili blog yazılarını incelemek de yararlı olacaktır.
Sistem programlama çoğunlukla donanıma yakındır. Bu yakınlık kodu hızlı ve kaynak açısından verimli kılar. Aynı zamanda bellek hatalarının cezalandırıcı olmasının sebebidir.
Tekrarlanan birkaç klasik hata vardır:
Bu hatalar her zaman açık değildir. Bir program haftalarca “çalışıyor” olabilir, sonra nadir bir zamanlama veya girdi örüntüsünde çöker.
Testler, denediğiniz durumların işe yaradığını kanıtlar. Bellek hataları genellikle denemediklerinizde saklanır: alışılmadık girdiler, farklı donanım, küçük zamanlama değişiklikleri veya yeni bir derleyici sürümü. Ayrıca deterministik olmayabilirler—özellikle çok iş parçacıklı programlarda—bu yüzden hata, günlük eklediğinizde veya bir hata ayıklayıcı bağladığınızda kaybolabilir.
Bellek yanlış gittiğinde sadece temiz bir hata almazsınız. Bozulmuş durum, öngörülemeyen çökmeler ve saldırganların aktif olarak aradığı güvenlik açıklarıyla karşılaşırsınız. Ekipler, yeniden üretmesi zor ve teşhis etmesi daha da zor arızaların peşinden koşmak için büyük çaba harcar.
Düşük seviyeli yazılım her zaman maliyeti ağır runtime kontrolleri veya sürekli bellek taramasıyla “ödeyemez”. Hedef, paylaşılan bir atölyeden bir aleti ödünç almak gibidir: özgürce kullanabilirsiniz, ama kurallar net olmalı—kim tutuyor, kim paylaşabilir ve ne zaman geri verilmeli. Geleneksel sistem dilleri bu kuralları insan disiplinine bıraktı. Rust’ın köken hikâyesi bu takasın sorgulanmasıyla başlar.
Çöp toplama (GC), dilleri bellek hatalarından korumanın yaygın bir yoludur. Programcıların belleği manuel olarak serbest bırakması yerine, çalışma zamanı hangi nesnelerin erişilebilir olduğunu izler ve geri kalanını otomatik olarak serbest bırakır. Bu, use-after-free, double-free ve birçok sızıntı kategorisini ortadan kaldırır—çünkü program artık aynı şekilde “temizlemeyi unutamaz.”
GC “kötü” değildir, ama bir programın performans profilini değiştirir. Çoğu toplayıcı şu kombinasyondan bazılarını getirir:
Birçok uygulama için bu maliyetler kabul edilebilir veya görünmezdir. Modern GC’ler mükemmeldir ve geliştiricilerin üretkenliğini dramatik şekilde artırır.
Sistem programlamada en kötü durum genellikle en çok önem taşıyanıdır. Bir tarayıcı motoru pürüzsüz render gerektirir; bir gömülü kontrolör katı zamanlama kısıtlarına sahip olabilir; düşük gecikmeli bir sunucu yük altında kuyruk sonu gecikmesini sıkı tutmak isteyebilir. Bu ortamlarda “çoğunlukla hızlı” olmak, “tutarlı ve öngörülebilir” olmaktan daha az değerli olabilir.
Rust’ın büyük vaadi şuydu: C/C++ benzeri kontrolü koruyun, ama çöp toplayıcıya güvenmeden bellek güvenliği sağlayın. Amaç, güvenli kodu varsayılan hale getirirken performans özelliklerinde öngörülebilirliği korumaktı.
Bu, GC’nin kötü olduğu iddiası değildir. Bunun yerine, düşük seviyeli kontrol ve modern güvenlik garantilerini birlikte isteyen geniş ve önemli bir orta zemin olduğunu varsayar.
Sahiplik Rust’ın en temel fikridir: her değerin onu artık kimse kullanmadığında temizlemekle sorumlu tek bir sahibi vardır.
Bu tek kural, C ve C++ programcılarının sıklıkla kafalarında tuttuğu “bunu kim temizleyecek?” defterinin büyük kısmını ortadan kaldırır. İnsan disiplinine güvenmek yerine Rust, temizlemeyi öngörülebilir kılar.
Bir şeyi kopyaladığınızda, iki bağımsız kopya elde edersiniz. Bir şeyi taşıdığınızda, orijinali teslim edersiniz—taşımadan sonra eski değişken artık onu kullanamaz.
Rust birçok heap-üzerindeki değeri (stringler, buffer’lar, vektörler gibi) varsayılan olarak taşınan olarak ele alır. Bunları düşüncesizce kopyalamak hem pahalı olabilir hem de kafa karıştırıcı: iki değişken aynı tahsise “sahip” olduğunu düşünürse, bellek hatalarına davetiye çıkmış olur.
Aşağıda küçük bir yalancı-kod fikri var (kod bloğu olduğu gibi korunur):
buffer = make_buffer()
ownerA = buffer // ownerA owns it
ownerB = ownerA // move ownership to ownerB
use(ownerA) // not allowed: ownerA no longer owns anything
use(ownerB) // ok
// when ownerB ends, buffer is cleaned up automatically
Her zaman tam olarak bir sahibi olduğu için, Rust bir değerin ne zaman temizleneceğini bilir: sahibi kapsamdan çıktığında. Bu, otomatik bellek yönetimi sağlar (her yerde free() çağırmanıza gerek yok) ama programı tarayan bir çöp toplayıcıya ihtiyaç duymaz.
Bu sahiplik kuralı birçok klasik problemi engeller:
Rust’ın sahiplik modeli sadece daha güvenli alışkanlıkları teşvik etmez—birçok tehlikeli durumu temsil edilemez hale getirir; bu, Rust’ın diğer güvenlik özelliklerinin üzerine kurulduğu temeldir.
Sahiplik, bir değere “kim sahip” olduğunu açıklar. Ödünç alma, programın diğer bölümlerinin o değeri geçici olarak nasıl kullanabileceğini açıklar—sahipliği almadan.
Rust’ta bir şeyi ödünç aldığınızda, ona bir referans elde edersiniz. Orijinal sahibi belleği serbest bırakmaktan sorumludur; ödünç alan sadece onu bir süre kullanma izni alır.
Rust’ın iki tür ödünç alma şekli vardır:
&T): sadece okuma erişimi.&mut T): okuma-yazma erişimi.Rust’ın merkezi ödünç alma kuralı söylemesi basit ama pratikte güçlüdür:
Bu kural, programın bir bölümünün veriyi okurken diğerinin gizlice değiştirmesini önler.
Bir referans, işaret ettiği şeyden daha uzun yaşamamalıdır. Rust buna yaşam süresi der—referansın güvenli olduğu süre aralığı.
Bu fikri kullanmak için formalizme gerek yoktur: bir referans, sahibi gittikten sonra ortada kalmamalıdır.
Rust, bu kuralları derleme zamanında borrow checker aracılığıyla uygular. Kötü bir referans veya riskli bir değişiklik umuduyla testlere kalmak yerine, Rust potansiyel bellek yanlış kullanımı üretebilecek kodun derlenmesine izin vermez.
Paylaşılan bir belge düşünün:
Eşzamanlılık, “makinemde çalışıyor” hatalarının saklandığı yerdir. İki iş parçacığı aynı anda çalıştığında, paylaşılan veriler beklenmedik şekilde etkileşime girebilir.
Veri yarışı şu durumlarda oluşur:
Sonuç sadece “yanlış çıktı” değildir. Veri yarışları durumu bozabilir, programları çökertir veya güvenlik açıkları yaratır. Daha da kötüsü, kesintisel olabilir: günlük eklendiğinde veya hata ayıklayıcı bağlandığında hata ortadan kalkabilir.
Rust alışılmadık bir duruş alır: her programcının her seferinde kuralları hatırlayacağına güvenmek yerine, birçok güvenli olmayan eşzamanlılık kalıbını güvenli kodda temsil edilemez hale getirmeye çalışır.
Genel olarak Rust’ın sahiplik ve ödünç alma kuralları tek iş parçacıklı kodla sınırlı kalmaz; aynı zamanda hangi şeylerin iş parçacıkları arasında paylaşılıp paylaşılamayacağını da şekillendirir. Derleyici paylaşılan erişimin koordine edildiğini kanıtlayamazsa, kodun derlenmesine izin vermez.
Bu, Rust’ta güvenli eşzamanlılık olarak adlandırılan şeyin özüdür: hâlâ eşzamanlı program yazarsınız, ama “eyvah iki iş parçacığı aynı şeyi yazdı” hatalarının büyük bir kategorisi program çalışmadan önce yakalanır.
İki iş parçacığının aynı sayacı artırdığını hayal edin:
Rust’ta güvenli kodda aynı değere çoklu değiştirilebilir erişim vermek mümkün değildir. Derleyici niyetinizi açıkça belirtmenizi zorunlu kılar—genellikle paylaşılan durumu bir kilidin arkasına koymak veya mesajlaşma ile erişimi koordine etmek gibi eşzamanlılık ilkelikleri kullanılmalıdır.
Rust düşük seviyeli eşzamanlılık numaralarını yasaklamaz. Onları karantinaya alır. Derleyicinin genelleştirilmiş güvenliğini kanıtlayamadığı bir şey yapmanız gerektiğinde unsafe blokları kullanabilirsiniz; bunlar bir uyarı etiketi gibidir: “burada insan sorumluluğu gerekiyor.” Bu ayrım, kod tabanının çoğunu daha güvenli alt kümede tutarken, sistem seviyesi gücün gerekli olduğu yerde kullanılmasına izin verir.
Rust’ın güvenlik ünü mutlak gibi görünebilir, ama daha doğru olanı Rust’ın güvenli ile güvensiz programlama arasındaki sınırı açık ve denetlenebilir kılmasıdır.
Çoğu Rust kodu “güvenli Rust”tır. Burada derleyici use-after-free, double free, sarkan işaretçiler ve veri yarışları gibi yaygın bellek hatalarını engelleyen kuralları uygular. Mantık hatası yazabilirsiniz ama normal dil özellikleriyle kazara bellek güvenliğini ihlal edemezsiniz.
Önemli nokta: güvenli Rust “yavaş Rust” değildir. Derleyici kuralların uyulduğuna güvenince agresif optimizasyonlar yapılabilir; birçok yüksek performanslı program tamamen güvenli Rust ile yazılır.
“Unsafe”, bazen derleyicinin genel olarak güvenli olduğunu kanıtlayamadığı yeteneklere ihtiyaç duyulduğu için vardır. Yaygın nedenler şunlardır:
unsafe kullanmak tüm kontrolleri kapatmaz. Sadece normalde yasaklanan bir dizi işleve (ham işaretçilerin dereferans edilmesi gibi) izin verir.
Rust unsafe bloklarını ve fonksiyonlarını işaretlemeye zorlar; böylece risk kod incelemesinde görünür olur. Yaygın bir desen, küçük bir “unsafe çekirdeği” güvenli bir API ile sarmaktır; böylece programın çoğu güvenli Rust’ta kalırken küçük, iyi tanımlanmış bölüm gerekli invariyantları korur.
Unsafe’ı bir güç aracı gibi ele alın:
İyi yapıldığında, unsafe Rust sistem programlamanın hâlâ manuel hassasiyet gerektiren kısımlarına kontrollü bir erişim sağlar—kodun geri kalanında Rust’ın güvenlik faydalarını kaybetmeden.
Rust, akıllı fikirleri kağıt üzerinde olduğu için “gerçek” olmadı—Mozilla bu fikirleri baskı altına alarak gerçeğe dönüştürdü.
Mozilla Research, performans kritik tarayıcı bileşenlerini daha az güvenlik hatasıyla inşa etmenin yollarını arıyordu. Tarayıcı motorları karmaşıktır: güvensiz girdileri ayrıştırır, büyük bellek hacimlerini yönetir ve yüksek paralellikte çalışır. Bu kombinasyon bellek güvenliği kusurlarını ve yarış koşullarını hem yaygın hem de pahalı hale getirir.
Rust’ı desteklemek bu amaçla örtüştü: sistem programlama hızını korurken belirli hata sınıflarını azaltmak. Mozilla’nın katılımı ayrıca dünyaya Rust’ın yalnızca Graydon Hoare’ın kişisel deneyi olmadığını, aynı zamanda gezegendeki en zorlu kod tabanlarından biriyle test edilebilecek bir dil olduğunu gösterdi.
Servo—deneysel tarayıcı motoru projesi—Rust’ı ölçekli olarak denemek için yüksek profilli bir yer oldu. Amaç tarayıcı pazarını “kazanmak” değil. Servo, derleyici teşhisleri, araçlar ve dil özelliklerinin gerçek kısıtlar altında değerlendirilmesi için bir laboratuvar işlevi gördü: derleme süreleri, çapraz platform destek, geliştirici deneyimi, performans ayarı ve paralellik altında doğruluk.
Servo ayrıca dil etrafında ekosistemin şekillenmesine yardımcı oldu: kütüphaneler, yapı araçları, yaklaşımlar ve hata ayıklama uygulamaları—oyuncak programların ötesine geçince önem kazanan şeyler.
Gerçek dünya projeleri, dil tasarımının sahte üretemeyeceği geribildirim döngüleri yaratır. Mühendisler sürtünme yaşadığında—anlaşılması zor hata mesajları, eksik kütüphane parçaları, garip kalıplar—bu acı noktaları hızla ortaya çıkar. Zaman içinde bu sürekli baskı, Rust’ı umut veren bir konseptten büyük, performans kritik yazılımlar için güvenilen bir şeye dönüştürdü.
Rust bir orta zemin arar: C ve C++’tan beklenen performans ve kontrolü hedefler, ama bu dillerin genellikle disiplini, testleri ve şansı bıraktığı birçok hatayı ortadan kaldırmaya çalışır.
C ve C++’ta geliştiriciler belleği doğrudan yönetir—ayırır, serbest bırakır ve işaretçilerin geçerliliğini sağlar. Bu özgürlük güçlüdür ama use-after-free, double-free, tampon taşmaları ve ince yaşam süresi hataları üretmeyi kolaylaştırır. Derleyici genellikle size güvenir.
Rust bu ilişkiyi tersine çevirir. Yine düşük seviyeli kontrol (stack vs heap kararları, düzen tahsisi, açık sahiplik transferleri) elde edersiniz, ama derleyici bir değerin kime ait olduğu ve referansların ne kadar süre yaşayabileceği ile ilgili kuralları zorlar. Rust, “işaretçilerle dikkatli ol” demek yerine “güvenliği derleyiciye kanıtla” der ve güvenli Rust’ta bu garantileri ihlal edebilecek kodu derlemez.
Çöp toplayıcılı diller (Java, Go, C# vb.) manuel bellek yönetimini üretkenlik karşılığında kolaylaştırır: nesneler erişilebilir olmadığında otomatik olarak serbest bırakılır. Bu büyük bir üretkenlik artışı olabilir.
Rust’ın vaadi—“çöp toplayıcı olmadan bellek güvenliği”—çalışma zamanı çöp toplayıcısı için ödeme yapmamanız demektir; bu, gecikme, bellek ayak izi, başlatma süresi veya sınırlı kaynaklı ortamlarda faydalı olabilir. Takas, sahipliği açıkça modellemek ve derleyicinin bunu zorlamasını kabul etmektir.
Rust ilk başta zor gelebilir çünkü yeni bir zihniyeti öğretir: işinizi işaretçi geçmek yerine sahiplik, ödünç alma ve yaşam süreleri açısından düşünerek yaparsınız. Erken sürtünme genellikle paylaşılan durum veya karmaşık nesne grafikleri modellemeye çalışırken ortaya çıkar.
Rust, güvenlik açısından hassas ve performans kritik yazılımlar—tarayıcılar, ağ, kriptografi, gömülü, katı güvenilirlik gerektiren backend servisler—için parlama eğilimindedir. Eğer ekibiniz düşük seviyeli kontrolden ziyade en hızlı yinelemeyi önceliklendiriyorsa, bir GC dili hâlâ daha iyi bir seçim olabilir.
Rust evrensel bir değişim değil; C/C++ performansı ve güvenlik garantilerini birlikte isteyen durumlar için güçlü bir seçenektir.
Rust, “daha hoş bir C++” olarak dikkat çekmedi. Düşük seviyeli kodun aynı anda hızlı, bellek güvenli ve maliyetler konusunda açık olabileceğini ısrarla savunarak konuşmayı değiştirdi.
Rust öncesinde ekipler bellek hatalarını performans için ödenen bir vergi olarak görür; sonra testi, kod incelemesini ve olay sonrası düzeltmeleri kullanarak riski yönetirlerdi. Rust farklı bir bahis oynadı: verilerin kime ait olduğu, kim değiştirebileceği ve referansların ne kadar süre geçerli olacağı gibi ortak kuralları dile kodlayın ki belli hata sınıfları derleme zamanında reddedilsin.
Bu değişim önemlidir çünkü geliştiricilerden “mükemmel olmalarını” istemez. Onlardan açık olmalarını ister—ve sonra bu açıklığı derleyicinin uygulamasına bırakır.
Rust’ın etkisi tek bir başlık yerine çeşitli sinyallerde görünür: performans hassas yazılım üreten şirketlerin artan ilgisi, üniversite derslerinde daha fazla yer alması ve paket yönetimi, formatlama, linting ve dokümantasyon iş akışları gibi günlük sürücü araçlarının olgunlaşması.
Bu, Rust’ın her zaman en iyi seçim olduğu anlamına gelmez—ama varsayılan olarak güvenliğin makul bir beklenti haline geldiğini gösterir.
Rust genellikle şunlar için değerlendirilir:
“Yeni standart”, her sistemin Rust’a yeniden yazılacağı anlamına gelmez. Daha ziyade çıtanın yükseldiği anlamına gelir: ekipler artık Neden bellek-güvensiz varsayılanları kabul edelim? diye daha sık soruyor. Rust benimsenmese bile modeli, daha güvenli API’lar, daha net invariyantlar ve doğruluk için daha iyi araçlar değerini artırdı.
Rust’ın köken hikâyesinin basit bir bağlantısı vardır: bir kişinin yan projesi (Graydon Hoare’ın yeni bir dil deneyi) inatçı bir sistem programlama sorunuyla çarpıştı ve çözüm hem katı hem de pratikti.
Rust birçok geliştiricinin kaçınılmaz sandığı bir takası yeniden çerçeveledi:
Pratik değişim sadece “Rust daha güvenli” demek değil. Dilin bir varsayılan özelliği olarak güvenliğin mümkün olduğunu göstermesidir—kod incelemeleri ve testlerle uygulanan iyi bir disiplin değil.
Merak ediyorsanız büyük bir yeniden yazmaya gerek yok; Rust’ın nasıl hissettirdiğini öğrenmek için küçük başlayın.
Küçük başlayın:
Nazik bir yol için bir “ince dilim” hedef seçin—ör. “bir dosya oku, dönüştür, çıktı yaz”—ve akıllı değil açık kod yazmaya odaklanın.
Eğer bir Rust bileşenini daha büyük bir üründe prototipleştiriyorsanız, çevre parçaları hızlı tutmak (admin UI, paneller, kontrol düzlemi, basit API’ler) yardımcı olabilir; Koder.ai gibi platformlar sohbet tabanlı iş akışıyla bu tür “bağlayıcı” geliştirmeyi hızlandırabilir—React ön yüzü, Go backend ve PostgreSQL şeması üreterek kaynağı dışa aktarabilir ve Rust servisinizi temiz sınırlar üzerinden entegre edebilirsiniz.
Sistem programlama, donanıma ve yüksek riskli ürün yüzeylerine yakın çalışan iş türüdür—örneğin tarayıcı motorları, veritabanları, işletim sistemi bileşenleri, ağ ve gömülü yazılım.
Genellikle tahmin edilebilir performans, düşük seviyede bellek/kontrol ve yüksek güvenilirlik gerektirir; çökme ve güvenlik hatalarının maliyeti özellikle yüksektir.
Rust, yaygın bellek hatalarını (use-after-free, double-free gibi) bir çöp toplayıcıya bağlı kalmadan önlemeyi hedefler.
Çöp toplayıcı yerine Rust, birçok güvenlik denetimini derleme zamanına taşır; bunlar sahiplik ve ödünç alma kuralları aracılığıyla sağlanır.
Sanitizer'lar ve statik analiz gibi araçlar birçok sorunu yakalayabilir, ama dilin izin verdiği tehlikeli işaretçi ve yaşam süresi kalıplarını tamamen garanti altına almakta yetersiz kalırlar.
Rust, temel kuralları dilin ve tip sisteminin içine yerleştirir, böylece derleyici belli kategorideki hataları varsayılan olarak reddeder; gerektiğinde açık kaçış yolları da sunar.
Çöp toplayıcı, çalışma zamanı yükü ve özellikle bazı iş yüklerinde daha az tahmin edilebilir gecikme (ör. duraklamalar) getirebilir.
Tarayıcılar, gerçek zamanı andıran kontrolörler veya düşük gecikmeli servisler gibi alanlarda en kötü durum davranışı önemlidir; bu yüzden Rust güvenliği hedeflerken daha öngörülebilir performansı korur.
Sahiplik, her değerin onunla ilgilenen tek bir sahibi olduğu fikridir; bu sahibi değer artık gerekmediğinde onu temizlemekle sorumludur.
Bu kural, C ve C++ programcılarının kafalarında tuttukları “bunu kim free() eder?” defterini gereksiz kılar ve temizlemeyi öngörülebilir hale getirir.
Bir taşıma (move) sahipliği bir değişkenden diğerine aktarır; orijinal değişken artık değeri kullanamaz.
Bu, iki değişkenin aynı tahsise sahip olduğu yanılgısını ve dolayısıyla double-free veya use-after-free gibi hataları engellemeye yardımcı olur.
Ödünç alma, bir değeri sahiplik almadan geçici kullanma izni verir—referans aracılığıyla.
Temel kural: çok okuyucu ya da bir yazıcı—aynı anda bir değere birden fazla paylaşılan referans (&T) olabilir veya tek bir değiştirilebilir referans (&mut T) olabilir, ama ikisi bir arada olamaz. Bu, okuma esnasında verinin değişmesini önler.
Bir yaşam süresi (lifetime), bir referansın ne kadar süreyle geçerli olduğunu belirtir. Rust, referansların işaret ettikleri veriden daha uzun yaşamasına izin vermez.
Borrow checker (ödünç denetleyici), derleme zamanında bu kuralları uygular; yığın dışı referanslar oluşturabilecek kod derlenmez.
Bir veri yarışması, birden fazla iş parçacığının aynı belleğe aynı anda erişmesi, en az birinin yazma olması ve erişimlerin koordine edilmemesi durumunda oluşur.
Rust’ın sahiplik/ödünç kuralları eşzamanlılığa da uygulanır; derleyici paylaşılan erişimin koordine edildiğini kanıtlayamazsa, güvenli koddaki bu tür paylaşımı engeller. Bu, veri yarışlarını çalışma zamanından önce yakalamaya yardımcı olur.
Çoğu kod “güvenli Rust”tır; burada derleyici bellek güvenliği kurallarını zorlar.
unsafe, derleyicinin genel olarak güvenli olduğunu ispatlayamadığı bazı operasyonlara izin veren açık bir kaçış yoludur (örn. belirli FFI çağrıları veya düşük seviyeli işlemler).
İyi uygulama, unsafe bloklarını küçük tutmak, açık yorumlarla güvenlik varsayımlarını belgelemek ve bu bölümlere ekstra inceleme yapmaktır.