Rust'un Öğrenme Eğrisini Yatıştırma Rehberi

• Rust, tamamen yeni bir düşünme biçimi gerektiren bir dil ve zihniyet, öğrenme hızını büyük ölçüde etkiliyor
• Asıl mesele derleyiciyle dost olmak; hata mesajlarını sadece düzeltmek değil, nedenlerini anlamaya çalışmak önemli
• Başlangıçta clone(), unwrap gibi araçları rahatça kullanıp küçük başlayarak kademeli refaktör etmek iyi bir yaklaşım
• Kodu bol bol elle yazarak, hata ve deneme-yanılma yoluyla sezgi ve kas hafızası geliştirmek gerekiyor
• Rust, tip sistemi merkezli geliştirme felsefesine sahip; bu yüzden dokümantasyonu dikkatle okuyup tiplerle modelleme pratiği yapmak gerekli

---

Flattening Rust's Learning Curve

Rust, öğrenmesi zor bir dil olarak biliniyor; ancak bu yazı, Rust'u daha etkili öğrenmek için yazarın deneyimlerine dayanan somut tutum ve yaklaşım önerileri sunuyor

Let Your Guard Down

• Rust, mevcut dillerden farklı bir zihinsel model gerektirir
• Acemilerin bazen ustalardan daha hızlı öğrenebildiği olur → asıl anahtar tutum ve açıklık
• Borrow checker'ı düşman değil, ortak yazar gibi görmek ve hata mesajlarını anlamaya çalışmak gerekir
• Derleyicinin neden lifetime parametreleri istediğini derinlemesine anlama isteği önemlidir
• Kod çirkin ve karmaşık görünüyorsa tasarım yanlış olabilir; bunu daha iyi bir yol aramak için işaret olarak görmek gerekir
• Rust'ın ayrıntılı yazım tarzı (verbosity) büyük uygulamalarda işe yarar ve refaktör etmeyi kolaylaştırır
• clippy lint'leri baştan itibaren mutlaka açılıp kullanılmalıdır

Baby Steps

• Başlangıçta String, clone(), unwrap cömertçe kullanılabilir; sonra refaktör etmek sorun değildir
• Karmaşık method chain'ler yerine önce basit if, match ifadeleri ile başlamak daha iyidir
• Asenkron (async) yapılar ilk hafta mümkünse ertelenmelidir
• Küçük kod parçalarını Rust Playground üzerinde deneyerek öğrenmek faydalıdır
• Her kavram için bir main.rs dosyasıyla pratik yapın; yazılan kodun çoğunu atılacakmış gibi düşünün

Be Accurate

• Rust'ta doğruluk bir hayatta kalma koşuludur
• Yazım hataları veya küçük yanlışlar doğrudan derleme hatasına yol açabildiği için dikkat gerekir
• &, mut'u otomatik ekleme alışkanlığı edinmek yardımcı olur
• Tsoding gibi geliştiricilerin yayın videoları iyi bir referans olabilir

Don’t Cheat

• LLM'lere ve kod otomatik tamamlama araçlarına bağımlı kalmak öğrenmeyi yavaşlatır
• Doğrudan elle yazmak ve anlamadığınızda dokümantasyona bakma alışkanlığı edinmek gerekir
• Auto-pilot halinde kod yazmayın
• Hataları kabul edin ve bunlar üzerinden derleyicinin nasıl çalıştığını anlamaya çalışın
• Kodu çalıştırmadan önce derlenip derlenmeyeceğini tahmin etme pratiği de önerilir
• Başkalarının kodunu okuma ve analiz etme alışkanlığı da önemlidir
• Öğrenme sürecinde harici crate kullanımını sınırlayın; serde, anyhow gibi birkaç istisna yeterlidir

Build Good Intuitions

• lifetime, ownership kavramlarını görsel olarak anlamak faydalıdır
• excalidraw gibi araçlarla veri akışı ve mimariyi çizme alışkanlığı edinmek önerilir
• Pek çok üstün mühendis ve matematikçi de görselleştirme araçlarını etkili biçimde kullanır

Build On Top Of What You Already Know

