Rust geliştiricileri arasında, özellikle asenkron kod yazarken, ekstra fonksiyon çağrılarının performansa olumsuz etki edeceği yönünde yaygın bir endişe bulunmaktadır. Bu durum, okunabilirliği ve sürdürülebilirliği azaltan, 20 satırı aşan büyük async fn bloklarının ortaya çıkmasına neden olabilmektedir. Makale, bu yaygın inancın Rust'ın asenkron yapısında çoğu zaman yanlış olduğunu savunuyor. Örneğin, büyük bir match kolunu ayrı bir async fn'e çıkarmak, kodun daha anlaşılır ve yönetilebilir olmasını sağlar, ancak bazıları bunun ek bir çağrı maliyeti getireceğini düşünebilir.
Yazar, bu endişenin prensipte doğru olsa da pratikte genellikle önemsiz olduğunu belirtiyor. Bir async fn'i await ettiğinizde, Rust compiler'ı genellikle çağrılan fonksiyonun durum makinesini çağıranın Future'ının durum makinesiyle birleştirir. Bu, soyutlamayı 'gerçekten ücretsiz' hale getirebilir; yani, ekstra await noktası, satır içi (inline) versiyonun üreteceği aynı durum geçişlerine derlenebilir. Parametre geçirme, ABI uyumluluğu, runtime Future durum makinesi kurulumu gibi teknik detaylar mevcut olsa da, bunlar Suspend yolunun gerçek iş yükü (I/O, kilitler, bellek tahsisi gibi) yanında ihmal edilebilir kalır.
Sonuç olarak, makale, Rust asenkron kod tasarımında yanlış detayların baskın olmasına izin vermememiz gerektiğini vurguluyor. Okunabilirlik ve sürdürülebilirlik gibi faktörler, çoğu zaman performans üzerindeki minimal indirection maliyetinden çok daha önemlidir. Geliştiricilerin, soyut performans endişeleri yerine, sistemin gerçekte neyi başarmaya çalıştığına odaklanmaları ve kodlarını daha modüler hale getirmekten çekinmemeleri gerektiği mesajı veriliyor.
Rust'ın asenkron yapısında fonksiyonları ayırmanın getirdiği dolaylı çağrı maliyetinin, kod okunabilirliği ve sürdürülebilirliği karşısında çoğu zaman ihmal edilebilir olduğu ortaya konuluyor.