Rust'un özü

• Rust, çeşitli kavramların birbiriyle sıkı biçimde iç içe geçtiği bir dil; bu yüzden temel bir programı anlamak için bile birçok unsuru aynı anda öğrenmek gerekir
• Fonksiyonlar, generics, enum'lar, pattern matching, trait'ler, referanslar, ownership, Send/Sync, Iterator gibi unsurların tümü birbiriyle etkileşime girecek şekilde tasarlanmış temel öğelerdir
• JavaScript ile karşılaştırıldığında, JS'te yalnızca bazı kavramları bilerek kod yazmak mümkünken, Rust'ta ancak dilin bütün bağlamı anlaşıldığında anlamlı kod yazılabilir
• Rust'taki bu karmaşıklık öğrenme eşiğini yükseltir, ama aynı zamanda güvenlik ve tutarlılık sağlar ve kod tasarlama biçimini güçlü şekilde etkiler
• Bu dilsel örgü, Rust'u özel kılar; “Daha küçük Rust” vizyonu da incelikle birbirine bağlanmış bir dil felsefesini yeniden düşünmeye sevk eder

---

Rust öğrenmenin zorluğu

• Rust'un giriş eşiği yüksek olsa da birçok kişi dokümantasyon, API ve tanılama iyileştirmelerine katkıda bulunmuştur
• Temel kavramlar arasında birinci sınıf fonksiyonlar, enum'lar, pattern matching, generics, trait'ler, referanslar, borrow checker, eşzamanlılık güvenliği, iterator'ler yer alır
• Bu kavramlar birbirine bağımlı ve iç içe geçmiş olduğundan tek tek ayrı öğrenilmeleri zordur; standart kütüphane de büyük ölçüde bu özellikleri kullanır
• Yaklaşık 20 satırlık bir Rust kodunu anlamak için bile fonksiyonel paradigma, Result ve hata işleme, generic tipler, enum'lar, iterator'ler gibi birçok öğeyi aynı anda kavramak gerekir

Rust ve JavaScript karşılaştırması

• Aynı dosya değişikliği algılama programı Rust ve JS ile yazıldığında, Rust tarafında çok sayıda dil kavramı birbirine dolanmıştır
• JS'te temelde yalnızca fonksiyonlar ve null işleme anlaşılırsa çalışan kod yazmak yeterlidir
• Bu, Rust'un sadece daha zor olduğu anlamına gelmez; Rust'un dilin tamamının yapısal olarak anlaşılmasını gerektiren bir tasarım olduğunu gösterir

Rust'un karşılıklı bağlı tasarımı

• Rust'un özü, organik biçimde tasarlanmış özelliklerin birleşimidir
  • Enum'lar pattern matching olmadan kullanışsız kalır; pattern matching de enum'lar olmadan kısıtlıdır
  • Result ve Iterator, generics olmadan uygulanamaz
  • Send/Sync kavramı ile println kısıtları, trait'ler olmadan güvenli biçimde ifade edilemez
  • Borrow checker, closure'ların capture analizini kullanarak Send/Sync güvenliğini garanti eder
• Bu karşılıklı bağ, Rust'u yalnızca bir özellikler toplamı değil, bütünleşik bir dil sistemi haline getirir

Daha küçük Rust vizyonu

• 2019'da without.boats, “Smaller Rust”tan söz ederek küçük ve rafine bir Rust olasılığını tartıştı
• Bugün Rust çok daha büyümüş olsa da, daha küçük Rust fikri incelikle kenetlenmiş dil tasarımının özünü hatırlatır
• Rust'un çekiciliği, dil öğelerinin birbirinden bağımsızken bir araya geldiklerinde güçlü ifade kabiliyeti ve güvenlik sunmasında yatar

Sonuç

• Rust'u öğrenmek zordur, ancak birbirine geçmiş kavramların tutarlılığı ve bütünlüğü büyük bir güçlü yön olarak öne çıkar
• Bu yapı sayesinde Rust, geliştiricilerin yalnızca kod yazmasını değil, güvenlik ve performansı aynı anda düşünen bir yaklaşım benimsemesini sağlar
• Rust'un özü, “küçük ve incelikle tasarlanmış bir çekirdek dil”dedir; bu da günümüzde genişlemiş Rust'ta bile önemli bir felsefe olarak varlığını sürdürür

[GN⁺]

Hacker News yorumu