• Rust'ta tanıdık kavramların bile çalışma biçimi farklıdır (ör. mut, değer taşıma)
• Yine de mevcut dillerle karşılaştırarak öğrenmek yararlıdır

Örnekler:

• Trait → Interface'e benzer ama aynı şey değildir
• Struct → Kalıtım olmayan bir sınıf hissi verir
• Closure → Lambda'ya benzer
• Module → Namespace
• Borrow → Tek sahipli işaretçi
• Option → Maybe monad
• Enum → Algebraic data type

• Rosetta Code, diller arası kod karşılaştırarak öğrenmek için faydalıdır
• Aşina olduğunuz bir dildeki kodu Rust'a port ederek öğrenmek de etkilidir
• Liste sözdizimi veya döngüler gibi dile özgü deyimlerin Rust'ta nasıl ifade edildiğini düşünme pratiği de yararlıdır

Don’t Guess

• Rust, tahmin yürütmenin işlemediği bir dildir
• "hello".to_string() gibi kodları neden yazmak gerektiğini sebebiyle birlikte düşünün
• Hata mesajları çok öğreticidir; içlerindeki ipuçlarını asla görmezden gelmeyin
• Özellikle borrow-checker hatalarında veri akışını elle takip ederek analiz yapmak gerekir

Lean on Type-Driven Development

• Rust, tip sistemi merkezli bir dil
• Fonksiyon imzaları ve tip tanımlarından çok fazla bilgi çıkarılabilir
• Standart kütüphane dokümanlarını ve kaynak kodunu sık sık okuyun
• Önce tipleri tasarlayıp sonra koda geçmek, daha doğru ve yeniden kullanılabilir yapılar kurmayı sağlar
• Değişmezleri (invariant) tiplerle ifade etmek, yanlış kodun en baştan derlenmemesini sağlar

Invest Time In Finding Good Learning Resources

• Rust öğrenme kaynakları hâlâ çok bol değil; bu yüzden başta size uyan kaynakları bulmak ciddi zaman kazandırır
• Rustlings gibi öğrenme araçları kişiden kişiye farklı karşılanabilir
• Advent of Code, Project Euler gibi problem çözme odaklı kaynaklar daha uygun olabilir
• YouTube videolarını bilgi kaynağından çok eğlence amaçlı değerlendirin
• Kitap satın alıp çevrimdışı okuyarak kodu bizzat yazmak en etkili yöntemlerden biridir
• Mümkünse uzman eğitimi veya koçluk almak da uzun vadede ciddi zaman kazandırabilir

Find A Coding Buddy

• Yetkin bir çalışma arkadaşının kodunu gölge gibi takip edip gözlemlemek de çok faydalıdır
• Rust forumları, Mastodon vb. yerlerde kod incelemesi istemek veya başkalarının kodunu incelemek gelişimi hızlandırır

Explain Rust Code To Non-Rust Developers

• Rust bilmeyen birine açıklamaya çalışmak da öğrenmeyi güçlendirir
• Açık kaynak projelerde bakımsız kalmış koda katkı vermek de önerilir
• Rust terimlerini kendi iş alanınızın diliyle eşleyen bir sözlük hazırlamak faydalı olabilir

Believe In The Long-Term Benefit

• Rust, kısa vadeli üretkenlikten çok uzun vadeli kalite için tasarlanmış bir dil
• Bir gecede uzman olunmaz; ama bir ay odaklı çalışmayla çok şey kazanılabilir
• Rust bir Day 2 dili; ilk gün zordur ama sürekli kullanıldığında değeri artar
• Başarılı olmak için bunu sadece özgeçmiş için değil, programlamayı gerçekten sevdiğiniz için yapmanız gerekir

[aer0700]

Eskiden öğrenme amacıyla daha önce C ile yazdığım kodu Rust ile yeniden yazmayı denemiştim; pointer’larla uğraşmak çok yorucu bir deneyimdi... Rc ya da RefCell gibi şeylerin nasıl çalıştığı kafamda bir türlü netleşmemişti...

[q8840]

