Matt Godbolt’un C++ üzerinden Rust’ın cazibesini göstermesiyle gelen ikna

• 20 yıldan uzun süredir C++ kullanan yazar, Matt Godbolt’un konuşması sayesinde Rust’ın avantajlarını yeniden keşfetmesine yol açan süreci anlatıyor
• C++’ta tip karışıklığından kaynaklanan hatalar derleyici tarafından düzgün biçimde yakalanmazken, Rust bunu derleme zamanında güçlü şekilde engelliyor
• Rust, yalnızca bellek güvenliğinin ötesinde, API’nin yanlış kullanılmasını önlemeye de uygun bir tasarıma sahip
• Özellikle çalışma zamanı girdilerini işlerken Rust, hataların açıkça ele alınmasını zorunlu kılarak riski azaltıyor
• Sonuçta bunun, dil tasarımının geliştirici hatalarını önleyen güçlü bir araç olabileceğini gösteren bir örnek olduğu vurgulanıyor

---

Giriş

• Matt Godbolt’un "Correct by Construction" başlıklı konuşması, C++ API tasarımındaki sorunlara ışık tutuyor ve bu, Rust’ın felsefesiyle de örtüşüyor
• Rust’ın güçlü yanlarını anlamak için bu konuşma iyi bir başlangıç materyali

What's in a type — C++’ın sınırları

• void sendOrder(const char *symbol, bool buy, int quantity, double price) gibi bir fonksiyon imzası hatalara son derece açıktır
• Yalnızca bool, int, double gibi temel tipler kullanıldığında, yanlış tip girilse bile derleyici uyarı vermez
• using Price = double gibi tip takma adlarının gerçek bir tip ayrımı işlevi yoktur
• Sınıflar ve explicit kurucular kullanılarak Quantity, Price tanımlandığında derleyici bazı hataları yakalayabilir, ancak:
  • Negatif değerler yine de kabul edilir ve bu sorun ancak çalışma zamanında ortaya çıkar
  • static_assert ve şablonlar kullanılarak derleme zamanı kontrolleri zorlanabilir
  • Ama atoi gibi çalışma zamanı dönüşümleri hâlâ tam sayı taşmasına yol açabilir ve derleyici bunu tespit edemez

Rust bunu nasıl farklı yapıyor?

• Aynı işlev tanımında bile Rust, tip uyuşmazlığını derleme anında açık bir hata olarak gösterir
• struct Price(pub f64); struct Quantity(pub u64); gibi yeni tip tanımları da basittir ve negatif girdilerin engellenmesi doğal biçimde çalışır
• "string".parse::<u64>() örneğinde olduğu gibi, çalışma zamanındaki string dönüşümleri de açık hata işleme gerektirir
• Değeri .expect() ile zorla açmak çalışma zamanında çökme yaratabilir, ancak bunun C++’taki sessiz hatalardan daha iyi olduğu özellikle vurgulanır

Sonuç

• Rust, yalnızca bellek güvenliğinin ötesinde API yanlış kullanımını önleme, derleme zamanı kontrolleri ve açık tip sistemi ile geliştiriciyi korur
• Bunun, dil tasarımının gücünün geliştirici hatalarını en baştan önleyebileceğini gösterdiği belirtilir
• Rust’a yeni başlayanlar borrow checker ile mücadele etmenin zorluğunu yaşayabilir, ancak bunun zamanla aşıldığı söylenir
• C++ tarihsel olarak çok ilerleme kaydetmiş olsa da, hâlâ Rust gibi temelden güvenlik ve açıklık sağlamasının zor olduğu ortaya çıkıyor

Referans

• Konuşma: Correct by Construction: APIs That Are Easy to Use and Hard to Misuse
• Matt Godbolt’un çalışmaları ve Compiler Explorer

[cronex]

C++'ın dezavantajı olarak gösterilen noktaların çoğu, büyük ölçüde C diliyle uyumluluk nedeniyle korunuyor gibi görünüyor.
C ile uyumluluğu bırakıp geliştirme yapabilecek şekilde değiştirilebilir mi?

[coremaker]

Keşke unsafe sunulmasaydı.

[codemasterkimc]

Temel dil = Rust

[GN⁺]

Hacker News görüşü

• Rust'ın en büyük avantajı, hata yayılım biçiminin tek bir Result türü etrafında birleşmiş olmasıdır. İstisna işleme ya da farklı hata döndürme yöntemlerini dert etmeye gerek kalmaması çekici.

  • ? kısayolu ve Result'ın fonksiyonel arayüzü sayesinde hata işleme hem eğlenceli hem de kolay yönetilebilir.
  • C++'ın karmaşık hata işleme yaklaşımına kıyasla tutarlılık eksikliği can sıkıcı.

• C++ hakkında çok sayıda şikayet var. Özellikle, hatırlanması gereken çok fazla kural olması ve bunlardan sadece birini bile yanlış uygulamanın kodu savunmasız hâle getirebilmesi sorun.

  • C++'ın güvenliğini artırmak için Rust'ın güvenli yaklaşımına benzer bir yönteme ihtiyaç var.

• Şu anda yazılan C++ kodu Rust'a benziyor. Açık ve güçlü tipler, net yaşam süresi yönetimi gibi yaklaşımlar kullanılıyor.

  • Rust derleyicisi hataları yakalama ve raporlama konusunda daha yardımcı oluyor.

• C++'taki örtük dönüşüm sorunu dilden çok kütüphane sorunu.

  • C++'ta da Rust benzeri özellikler uygulanabilir, ancak bunun için kütüphane desteği gerekiyor.

• Rust'ta anahtar kelime argümanları ya da adlandırılmış tuple'lar olmaması, Args/Options yapılarını kullanmayı kullanışsız kılıyor.

• -Wconversion seçeneği belirli dönüşüm sorunlarını yakalayabilir, ancak her durumda geçerli değil.

  • Örneğin, 1000.0'ın 1000'e dönüştürülmesi hassasiyet kaybı olmadığı varsayıldığı için sorun sayılmıyor.

• Rust'ın daha iyi olduğu noktalardan biri, örtük sayısal dönüşümlerin olmaması. C++'ta atoi kullanmak yerine STL'nin dönüşüm fonksiyonlarını kullanmak daha iyi.

• SQL kısıtları ya da pydantic'in özel tipleri ve doğrulayıcılarına benzer işlevler Rust veya Golang'de henüz yok.

• Matt ve Ben Rady'nin programlama podcast'i "Two's Complement" ilginizi çekiyorsa dinlemeye değer.