• "Basit" bir JS programında bile hata olmasında bir ironi görüyorum. fs.watch dokümanında, callback içinde filename değerinin null olabileceğinin mutlaka kontrol edilmesi gerektiği açıkça yazıyor. Rust'ta bu gerçek tip sistemine yansıtılır ve seni bunu zorunlu olarak ele almaya iterdi, ama JS'te kodu gelişigüzel yazmak çok kolay. İlgili doküman
  • TypeScript kullanırsan null kontrolü zorunlu olur. Bu yüzden bence TS'nin, JS dünyasında Rust'taki doğruluk anlayışına daha yakın, nispeten düşük maliyetli bir ara adım olduğunu gösteren iyi bir örnek
  • Ek bir hata daha var: for path in paths, for (const path of paths) olmalı. JS parantez yoksa zaten hemen hata verir ama in ile of arasındaki fark şu: biri değerleri değil indeksleri (iterable index) dolaşır, dolayısıyla indeks gerçekten string'e çevrilip fs.watch'ın ilk argümanı olarak geçer. Hatta TypeScript bile bu hatayı yakalayamayabilir
  • Dediğin gibi döngü sözdiziminin kendisi zaten yanlış, çalıştırınca hemen anlaşılır. Yani bunu, yazarın o JS kodunu özenle yazmadığı ve bunun asıl tartışma açısından çok da önemli olmadığı şeklinde yorumlamak daha doğru olabilir
  • Ben mi kaçırdım bilmiyorum ama kind'in nereden geldiğini merak ediyorum. console.log("${kind} ${filename}") içinde kind değil, eventType (string) olması gerekirdi
• Küçük bir düzeltme yapmak isterim. Rust'ta println, yalnızca Display veya Debug trait'ini uygulayan tipleri yazdırabilir. Bu yüzden Path doğrudan yazdırılamaz. Her işletim sistemi yolları UTF-8 olarak saklamaz ve Rust'ın string tipleri bütünüyle UTF-8'dir. Yani Path yazdırmak kayıplı olabilir. Path, display metodu üzerinden Display uygulayan bir tip döndürür. Rust bunu tip sistemine işlemiş durumda ama JS/TS'te içteki string'in UTF-16 olduğunu açıkça ifade etmek zordur; Unicode olmayan yolları doğru işlemek için doğrudan TextEncoder/Decoder kullanmak gerekir. Eski deneyimlerime göre, sunucu Shift_JIS ile metin gönderdiğinde bunu response.text() ile okuyunca çalışma zamanında yalnızca boş string dönüyordu. Kodlama meselelerine alışkın değilsen böyle bir durumda günlerce debug yapabilirsin. Ayrıca JS örneğinde, Rust kodunda olmayan hatalar ve sözdizimi yanlışları var (for-in yerine for-of gerekli). Bu örnek için sadece "birinci sınıf fonksiyonlar" kullanılıyor demek de pek doğru değil; Rust'taki gibi iterator mantığını da anlaman gerekiyor ve CommonJS kullanılıyor. Üstelik async/await, Promises ve top-level await gibi şeyleri de ayrıca öğrenmek gerekiyor; top-level await ise Node dahil bazı çalışma zamanlarında ancak yakın zamanda desteklendi. Hâlâ bazı JS motorlarında da yok (ör. React Native'in Hermes'i)

  • Rust'ı kullanmaya devam etmemin nedeni tam da bu. Bu örnek sadece bir tanesi ama böyle küçük sorunlar ve tuzaklar diğer dillerde hep etrafa saçılmış durumda. Tek tek bakınca belki hiç yaşanmayabilir ama bir programın tüm yaşam döngüsü boyunca birikince, bir yerlerden sürekli garip hatalar fırlar ve onları durmadan aramak zorunda kalırsın. Rust'ta bu olmuyor. Tip sistemi akıl almaz ölçüde çok durumu daha baştan engelliyor. Gerçekten de Rust'la özellikleri tamamlanmış bir yazılımı yayına aldıktan sonra, sadece ara sıra yeni özellik ekledim; genel hata ayıklama yükü neredeyse tamamen ortadan kalktı. Elbette her yerde mantık hataları olabilir ama diğer dillerdeki aptalca tip/yapı uyuşmazlıklarından doğan sorunları en baştan kapattığı için üretkenlik ve bakım deneyimi bambaşka oluyor

  • Kişisel olarak, JS/TS'te thenable/Promise ve async-await konusunu gerçekten iyi bilen geliştirici sayısının çok olmadığını düşünüyorum. Şuna benzer şeyler de gördüm:

    var fn = async (param) => new Promise((res, rej) => {
      fooLibraryCall(param).then(res).catch(rej);
    });
    

    Callback biçimindeki bir sarmalayıcıyı aynen Promise ile paketleyip sonra bunu async fonksiyon içinde tekrar kullanıyorlar. Bunu her gördüğümde içim acıyor. Gerçekten bunun gibi kodları her yerde gördüm. Buna bir de modül import'ları, async import(), transpile, code splitting vb. eklenince iş gerçekten karmaşıklaşıyor