Temel belgeleri ve Nomicon'u sırayla birer kez okuduktan sonra Rust konusunda bir kez bile tıkanmadım; gerçekten öğrenme eğrisi o kadar yüksek mi diye düşünüyorum.

[freedomzero]

Ah, unwrap ve clone kullanımına alışırsan, sonra sahiplik yüzünden çok acı çekersin T_T

[GN⁺]

Hacker News görüşleri

• Bu, sanki “A Discipline of Programming” okuyormuşum gibi hissettiriyor; Dijkstra’nın ahlaki tonda açıklama yapma tarzının eskiden neden gerekli olduğu da buydu, çünkü insanlar programlama kavramlarının kendisini gerçekten anlamıyordu. Rust’ın sahiplik açıklamaları çoğu zaman gereksiz derecede uzun oluyor; temel kavramların çoğu var ama örneklerin altına gömülmüş durumda. Rust’ta her veri nesnesinin tam olarak bir sahibi vardır. Bu sahiplik, her zaman yalnızca bir kişi sahip olacak şekilde devredilebilir. Birden fazla sahip gerekiyorsa, gerçek sahibin referans sayımlı bir hücre olması gerekir. Bu hücre klonlanabilir. Sahibi ortadan kalkarsa, onun sahip oldukları da ortadan kalkar. ref kullanarak veri nesnesine erişimi geçici olarak ödünç alabilirsiniz. Sahiplik ile referans açıkça farklı şeylerdir. Referanslar aktarılabilir ve saklanabilir, ama nesnenin kendisinden daha uzun yaşayamaz; aksi halde “dangling pointer” hatası olur. Bu kurallar derleme zamanında borrow checker tarafından sıkı biçimde uygulanır. Rust’ın sahiplik modeli budur; bunu anladıktan sonra ayrıntılar eninde sonunda bu kurallara çıkar.

  • Sadece bana mı öyle geliyor bilmiyorum ama bu tür kavramsal açıklamaları takip etmek zor geliyor. Encapsulation da benim için böyleydi; “bilgiyi gizler” deniyor ama bunun tam olarak nasıl/niçin olduğunu eşelemiyor. Mesela Rust’ta sahibin tam olarak kim olduğunu anlamıyorum. Sahip stack frame mi? LIFO yapısı varken sahipliğin neden callee’ye aktarıldığını merak ediyorum; sonuçta callee’nin stack’i önce yok olacağı için risk olmaması gerekmez mi? Eğer amaç optimizasyonsa, nesneyi daha erken temizleyebilmek için mi? Sahip stack frame değilse, o zaman ne? Neden mutable reference yalnızca 1 kez verilebiliyor, o da kafamı karıştırıyor. Tek thread’li ortamda zaten bir fonksiyon bitmeden diğeri başlamayacağı için ikisinin de mutable reference alması sorun değilmiş gibi geliyor. Sorun sadece çoklu thread ortamında çıkıyorsa, hata orada verilse olmaz mı? Bu sorular yüzünden Rust çalışmaya başlayıp durmadan bırakıyorum.

  • Bu sahipliği açıklayan bir metin değil, motive etmeye çalışan bir metin. En zor ve en kritik kısım, fonksiyon imzalarında lifetime’ların karmaşık biçimde dolandığı durumları nasıl okuyacağınızı ve böyle fonksiyonları çağırırken oluşan derleyici hatalarını nasıl anlayıp düzelteceğinizi öğrenmek.

  • Bu kavramları zaten bilen biri için doğru ve kusursuz görünen bir özeti hazırlamak, ilk kez öğrenen birine açıklamaktan çok daha kolay. Bunu böyle anlatırsanız, şimdiye kadar sadece call-by-sharing kullanan biri gerçekten hemen anlayabilir mi? Pek sanmıyorum.

  • Rust bilmeyen biri bu özeti okuyunca Rust hakkında hiçbir şey öğrenmiş olmayacak. Sadece “bu dilde sanki derleyicinin içinde kara büyü varmış” diye düşünecek.

  • Sahiplik ve borrowing kavramlarının kendisi aslında kolay anlaşılabilir. Rust’ı gerçekten zor yapan şey, fonksiyon imzaları ile gerçek kullanım kodunun, referansların nesnelerden daha uzun yaşamayacağını birbirine ispatlamak zorunda olması. Bu arada, referans verilen nesneyi tipe kaydetmemek, ispatı daha az karmaşık hale getirdiği için genelde daha iyi bir tercih.

  • 60’larda insanların assembly düzeyinde sistem/uygulama durumunu nasıl ele aldığını anlatan yazılar uzun zamandır arıyordum. Sutherland’ın Sketchpad makalesinde veri yapılarıyla ilgili çok ayrıntı olduğu söylenmişti ama sadece 2-3. bölümleri okudum.

  • Bu açıklama bana anlamlı gelmiyor. Sahiplik ve borrowing’i net biçimde tanımlamıyor. İkisi de sanki finansal varlık yönetiminden alınmış metaforlar gibi duran kelimeler. Rust’a aşina değilim ama bu kelime seçiminin kendisi kavramları anlamayı zorlaştırıyor gibi. Metaforlar çoğu zaman iki ucu keskin kılıçtır. Daha doğrudan, belleğe ilişkin terimlerle anlatmak daha faydalı olabilir.

  • Model açıklamasında önemli olan exclusive/shared ya da mutable/immutable borrowing farkı tamamen atlanmış. Rust, bu tür borrow’lara nasıl izin verileceği konusunda çok sayıda tercih yaptı ve bunlar sezgisel değil. Örneğin no aliasing kuralı sezgiden değil, fonksiyon optimizasyonu amacından doğmuş bir şey. Borrowing’deki en karmaşık nokta, lifetime elision kuralları yüzünden derleyici hata mesajlarının bazen gerçek nedenden tamamen farklı bir yeri işaret etmesi. Bu elision kuralları sezgisel değil; işleri basitleştirmek için getirilmiş tercihler.

  • Brown University’nin düzenlediği Rust Book sürümü, borrow checker’ı gerçekten çok iyi açıklıyor.

  • Açıklama eksik gibi görünüyor; örneğin ödünç alan taraf ortadan kalkarsa ne olacağına dair bir şey yok.

  • “Gerçek sahip referans sayımlı bir hücre olmalı” denmiş ama bu, ancak onun ne olduğunu bilenlerin anlayacağı bir açıklama gibi.

  • Borrow checker’ı ancak kendi borrow checker’ını yazınca anlamaya başlıyorsun.

  • İkinci bölümün ikinci maddesi ciddi biçimde abartılı. Gerçekte Rust’ın derlemediği ama güvenli olan çok sayıda kod örneği var. Bu karmaşıklığın oluşma nedeni, derleyicinin neleri ispatlayabildiğinin sınırlarını netleştirmek.

