Muhtemelen Rust, büyük ölçekli eşzamanlı kullanıcı alanı yazılımları için uygun bir araç olmayabilir

• Bu yazı, büyük ölçekli eşzamanlılığa sahip kullanıcı alanı yazılımlarında Rust kullanmanın zorluklarını ele alıyor.
• Rust'ın asenkron modeli, modern hesaplamanın iki temel kavramı olan eşzamanlılık ve paralelliği ele alacak şekilde tasarlanmıştır.
  • Paralellik, kodun birden fazla CPU üzerinde aynı anda çalıştırılmasını içerir.
  • Eşzamanlılık ise problemi ayırmayı, onu bağımsız parçalara bölmeyi ve sıra gözetmeksizin ya da kısmi bir sırayla çalıştırmayı içerir.
• Yazı, süreçler arası iletişimin maliyetli olması nedeniyle eşzamanlılık için birden fazla süreç kullanmanın sınırlarını vurguluyor.
• Aynı belleği paylaşan süreçler olan thread'ler bir alternatif olarak sunulsa da, yarış durumu ve deadlock gibi karmaşık sorunlara yol açabilir.
• Tony Hoare'un 1978 tarihli "Communicating Sequential Processes" makalesi, thread'lerin birbirlerine mesaj göndermesi için kuyruklar veya kanallar kullanılmasını önerdi; bu yaklaşım, süreç benzeri izolasyon ve daha kolay hata ayıklama gibi çeşitli avantajlar sunar.
• Rust'ın standart kütüphanesinde std::sync::mpsc::sync_channel altında kanallar bulunur.
• Ancak, on binlerce kullanıcıya bağlı bir web sunucusu gibi yüksek düzeyde eşzamanlılık gerektiren problemler için thread'ler yeterli olmayabilir.
• Rust, bu tür durumlar için, bir fonksiyon asenkron olarak işaretlendiğinde future veya promise döndüren ve sonuç üretmek için beklenebilen async/await modelini kullanır.
• Avantajlarına rağmen asenkron Rust, derleyiciyi her şeyin yolunda olacağına ikna etme gerekliliği gibi zorluklar barındırır. Bu da ham thread'lerle zor olabilir.
• "Atomic reference count" ya da Arc kullanımı bir çözüm olarak önerilse de, garbage collector sorunlarına benzer problemlere yol açabildiği için her derde deva değildir.
• Yazı, Rust'ın diğer alanlardaki güçlü yanlarına rağmen, büyük ölçekli eşzamanlılığa sahip kullanıcı alanı yazılımları için en uygun araç olmayabileceğini öne sürerek sona eriyor.

[GN⁺]

Hacker News görüşü

• Yazar, gerçek zamanlı olarak büyük miktarda veriyi işlemek zorunda olan yüksek performanslı bir metaverse istemcisini Rust ile geliştiriyor.
• Yazarın projesi; grafik render etme, ağ olaylarını işleme, varlık yükleme gibi çeşitli işler için birden fazla thread kullanıyor.
• Rust bu projede faydalı oldu; yazar, genelde başkalarının "unsafe" kodu yüzünden yılda bir kez bellekle ilgili çökme yaşadığını söylüyor.
• Yazar, Rust'ta race condition olmasa da deadlock olmadığının söylenemeyeceğini eleştiriyor ve statik bir deadlock analizörüne ihtiyaç olduğunu öne sürüyor.
• Yazar, Rust'ta async'in yaygın kullanımını eleştiriyor; bunun hesaplama ağırlıklı işler için uygun olmadığını ve farklı önceliklerde çalışan thread'lerle uyumlu olmadığını savunuyor.
• Yazar, Rust'ın tekil sahiplik modelinin geri referanslarla birlikte yaygın bir ihtiyaç olduğunu, ancak uygulanmasının fazla zor olduğunu öne sürüyor.
• Yazar, Rust oyun ekosisteminin ciddi oyun geliştirme için hazır olmadığına inanıyor ve Rust'ta oyuncak olmayan grafiklerin eksikliğini buna gerekçe gösteriyor.
• Diğer yorumlar, async Rust'ın zorlayıcı ve çoğu zaman gereksiz olduğu konusunda hemfikir; Go'nun her şeyi sync yapıp tek bir async kanal kullanma yaklaşımının daha iyi olabileceğini öne sürüyorlar.
• Bazı yorumcular, Rust ekosisteminde async'in yaygın kullanımını eleştiriyor; bunun programı baştan sona async hale getirmeye ya da pek çok şey için tokio crate'ine bağımlı olmaya zorladığını savunuyorlar.
• Bazı yorumcular, Rust'ın async özelliklerinin hâlâ geliştirilmekte olduğunu ve mevcut durumunu eleştirmenin erken olduğunu öne sürüyor.
• Bir yorumcu, Rust'taki Arc'ın bilinemez bir şey olmadığını; bunun nerede ve nasıl tutulduğuna bağlı olduğunu savunuyor ve yazarın önceki zihinsel modelini Rust'a dayatmaya çalıştığını öne sürüyor.
• Bazı yorumcular, genel olarak async/await kullanımına karşı çıkıyor; bunun dili ve ekosistemi ikiye böldüğünü ve uzun vadeli sorunlar yarattığını savunuyorlar.
• Bir yorumcu, eşzamanlılık için doğru ilkelin, Hoare'nin Communicating Sequential Processes yaklaşımının Java'da (JDK17 sonrası - Java Virtual Threads), Go'da ve Kotlin'de uygulandığı gibi green thread'lere eşlenmesi olduğunu öne sürüyor.
• Bir yorumcu, async-scoped gibi unsafe crate'ler kullanarak, C++ ile yazılmış olsaydı ortaya çıkacak hataların çoğunu yakalamanın makul bir uzlaşma olduğunu öne sürüyor.