• Bjarne alıntısının aslında C++'ın giderek kötüleşmesini tekrar tekrar meşrulaştırmak için kullanılan bir satış söylemi olduğunu düşünüyorum. Başlarda samimi olabilir ama artık model tamamen tekrar eden bir döngü gibi. Bana göre yapı şöyle:
  1. "C++'ın içinde daha küçük ve daha temiz bir dil var"
  2. Ama dili gerçekten bir subset olarak çıkaramıyoruz; o yüzden önce superset'i (daha çok özellik) yapalım, sonra subset'e bakarız deniyor
  3. Superset yeni C++N+1'e giriyor. Asıl subset tartışması ise sonra denilerek erteleniyor ve bu tekrar ediyor
  4. C++N+1 daha da karmaşıklaşıyor ve bu sonsuza kadar sürüyor Bunu tekrar tekrar gören insanların neden hâlâ kaldığını anlamıyorum. Sonuçta o "daha küçük ve daha temiz dil" hiçbir zaman ortaya çıkmıyor. Hep birinci adım tekrar ediliyor
  • Bunu görünce aklıma xkcd 927 geliyor. C++ standardı her seferinde daha karmaşık hale geliyor; iyi değişiklikler de var ama eski sürümlerle uyumsuzluklar da çıkıyor ve kaynak kod giderek daha da karmaşık bir şeye dönüşüyor. İki OSS kütüphanesi yönetiyorum ama artık neredeyse hiç kullanmıyorum. Daha ne kadar dayanacağımı son zamanlarda düşünüyorum. Rust, c++11/14/17/20 sonrasından geçince gerçekten ferahlatıcı geliyor. Yine de Rust da tamamını öğrenirsen yeterince büyük bir dil. Bu yazıdaki tespitler bu yüzden bana çok yerinde geldi
• shebang'i (kendi kendine çalıştırılabilir rust script'i) görür görmez dikkati dağılan başka kimse olmadı mı? Daha önce Go'da benzer bir şeyi fark ettiğimde de aynı tepkiyi vermiştim. Oldukça kullanışlı görünüyor; temel amaçlar için gayet yeterli olabilir. Rust ile build/test pipeline yöneten projelerde de benzerini görmüştüm. Bu kullanım için epey iyi bir alternatif olabilir. Yine de ben çoğu zaman bash'in biraz ötesine geçen bir script gerektiğinde Deno+TS kullanıyorum. En uzun süre JS ile çalıştım (28 yıl), sonra da C# ile 24 yıl. Node'u ilk günlerinden beri kullanıyorum. Deno, paket paylaşımı/merkezileştirme açısından Node ya da Python'dan daha kolay yönetiliyor. cargo frontmatter da benzer şekilde çalışıyor
  • cargo'ya script entegrasyonunu bizzat tasarlayıp uygulayan kişiyim (bu arada uzun süredir üçüncü taraf uygulamalar da vardı). Gerçek kullanım örnekleri görmek beni çok mutlu ediyor; burada anıldığını görmek de sevindirici. Dokümana da bakabilirsiniz. Bunun nasıl görünmesi gerektiği, dille nasıl bağlanacağı, ilk sürüm kapsamının ne olacağı gibi uzun tartışmalar yaşandı. Şu anda stil kılavuzu ve Rust referansı güncellemeleri gibi son işleri yapıyoruz; geriye kalan büyük başlıklar rustfmt, rust-analyzer ayrıntıları, rustc hata düzeltmeleri ve Cargo'nun hata raporlamasını iyileştirmek. Ben de her gün issue yeniden üretim script'leri yazmak için cargo script kullanıyorum
  • Ben de gerçekten -Zscript özelliğinin anahtar kelimeleriyle arama yapıp araştırmaya dalmıştım, dikkatimin dağılması bundan. 2023'ten beri üzerinde çalışılıyor ve neredeyse tamamlanmış görünen açık issue'lar da var. ZomboDB deposunda da build pipeline'ın Rust ile yönetildiğini gördüm ama tüm bağlamı tam olarak anlayamadım. cargo frontmatter'ın script taşınabilirliği açısından aşırı faydalı olduğunu da söylemek isterim. Tek bir dosyayı paylaşmak yetiyor; Python veya Node.js'teki gibi ek kurulum/başlatma olmadan bağımlılıkları hemen çekip kullanabiliyorsun
  • Bunu Go'da da yapabildiğini söylemişsin; biraz daha ayrıntı verebilir misin merak ediyorum. Eğer ilgili bağlantı buysa ben de ilgilenirim
  • JS ve C#'ı uzun yıllar kullanmış biri olarak, 2025'te bu tür nedenlerle bir sistem seçmek bana çok anlamlı gelmiyor. Son 20 yılda gerçekten çok şey çok daha iyi hale geldi
  • Bu aslında Unix'in temel bir özelliği sadece. #!/some/path ile başlayan bir dosya, kabuk tarafından belirtilen komuta tüm dosya stdin olarak verilerek çalıştırılır