• Rust’ın sahiplik modeli, lifetime’lar, enum ve pattern matching ilk karşılaştığımda inanılmaz göz korkutucuydu. İlk denememde fazla hızlı biçimde bunaldım; ikinci denememde kitaptaki her satırı okumaya çalışınca sabrım tükendi. Ama bu sırada Rust’ın programlama ve yazılım tasarımı hakkında daha derin içgörüler veren bir dil olduğunu fark ettim. Ancak üçüncü denememde, daha önce yazdığım küçük programları ve script’leri Rust tarzında yeniden yazarak öğrenmeye başladım; bu süreçte Rust usulü hata işleme, veri temsili için tipleri aktif kullanma, pattern matching gibi şeyleri de öğrendim. Bütün bu deneyimden sonra, Rust öğrenmenin programcı hayatımdaki en iyi kararlardan biri olduğuna eminim. Tipleri, struct’ları ve enum’ları önceden tanımlayıp; immutable veri ve pattern matching temelli fonksiyonlar yazma yaklaşımını artık başka dillerde de doğal biçimde uyguluyorum.

  • Ben de benzer bir deneyim yaşadım. Rust’ı üçüncü kez öğrenirken ancak gerçekten oturmaya başladı ve birkaç programı etkili biçimde yazabilir hale geldim. Uzun yıllardır programlama yapıyor olsam da bazen tekrar tekrar öğrenmek gerekiyor. Daha önce JVM bağımlılık enjeksiyonu çatısı Dagger’ı anlamak için de tam 3 öğrenme denemesi gerekmişti. Belki de karmaşık şeyler öğrenirken bende tekrarlayan bir örüntü bu.

  • C++ geliştiricilerinin Rust’la ilk karşılaşmasında sık görülen bir şey bu; C++ zihniyetiyle yaklaşınca sürekli “borrow checker” ile kavga ediyorsun. Rust alışkanlıklarını gerçekten öğrendiğinde, o alışkanlıkları tekrar C++’a da taşıyıp daha sağlam kod yazmaya başlıyorsun; C++’ta borrow checker olmasa bile.

• “Derlemeden önce tüm kodu dikkatle okuyup yazım hatalarını düzeltirsen daha iyi vakit geçirirsin” tavsiyesi bana garip geliyor. Rust derleyicisi çok yardımsever hata mesajlarıyla ünlü; madem öyle, neden ben oturup yazım hatası avına çıkayım? Yazım hatalarımı bilgisayarın yakalamasını isterim.

  • cargo fix bazı sorunları otomatik düzeltiyor ama her şeyi çözmüyor.

• “Direnme”, “öğrenmek için kibrini bırak”, “teslimiyet ilanı lazım”, “direniş faydasız, ne kadar erken kabullenirsen o kadar az acı çekersin”, “bildiklerini unut” gibi tavsiyeler var; bunu görünce Orwell’in telescreen OS’inin Rust’la yazıldığını düşünesim geldi.

  • Buna katılıyorum. Rust öğrenirken yaşadığım hayal kırıklığındaki en büyük hata, Rust’ı zorla nesne yönelimli paradigma ile ele almaya çalışmamdı. “Tamam, Rust nasıl istiyorsa öyle yapayım” diye kabul edince işler hemen akmaya başladı.

• Rust yeni başlayanlar için epey yüksek bir eşik. Diğer dillerden çok farklı — bu kasıtlı ama aynı zamanda ciddi bir giriş bariyeri. Söz dizimi karmaşık ve çok yoğun; sanki klavyeye dirsekle vurulmuş gibi görünebiliyor. Tek bir karakter anlamı tamamen değiştirebiliyor ve iç içelik çok fazla. Pek çok özelliği, arkasındaki teorik zemin olmadan anlamak zor; bu da karmaşıklığı daha da artırıyor. Tip sistemi ve borrowing mekanizması bunun başlıca örnekleri. Sıradan bir Python ya da JavaScript kullanıcısına neredeyse uzaylı dili gibi geliyor. Günümüzde programcıların çoğunun fiilen yüksek lisans düzeyinde CS arka planı yok; bu yüzden Rust onlara uygun görünmüyor. Üstüne makrolar işleri daha da karmaşıklaştırıyor; tanımını bilmezsen kodun ne dediğini anlamak zor. Son dönemde LLM’lerin bu bariyerleri düşürebileceği düşüncesi bana umut veriyor. Hâlâ Rust öğrenme ihtiyacını hissetmiyorum ama LLM’ler sayesinde bir gün yeniden denemeye niyetliyim. Rust bu anlamda gerçekten benzersiz derecede öğrenmesi zor bir dil.

  • Rust öğrenirken en zorlandığım şey tam olarak makrolardı. Kullandığım kaynaklar makroları erken dönemde, üstelik düzgün açıklama yapmadan tanıttığı için iyice kafam karıştı.

• Hangi durumda olursa olsun Rust’tan daha iyi bir seçenek varmış gibi geliyor. Yine de açık fikirliyim; belki bir gün Rust yeterince yaygın olursa anlamlı hale gelir.

  • Eğer neredeyse 20 yıl önce Rust’ın ilk tasarlandığı amaç hâlâ geçerliyse, tarayıcıyı sıfırdan yeniden yapmak için mükemmel bir dil. Zaten bugün bu alanda Rust baskın durumda. Ayrıca dilin yaratıcısının “unix”i dünyaya hâkim oldu; birilerinin yaptığı Ladybird gibi bir şey onun yerini almadı.