• Rust'ta "içinden daha küçük ve daha temiz bir dil çıkıyor" denirken tam olarak hangi dilden söz edildiğini merak ediyorum. Yazıya bakınca, referanslar, lifetime'lar, trait'ler, enum'lar vb. yine durmak zorunda gibi görünüyor; öyleyse neredeyse Rust'ın kendisinden farkı kalmıyor. Son bölümde "kullanmak istediğim Rust" ve "geçmişteki Rust" diye iki ipucu veriliyor ama bana çok net gelmedi. withoutboats'un "Notes on a smaller Rust" yazısını da okudum; oradaki tasarım hedefi zaten Rust'tan farklı, yani Rust olmaya çalışan bir şey değil, daha çok yeni bir dil tasarlarken Rust'tan ne öğrenilebileceğini gösteriyor. Rust olmaya çalışan bir dil değil; "ana akım" beklentilere göre şekillenen bir dil örneği (ör. GC, derleme/sözdizimi sadeleştirmesi vb.). İkinci olarak, "2018'de ilk öğrendiğimde âşık olduğum dil o 'daha küçük Rust'tı" deniyor ama aslında 2018'den beri Rust özünde çok değişmedi. Edition değişiklikleri vb. çoğu şey sözdizimsel esneklik iyileştirmeleri ve gerçekten büyük istisnalar sadece async ile const. O halde doğrudan "async ve const gelmeden önceki Rust daha küçük ve daha temizdi" denmesi gerekirdi; yazıda bunun bu kadar açık söylenmemesi bana eksik geldi
  • "Daha küçük ve daha temiz Rust" denecekse, aklıma örnek olarak Austral geliyor
  • Rust'ın temel kavramlarını koruyup daha basit (daha küçük) bir dilin mümkün olduğunu savunanlar da var. Örneğin Copy trait, reborrowing, deref coercion, döngülerde otomatik into_iter, scope sonunda otomatik drop çağrısı (bu da elle çağrılabilir ya da derleyici hata verebilir), trait bound'larda varsayılan :Sized, lifetime elision, match ergonomics gibi çeşitli otomasyon ve kolaylıkları çıkarırsan gerçekten mekanik olarak daha basit bir Rust elde edebilirsin. Ama böyle bir dili günlük kullanımda yazmak çok rahatsız edici olurdu. İronik olan şu ki bu unsurların çoğu aslında yeni başlayanlar için tasarlanmış
  • Çok dikkatli okumuşsun. Benim gerçek niyetim de gerçekten, Rust'ın async ve const gelmeden önce daha küçük ve daha temiz olduğu yönündeydi. Bunu doğrudan söylemememin nedeni, bu özellikleri geliştiren arkadaşlarımın olması. Matklad bunu lobste.rs üzerinde çok iyi ifade ediyor. 2015 Rust'ı daha tamamlanmış ve daha tutarlıydı ama Rust'ın vizyonu mutlak tutarlılık (coherence) değil, endüstride işe yarayan bir dil olmak
• Ben taraflı olabilirim ama Rust'ın kusursuza en yakın dil olduğunu düşünüyorum. Borrow checker can sıkıcı olabiliyor ama kesinlikle gerekli. Aynı derecede hatalı kod C'de olsaydı çalışma anında çöküş yaşanırdı—ve sonuçta o zaman da hatayı düzeltmek zorunda kalırdın. Fark şu ki Rust, hatayı daha derlemeden çözmeni zorunlu kılıyor; C'de ise gece yarısı çıkan arızayı toparlamak zorunda kalıyorsun. Rust'ın zor olmasından çok, farklı bir düşünme biçimine geçmeyi gerektirdiğini düşünüyorum. Güvenli ve güvenlik açısından sağlam kod yazma yönünde bir paradigma değişimi gerekiyor. Değişim çoğu zaman rahatsız edicidir; sanırım Rust'a yönelik direncin temel sebebi de bu
  • Rust kusursuzluktan oldukça uzak
    • Derleyicinin Deref'i ne zaman ve hangi sırayla uygulayacağı konusunda fazla özgür olduğunu düşünüyorum. .into() ve From trait'i tip dönüşümlerini fazla gizli yapıyor. Standart kütüphanede de bu tür "kolaylık" fonksiyonlarından çok var. Sonuçta nesnenin tipi belirsizleşiyor ve fonksiyon çağrısıyla implementasyon arasındaki bağın takibi zorlaşıyor (tabii IDE biraz yardımcı olursa başka)
    • Örtük dönüş (implicit return) program akışını gizleyip hatalara yol açıyor. Soru işareti operatörünü de pek sevmiyorum
    • Küçük Rust modülleri o kadar fazla parçalanmış durumda ki işe yarar bir şey yapmak için yüzlerce bağımlılık gerekiyor. Kararlı build için bunların hepsini ayrı ayrı yönetmek ve vendor etmek gerekiyor; bu gerçekten can sıkıcı
    • Async Rust şu anda tam bir kaos
  • Esas eleştiri borrow checker'a değil, Rust'ın kendi "kütlesinin" çok büyümüş olmasına. 2018'deki kaba sayılabilecek, eksik Rust'ı seven insanlar için (ben dahil) bugünkü hali pek çekici değil. Elbette ustalaşınca çok güçlü ama gerçekten o kadar emeğe değer mi diye insan kendine soruyor. 2025'te C/C++ alternatifi olarak muhtemelen Zig'i seçerdim (tek istisna Postgres işleri; pgrx ekosistemi gerçekten eşsiz). Yine de C ile çalışmaktan iyidir
• İlk öğrenilen dil olarak Rust'ı önermemek gerektiğini düşünüyorum. İlk dili öğrenmek zaten zorken, Rust'ta derleyici hataları yüzünden kod tamamen doğru olana kadar çoğu zaman çalıştırmayı bile göremiyorsun. Bu çok yıldırıcı olur ve insanlar kolayca vazgeçer. Python, JavaScript veya Lua ile başlamak; oyun gibi bir şeyleri hızlıca yapıp yinelemeli ilerlemek daha iyi bir tavsiye bence
  • Benim deneyimim farklı. Şirketimizde yalnızca Python bilen bir ML mühendisi, Rust kod tabanına katkı yapmak istedi. Ben yaklaşık bir saat temel şeyleri anlattım, çok hızlı uyum sağladı ve üretkenliği hemen arttı. Aslında bir oyun yaparken string'i sayısal bir fonksiyona verip programı çökertirsen, sebebini bulmak çok daha fazla zaman alabilir. Rust'ta derleyici doğrudan "burada string var ama int olmalı" diye gösteriyor; bu yüzden debug daha kısa sürüyor. Bütün günü derleme hatalarıyla geçirmek yerine, çalışma zamanı hatalarıyla bir hafta uğraşmıyorsun
  • Blogun başındaki alıntının sahibi benim. Rust'ı ilk dil olarak 400'den fazla kişiye öğrettim ve bu başlıktaki iddialar bana çok ilginç geliyor. Uzun süreli doğrudan deneyimim sayesinde bunun sadece mümkün değil, epey iyi de işlediğine dair yeterince kanıt gördüm
  • Ben hâlâ tam emin değilim. Rust'ın ilk dil olarak iyi bir eğitmen tarafından denenmesini görmek isterdim. Nesiller değişti, üniversitelerde de Python daha yaygın ama teorik olarak Rust'ın ilk dil olarak tüm kohortun seviyesini yükseltmesi mümkün olabilir diye düşünüyorum (tabii başarısızlık oranı fazla yüksek olup idari sorun da yaratabilir; öte yandan ileri seviye öğrenciler daha çok şey öğrenebilir). move assignment ya da const anahtar sözcüğünün anlamı gibi, Rust'ta öğrenilen bazı şeyler sonradan geleneksel dillerde edinilmiş kötü alışkanlıkları söküp atma zahmetini de azaltabilir
  • Genelde ilk dil olarak statik tiplemeden kaçınmayı tavsiye ederim. Ben de statik tiplemeyi severim ama yeni başlayan biri için çoğu zaman sadece kafa karıştırıcıdır. Derleyici hataları genellikle karşıolgusaldır ve "derleyici bunun none olmadığını kanıtlayamadı" türü mesajlar, bir test durumunda çalışma zamanı çökmesinin yerini doğrudan görmekten çok daha zor gelebilir. Çıktıları satır satır yazdırarak sorun çözmek çoğu zaman daha hızlıdır; ama derleyicinin karmaşık hata mesajlarında takılırsan gerçekten uzun süre kaybolabilirsin
  • Rust, her şeyi bir anda kavrayabiliyorsan kötü bir dil değil. Sorun şu ki kimse dili böyle öğrenmiyor; ana kavramları yeterince bilmeden Rust'ta sürekli deneme-yanılma yaşarsın. Sonunda başka dillerde hiç karşılaşmadığın pek çok kavramla uğraştığın için, yeni bir dile geçtiğinde de yeniden bocalayabilirsin