• İnsanların çabalayıp öğrenmesi gerektiğine ikna etmeye çalışan yazılara ihtiyaç duyan bir dil varsa, bunun dil tasarımının kendisiyle ilgili bir sorun olup olmadığını merak ediyorum. (Bu arada Rust öğrenmedim, o yüzden bunu fazla ciddiye almayın.)

  • Senin yorumunu ancak “zor olan şey yapmaya değmez” diye okuyabiliyorum. Her şeyin artısı eksisi var; bir şeyin dezavantajlarının olması, denemeye bile değmeyeceği anlamına mı geliyor? Arp çalmanın zor olduğunu anlatan tutkulu bir yazı yazılsa, bu durumda arp çalmak kötü bir hobi mi olurdu?

  • Kıdemli geliştirici olduğunda bile, Rust’ın önem verdiği derslere belki kenardan bakmış ama gerçekten yaşamamış olabiliyorsun. Birçok kişi “zaten garbage collection olan diller kullanıyorum, Rust bana ne öğretebilir ki?” diye düşünüyor. Oysa mutable durum ile paylaşılan referanslar birbirine girince korkunç bir karmaşa çıkıyor ve bu yüzden immutable nesnelere yöneliyorsun. Immutable nesnelerin olunca, bu nesneleri rahatça dönüştürmenin yollarını tekrar düşünmek zorunda kalıyorsun; hatta bazen mutable nesnelere göre kullanımları daha zor olabiliyor. “Bu nesnenin mutable olduğu zamanlar ve immutable olduğu zamanlar var”ı ifade etmeye çalışınca sonunda borrow checker ihtiyacı ortaya çıkıyor. Borrow checker gelince de “o zaman neden hâlâ garbage collection gerekiyor?” sorusu kalıyor. Sonuçta çoğu zaman sadece nesne yaşam süresini açıkça düşünmekle uğraşmamak için garbage collection kullanıyoruz. Rust, bu temel meseleyi doğrudan yaşatıyor.

  • Rust’ın tasarım kararlarını anlamak çoğu zaman zor. Mojo’da da borrow checker var ama yine de Rust’tan çok daha kolay öğreniliyor; bunun birkaç nedeni var. Birincisi value semantics. Rust’ta yeni başlayanlara sürekli clone() kullanmaları söyleniyor, oysa çoğu statik dilde (C, C++, Go vb.) günlük kullanımda value semantics zaten varsayılan. İkincisi, Mojo’daki lifetime’lar, bir değerin scope’a göre kullanılabilir olup olmadığını değil, ne zaman silineceğini belirliyor. Referanslar kaldığı sürece lifetime uzuyor, kullanım biter bitmez de siliniyor. Bu yüzden Mojo’da “değer yeterince uzun yaşamıyor” gibi hataları görmüyorsun. Sadece bu iki tasarım tercihi bile yükü ciddi biçimde azaltıyor.

  • Yeni başlayanlar için her dili öğrenmek zordur; o yüzden Rust’ı burada özel bir yere koymak çok doğru değil. Programlamanın kendisinin zaten bir öğrenme eğrisi var.

  • Böyle bir yazının varlığı bana dilden çok yazar hakkında bir şey söylüyor gibi geliyor. Yazarı eleştirmek için söylemiyorum; bu tutkuyu böyle paylaşması güzel bence.

  • Bu yazı, Rust’ın hangi sorunları çözdüğünden çok öğrenme eğrisi hakkında konuşuyor gibi. İkisini dengeli anlatmak gerekir ki gerçekten uğraşmaya değip değmeyeceğine karar verilebilsin.

  • Rust hakkında tasarım tartışmaları elbette yapılabilir ama böyle yazıların gerekli olması tek başına Rust dilini değerlendirmek için yeterli değil. Hatta bence Python’ın bu tür yazılara daha çok ihtiyacı var. Mühendislik dışı geçmişten gelen programcılar arttıkça, Python paradoksal biçimde herkesin kullanabildiği ama Rust’ın herkesin kullanamadığı bir dil haline geliyor. Bazı insanlar için Rust, C ya da Zig gibi dillerle kıyaslandığında çok daha kolay öğrenilen bir dil. Python’ı seviyorum ama özünde korkunç bir dil olduğunun da farkındayım. LLM çağında bile insanlar optimize Python yazmaları gerektiğini pek bilmiyor; bizim yapay zeka dostlarımız da özellikle söylenmedikçe verimsiz Python üretmeye devam edecek.

  • “Bu dil tasarımıyla ilgili bir sorun değil mi?” sorusuna benim karşılığım “neden?” olur.

  • Rust öğrenmiş biri olarak şunu söyleyebilirim: ağırlıklı olarak Python kullansan bile Rust’ta dilsel bir kusur olduğunu hiç hissetmedim. Aksine çok katı bir dil; onu sürekli Rust olmayan biçimde kullanmaya çalışırsan sadece kendini yoruyorsun. Rust tarzına uyduğunda, işler karmaşıklaştıkça daha da fazla yardım ediyor. Diğer dillerde hatalar çalışma zamanında teker teker ortaya çıkarken, Rust bunların büyük kısmını derleme anında yakalıyor. Elbette mantık hatalarını engellemiyor ama güçlü test entegrasyonu sayesinde bununla başa çıkılabiliyor. Eksileri var ama Rust kesinlikle bir kez öğrenmeye değer. Hataları azaltmak için seçtiği yaklaşım, başka dillerde iyi geliştirme alışkanlıkları olarak da işe yarıyor.

  • Rust gerçekten fazla karmaşık; LLM’lerin doğru Rust kodunu tek seferde üretmesinin zor olduğu da doğru. Yine de bunu JavaScript ve diğer zayıf tipli/dinamik dillerin pek çok sorununa tercih ederim.

  • Ben Rust öğrendim ve söylediğine katılıyorum. Rust gerçekten karmaşık ve “komite tasarımı” gibi duran bir dil. Harika tooling’i var ama yine de C++’tan daha az karmaşık olsa da kolay öğrenilecek bir dil değil.

  • Bu tür yazıların sorunu özüne inmemesi. Rust’ta yazılmasına en baştan izin verilmeyen programlar var. Bunun iyi nedenleri var ama bu, neredeyse herkesin kullandığı dillerden temelden farklı bir durum. Açıkça Rust’ta yazılamayan programlar olduğu için bunu kabullenmek gerekiyor; yoksa Rust sana göre değil.