• Gördüğüm "basit Rust"a en yakın örnek Gleam oldu. Rust'tan epey ilham almış gibi görünüyor
  • Gleam'in Rust'tan ilham aldığı düşüncesi bir yanlış anlama. Yapımcısı bunu resmî olarak söylemiyor. Derleyici Rust ile yazılmış olabilir ama Gleam'in paradigması ve hedef çalışma zamanı tamamen farklı; Rust'ın alternatifi değil
  • Başka bir "simple rust" tarzı istiyorsan fsharp'a da bakmanı öneririm
  • Gleam'in ana sayfasında siyahların hakları, trans hakları ve anti-Nazi mesajları var; bu yüzden bu dille hiç ilgilenmiyorum
  • Gleam ile 3D yapılabiliyor mu acaba
• Beni rahatsız eden şey, "Rust programının ne yaptığını açıklamıyor" olmasıydı. Bir sürü teknik açıklama var ama programın gerçekte ne yaptığının özeti yok. Aslında yaptığı tek şey dosya değişikliklerini izleyip yazdırmak. Rust'ta böyle basit bir işin bile uygulaması karmaşıklaşabiliyor; gerçek sorunla ilgisi olmayan iç ayrıntıları da düşünmek zorunda kalıyorsun. Bunu dilin zorluğunu iyi gösteren bir nokta olarak görüyorum: hem karşılaşılan bir meydan okuma hem de bir bakıma kendi kendine oluşturulmuş bir engel
  • Diğer dillerde de aynı sorun var ama Rust bunları daha en baştan ele almana yardım ediyor. Her dosya adı yazdırılabilir değil ve çoğu dil bu kısmı kullanıcıya bırakıyor. Rust dönüş tipleriyle hata/başarısızlığı açıkça gösteriyor; diğer dillerdeyse istisna yönetimi gibi başka mekanizmalar gerekiyor. İlk bakışta basit görünse de aslında Rust tarafı daha sezgisel bile olabilir
  • Uygulama da aslında yüksek performanslı bir dil için oldukça basit. Her şey tek sayfaya sığıyor. Bu kadar basit bir örnek değil mi zaten?
  • Basit açıklama = basit uygulama her zaman doğru değil. Bunu XKCD 1425 çok iyi anlatıyor. (Örn. bir fotoğrafın milli park içinde çekilip çekilmediğini anlamak kolay olabilir ama bunun bir kuş fotoğrafı olup olmadığını ayırt etmek için bir araştırma ekibi gerekebilir.) xkcd 1425
• Rust'ın anlamsal açıdan oldukça tutarlı ve bütünlüklü olduğunu düşünüyorum. Diğer dillere kıyasla daha az yapay tatlandırıcı, daha az şekerleme var; bu yüzden daha sezgisel geliyor. Tüm arayüzler genelde mem modülü desenini takip ediyor, bu yüzden arayüz yapısını gerçekten anlamak istiyorsan std::mem ile başlamak iyi olur