• Rust öğrenirken pek yaygın olmayan yaklaşımlardan biri, önce dilin sadece bir alt kümesini öğrenmek. Örneğin benim Rust giriş kitabım lifetime’ları hiç öğretmiyor. Lifetime içermeyen fonksiyonlarla bile gayet çalışan programlar yazılabilir. Makrolarda da benzer durum var; kolay değiller ama sonuçta önce alt kümeyi öğrenmek gerekiyor. Ayrıca en baştan copy() ya da clone() bağımlısı olmak yerine, önce borrowing kavramını öğrenmenin daha doğru bir yaklaşım olduğunu düşünüyorum. Borrowing bu dilin kalbi.

• Rust öğrenmenin tek yolu, 300 bin dolar üstü maaş veren çok sayıda iş çıkması olabilir. Gelecekte Rust’ın quant tarafında C++’ın yerini alma potansiyeli olduğunu da düşünüyorum. Ama zaten OCaml var ve eğer aşırı zor ve karmaşık bir dil öğreneceksem önce ortada para görmek isterim. Şimdiye kadar en yüksek maaşlı işler benim için Python tarafındaydı.

• Bu yorumları okurken, yaşlı programcıların eleştirildiklerinde sıkça gösterdiği tutumu fark ettim. İnsan yıllar geçtikçe daha inatçı olabiliyor. Derleyicinin önerilerini neden reddettiğinizi herkesin kendisi düşünmesi iyi olur. Neyi farklı yapmak istiyorsunuz, sizi tam olarak ne engelliyor; bunu kendiniz sorgulamanız lazım.