Zig'in gerçek dünyadaki CLI araç geliştirmede neden Rust'tan daha pratik hissettirdiği

 (dayvster.com)
6 puan yazan GN⁺ 2025-09-27 | 3 yorum | WhatsApp'ta paylaş
  • Bellek yönetimi konusunda Zig, Rust'a kıyasla daha basit ve sezgisel bir yaklaşım sunar
  • Rust'un borrow checker'ı güçlüdür, ancak küçük CLI araçları geliştirirken gereğinden fazla karmaşıklık ve geliştirici yükü yaratır
  • Zig'in manuel bellek yönetimi, uygun araçlar ve biraz geliştirici disipliniyle verimli bellek güvenliği sağlama imkanı sunar
  • Program güvenliği, bellek güvenliğinin ötesinde öngörülebilir davranış, yönetilebilir performans, veri koruma gibi çeşitli unsurları da kapsar
  • Rust büyük ölçekli sistemler için uygundur, ancak küçük ve pratik CLI araçlarında Zig, geliştirme verimliliği ve bakım açısından daha avantajlıdır

Genel Bakış

Son zamanlarda CLI araçları geliştirirken Rust yerine öncelikli olarak Zig'i seçiyorum.

Bellek Yönetiminin Temeli: Stack ve Heap

  • Stack, fonksiyon parametreleri, yerel değişkenler, dönüş adresleri gibi çok geçici verileri saklayan hızlı ve sabit boyutlu bir bellek alanıdır
  • Heap, dinamik bellek tahsisi için kullanılan alandır; verinin ömrü uzun olduğunda veya boyutu çalışma zamanında belirlendiğinde tercih edilir
  • Stack yapısal olarak basittir ama alanı sınırlıdır; heap ise hız ve parçalanma açısından daha fazla dikkat gerektirir

Rust'un Borrow Checker'ı

  • Rust'un borrow checker'ı, derleme zamanında bellek güvenliğini garanti eder
  • Referans, sahiplik ve yaşam süresi (lifetime) gibi kuralları zorunlu kılarak null pointer dereference, dangling pointer gibi hataları daha oluşmadan engeller
  • Ancak bellek güvenliği yalnızca derleme zamanı ölçütlerine göre denetlenir; kullanıcının hatalarını ya da karmaşık sahiplik tasarımı sorunlarını tamamen ortadan kaldırmaz

Örnek: Kendi Notes CLI Aracım

  • Kişisel not yönetimi için bir CLI aracını Rust ile yazmaya çalışırken borrow checker nedeniyle yapıyı zorlayarak yeniden tasarlamak zorunda kaldım
  • Buna karşılık Zig'de yalnızca allocator kullanarak pointer tabanlı indeks oluşturma ve serbestçe değiştirme/silme işlemleri çok daha basit şekilde yapılabildi
  • Rust'un borrow checker'ının amacı nettir; ancak Zig, temel bellek yönetimi bilgisi ve disiplinle bile yüksek düzeyde verimlilik ve güvenlik sağlamayı mümkün kılar

Bellek Güvenliğinin Ötesinde CLI Araçlarında Güvenlik

  • Bir ürünün gerçek güvenliği; öngörülebilir davranış, hata durumunda anlamlı geri bildirim, hassas verilerin korunması, saldırılara dayanıklılık gibi birçok unsuru içerir
  • Rust da Zig de bellek güvenliği dışındaki koşulları karşılamıyorsa "güvenli" sayılmaz
  • Örneğin bir CLI, hata durumunda sessizce verinin üzerine yazıyor ya da dosya izinlerini yanlış ayarlıyorsa kullanıcı ciddi sorunlar yaşayabilir

  • CLI araçlarında güvenlik

    • Öngörülebilir davranış: Hatalı girişte veya beklenmeyen durumlarda bile tutarlı ve açık davranış garanti edilmelidir
    • Çökme ve veri bozulmasını önleme: Hatalar zarif biçimde ele alınmalı; veri bozulması veya raporlanmayan çökme durumları engellenmelidir
    • Performans yönetimi: Büyük miktarda veri işlendiğinde bile kaynak tüketimi veya yanıt verebilirlikte bozulma olmamalıdır
    • Hassas bilgilerin korunması: Geçici dosyalar ve izin ayarları konusunda dikkatli olunmalıdır
    • Saldırılara dayanıklılık: Girdi doğrulama, bellek taşması, injection saldırıları gibi durumlara karşı sağlam olunmalıdır

Rust Borrow Checker'ın Güçlü ve Zayıf Yanları

  • Güçlü yanlar

    • Veri yarışı ve yinelenen referansları engelleme: Derleyici, tek bir mutable referans ve birden çok immutable referans kuralını garanti eder
    • Güçlü derleme zamanı garantileri: Bellekle ilgili hataların çoğu çalıştırmadan önce engellenir
    • Hataları erken bulma: Ticari servislerde veya eşzamanlılık içeren sistemlerde büyük avantaj sağlar

  • Sınırlar ve zorluklar

    • Bilişsel yük: Küçük CLI işlerinde bile sahiplik/yaşam süresi/referans yönetimi üzerine düşünmek kaçınılmazdır
    • Boilerplate / yapısal çarpıtma: Rc, RefCell gibi wrapper'lar, aşırı clone kullanımı, yapıyı yeniden tasarlama gibi nedenlerle "sorun çözmeye" değil "derleyiciyi memnun etmeye" odaklanılır
    • Mantıksal / durumsal hatalar karşısında etkisiz kalma: Yalnızca bellek kurallarını garanti eder; öngörülebilirlik, mantık hataları veya veri bütünlüğünü garanti etmez
    • Uç durum karmaşıklığı: Cache, global durum, mutable index gibi yapılarda lifetime çatışmaları kolayca ortaya çıkabilir
  • Sonuç olarak küçük CLI projelerinde Rust'un borrow checker'ı geliştirici için bir "zihinsel vergi" haline gelir ve gereğinden fazla karmaşıklık yaratabilir

Zig'in Güvenlik ve Basitlik Yaklaşımı

  • Zig, isteğe bağlı güvenlik kontrolleri ve manuel bellek yönetimi temeline dayanır
  • Yerleşik allocator kavramı sayesinde yapısal ve öngörülebilir bellek kullanımı uygulanabilir
  • Hatta özel allocator'lar oluşturarak projenin özelliklerine uygun bir bellek yönetimi yaklaşımı belirlemek mümkündür
  • Zig'in defer sözdizimi sayesinde kapsam sonlandığında otomatik serbest bırakma ve kaynak temizliği çok daha sezgisel hale gelir
  • Rust'tan farklı olarak geliştirici sorumluluğunu öne çıkarır; disiplin gerektirir, ancak yapı iyi tasarlanırsa bellek güvenliğine ulaşmak ve bunu korumak kolaydır
  • Zig'de kod daha sadedir; pointer, liste ve index gibi yapıların değiştirilmesi Rust'a kıyasla çok daha basittir
  • Rust'taki kadar kısıtlanmadan da aynı düzeyde güvenli ve verimli kod yazmak mümkündür
  • Buna ek olarak Zig'in comptime özelliği, derleme zamanında kod çalıştırma, test ve optimizasyon için büyük fayda sağlar

Geliştirici Deneyiminin (Developer Ergonomics) Önemi

  • Geliştirici deneyimi (ergonomics), dilin sözdizimi, araçları, dokümantasyonu ve topluluğunu kapsayan bir unsurdur
  • Rust, çok katı kuralları sayesinde nihayetinde bellek güvenliği sağlar; ancak aşırı kuralcılık ve ceremony üretkenliği düşürür
  • Zig, geliştirici odaklı tasarımı öne çıkararak kodu daha kolay ve hızlı yazmayı, değiştirmeyi ve anlamayı mümkün kılar
  • Zig, sezgisel kod, hızlı yineleme, düşük zihinsel yük sayesinde geliştiricinin araçlarla boğuşmak yerine probleme odaklanmasını sağlar
  • Zig geliştiriciye güvenir ve uygun araçlarla seçim özgürlüğü sunar; buna karşılık Rust zaman zaman fazla denetleyici ve kısıtlayıcı hissettirebilir
  • Geliştirici dostu ortam, geliştiriciyi sadece "hatalardan korumak" değil, kendi hatalarından öğrenip gelişme fırsatı vermek anlamına da gelir

Sonuç

  • Büyük, çok iş parçacıklı, uzun süre çalışan sistemler gibi Rust'un avantajlarının en üst düzeye çıktığı alanlarda Rust hâlâ en iyi seçimdir
  • Ancak küçük ve pratik CLI araçları için Zig'in hafifliği, sadeliği, hızlı geliştirme ve bakım kolaylığı daha uygundur
  • Bellek güvenliği, güvenlik yapbozunun yalnızca bir parçasıdır; öngörülebilir davranış, bakım kolaylığı ve dayanıklılık gibi CLI araçları için kritik unsurlar Zig'de daha kolay sağlanabilir
  • Sonuçta önemli olan "daha iyi dil" değil, **kişinin iş akışına ve projenin özelliklerine uygun "doğru aracı seçmek"**tir
  • Zig, "bellek güvenliği + düşük zihinsel maliyet + geliştirici dostuluğu / üretkenlik" birleşimiyle küçük araç geliştirme için çok iyi uyum sağlayan bir dildir

İlgili okumalar

3 yorum

 
shakespeares 2025-10-05

Bence ekosistemi henüz Rust kadar istikrara kavuşmuş görünmüyor.
 
bus710 2025-09-27

Zig’de yeni sürümlerde kırıcı değişiklikler oldukça sık olduğu için... küçük bir proje olsa bile mümkünse CI ekleyip düzenli olarak yönetmek gerektiğini fark ettim.
 
GN⁺ 2025-09-27
Hacker News görüşü

  • Zig'in avantajı, C geliştiricisi gibi düşünmeye devam etmeyi sağlaması; ama bunun bir noktaya kadar sadece aşinalık meselesi olduğunu düşünüyorum

    • Rust'a yeterince alışmış geliştiriciler artık borrow checker ile savaşmıyor; zaten kodu o yapıda düşünmeye başlıyorlar

    • Rust'ta “object soup” benzeri bir yaklaşım pek işlemiyor ama bunun temelde daha kolay bir yöntem olduğunu da sanmıyorum; sadece alışık olduğumuz için kolay geliyor

    • ergonomics'i ölçmenin ya da sayısallaştırmanın zor olduğunu kabul edince, bu tür tartışmalar doğal olarak muğlak kalıyor

      • Bu, "Bu sandalye çökmez, gönül rahatlığıyla otur; biraz daha az rahat ve daha ağır olabilir ama çoğu insan yakında alışır ve rahatsızlığı fark etmez" demeye benziyor
      • Asıl yazıdaki ifade gibi, "Rust geliştirici deneyimini zorlaştırır ama bellek güvenliği sağlar; Zig ise daha iyi geliştirici deneyimi ve biraz dikkatle bellek güvenliği sağlayabilir" demek sonuçta güvenlik ile kullanılabilirlik arasında bir takastır
      • Rust topluluğunun bu tür trade-off'ları dürüstçe kabul etmesi gerektiğini düşünüyorum; güvenliği artırmak her zaman daha düşük konforu beraberinde getirir
      • Bunun temeli güvenlikte, hayatta, gündelik yaşamda ve yazılımın genelinde var; ama çoğu iddia belirsiz ya da öznel
      • Bazıları ergonomics tartışmasını kolayca "alışkın olanlar için sorun yok" diye geçiştiriyor; bu da "bu bile sana zorsa yeterince zeki değilsin" gibi algılanabiliyor

    • “borrow checker ile savaş” söylemi, Rust'ta sadece lexical lifetime'ların anlaşıldığı dönemden kalma bir anlatı

      • Ben 2021'de Rust öğrenirken bu zaten geçmişte kalmış eski bir hikâyeydi
      • Gerçekte sadece Python, C ya da JavaScript kullanmış biri için Rust'a alışmak kolay olmayabilir
      • Benim için kolaydı ama çoğu kişinin böyle hissetmediği anlaşılıyor
      • Ama “Rust'ta diagnostic mesajlarını okuyup kodunu düzeltmen gerekir” demek, “borrow checker ile cesurca savaşırsın” kadar havalı gelmiyor; bence durumu daha dürüst anlatmak lazım

    • Benim deneyimimde usta Rust geliştiricileri her yere Arc serperek onu fiilen otomatik garbage collection gibi kullanıyor

      • Statik bellek yönetimi oldukça katı olduğu için karmaşık veri yapılarında pratikte zorlaşıyor
      • lifetime'ların gerektirdiği takip yolu insanın bilişsel kapasitesini aşacak kadar fazla olabiliyor

    • Usta Rust geliştiricilerinin bile açık kaynak Rust projelerinde her yere Arc, Clone, Copy vb. kullandığını çok gördüm

    • Zig'in artısı, C'deki tanıdık geliştirme tarzını korurken dil ve tooling tarafında güvenliği destekleyen özellikler sunması

      • Örneğin Zig'deki optional sayesinde nil dereference sorunlarından kaçınılabilir
      • Debug veya test sırasında debug/custom allocator'ı doğrudan geçirip runtime kontrolleri, bellek erişimi ve kaynak sızıntısı kontrolleri de kolayca yapılabilir
      • Açık interface/trait olmamasından memnun değilim ama benimsenmesi basit olduğu için pratik buluyorum

  • Ben asıl yazının çoğuna katılmıyorum

    • Rust da C veya Zig gibi lifetime, ownership ve borrow scope üzerine düşünmeyi gerektiriyor; fark, derleyicinin yardım edip etmemesi

    • Ne kadar zeki olursan ol, yorgunken ya da dikkatin dağınıkken hata yapmak insanidir; bunu kabul etmek akıllıcadır

    • Rust derleyicisinin güvenli saydığı programlar kümesi yeterince geniş değil; bu yüzden gayet normal programları epey sık reddediyor

    • Örnek: Foo adlı bir struct içinde bar ve baz ayrı string'lerse, bar için mutable reference aldıktan sonra baz için immutable reference almaya çalıştığında derleme başarısız olur; böyle durumlarda kod yapısını zorla dolandırmak zorunda kalırsın

    • Buna karşılık şu da var: “gerçekte sorun olmayan bir durumun derleyici tarafından reddedilmesini önlemek için” kodu ikinci ya da üçüncü en iyi tasarıma çevirmek başlı başına büyük bir yük

      • Bu, tüm kod tabanının tasarımını değiştirebilir
      • Oyun geliştiricileri gibi zor işler yapanların Rust benimsemekte zorlanmasının sebeplerinden biri olarak da bu gösteriliyor
      • Eğer Rust compiler hiç false positive üretmeden kusursuz çalışsaydı, ergonomics açısından da zirvede olurdu; ama gerçek dünya öyle değil

    • Bu örnek gerçekten çok iyi görünüyor; blogumda ya da bir yazıda ele almamda sakınca olur mu diye sormak isterim

    • O kodu görünce tam tersine iddiama olan güvenim biraz daha azaldı

  • Her programın mutlaka bu kadar "güvenli" olması gerekmediğini hatırlamalıyız

    • Bir sürü unsafe yazılımla eğlenerek büyüdük; Star Fox 64, MS Paint, FruityLoops gibi

    • Zig'in yaratıcısı Andrew Kelley'nin de, müzik prodüksiyon yazılımı (DAW) geliştirmek için uygun ortam olmadığı için Zig'i yaptığını okumuştum; Zig'in böyle yaratıcı yazılımlara iyi uyduğunu düşünüyorum

    • Bellek hatalarına duyarlı olan herkes Rust kullanabilir

    • Hatta Super Mario World'ün bellek hataları yüzünden daha eğlenceli olduğuna inanıyorum

    • "Güvenlik", "programım amaçladığım gibi çalışıyor" ifadesinin kısaltmasıdır

      • İstenmeden yazılmış mantıksız kodlar, yani semantic gibberish, amaca ulaşmayı zorlaştırır
      • Elbette kasıtlı olarak anlaşılmaz kod yazılan durumlar da var; IOCCC, hacking ya da code poetry gibi; ama oralarda da iş dikkatle işlenmeli
      • Rust'ta da escape hatch (unsafe) ile bunları bilerek yapmak mümkün
      • Buradaki iddia, istemeden anlamsız kod yazabilmenin bir avantaj olduğu yönünde; buna kolayca katılamıyorum
      • Eğer her kodu hiçbir bedel olmadan güvenli yapabilseydik, bunu kim istemezdi ki?
      • Super Mario World speedrun'ları da sonuçta binary patch ile yapılabilir; eğlencenin tek kaynağı giriş üzerinden bellek manipülasyonu değil

    • Biraz kafam karıştı; söylediklerimin kötü bir görüş sayılmasının nedeni bellek güvenliğinin önemsiz olduğunu ima etmem mi diye merak ettim

  • borrow checker'ın değerinin küçümsenmesi bana üzücü geldi

    • Rust'ın borrow checker'ı geçersiz bellek erişimlerini derleme zamanında engeller

    • Elbette bunun bedeli, kodu derleyicinin kurallarına uyan bir yapıya dönüştürmek zorunda kalmaktır

    • Rust'ı tek başıma kullanırken hiç lifetime annotation'ların yanlış olduğunu düşünmedim; biraz angarya gibiydiler ama hızlıca alıştım

    • unsafe kullanmadığın sürece Rust'ta iki thread aynı belleğe aynı anda yazamaz

    • "CLI araçlarında Zig neden daha pratik geliyor" sorusuna pek katılmıyorum; Rust'ın CVE'leri önleme tarafında hâlâ güçlü bir avantajı var

    • Ben zaten çoğu işi GC'li dillerle de rahatça yapıyorum; başka dillere katkı verirken de Rust, Zig, C/C++ fark etmiyor

    • CLI araçları özel bir kategori değil mi?

      • Genelde CLI araçları çok büyük olmaz ya da tek kişi tarafından geliştirildiği için yönetmesi daha kolaydır
      • Zig veya C, çok büyük kod tabanlarına pek uygun olmayabilir; daha karmaşık projelerde bir babysitter gerekir
      • Buna benzer eski bir tartışmada Java da "babysitter dili" diye anılmıştı ama pratikte birçok kod tabanı gerçekten buna ihtiyaç duyuyor

    • unsafe kullanmadan iki thread'in aynı belleğe aynı anda yazamaması konusu da o kadar net değil

      • Benim derleyiciden asıl beklediğim yardım çoğunlukla memory ordering problemlerini çözmesi
      • Rust bu tarafta race oluşsa bile bunu unsafe değil safe olarak sınıflandırabiliyor

  • Rust'ta backlinks uygulamanın gereksiz yere karmaşık olduğuna katılıyorum

    • Rc, Weak, RefCell, .borrow() gibi araçlarla mümkün ama kolay değil

    • Kısa süreli çalışan programlarda arena allocation da bir yöntem olabilir; sanırım CLI aracı derken kastedilen de bu

    • Rust asıl gücünü büyük, çok iş parçacıklı ve uzun süre çalışan uygulamalarda gösteriyor

    • Ben gerçekten Rust ile büyük bir metaverse istemcisi yazdım ve onlarca thread'i 24 saat çalıştırmama rağmen bellek sızıntısı ya da çökme yaşamadım

    • Aynı şeyi C++ ile yapmak için QA ekibi ve Valgrind gibi araçlar şart olurdu; script dilleri ise performans açısından fazla yavaş kalır

    • Ben de Rust ile Dünya'nın eğriliğini ve yerçekimi sapmalarını hesaba katan fizik simülasyonlu bir uçak yaptım

      • 5 saatlik ve 22 saatlik rota testlerini yıllarca sorunsuz çalıştırdım
      • 7 yılda Rust'ta yaşadığım çökme sayısı çok az oldu; C/C++'ı artık sadece eski miras kodu düzeltirken kullanıyorum

  • Zig çekici ama D de hâlâ var ve kişisel olarak D'nin benim istediğim C/C++ alternatifi olduğunu hissediyorum

    • Zig'in sözdizimi bana biraz tuhaf geliyor; Rust ise artık ekosistemin merkez oyuncularından biri

    • Go da birçok dil aracında yüksek paya sahip ve yapay zeka alanında Python'dan sonra en çok kullanılan dillerden biri

    • Rust'tan önce Go vs. D tartışmaları vardı; ben de D kitabı bile almıştım ama sonunda Go'ya geçtim

      • Bana göre standart kütüphane çok daha kullanışlıydı ve int64 gibi tür adları daha sezgiseldi

    • D iyi ama onu yaygınlaştıracak bir killer app çıkmadı

  • CLI aracı yazmak için neden özellikle Rust ya da Zig seçmek gerektiğini pek anlamıyorum

    • Darboğaz genelde I/O'dur; GC'nin yavaşlığı değil

    • GC meselesi oyunlar, veritabanları gibi bellek yoğun alanlar dışında esas tartışma konusu değil

    • Bellek güvenliği tartışmaktan çok, neden GC'siz bir dil seçmek gerektiğini düşünmenin daha önemli olduğunu vurguluyorum

    • Eğer sebep “no-GC eğlenceli olduğu için” ise bu tek başına yeterlidir; ayrıca tartışmaya gerek yok

    • Anında startup time, yani açılışta gecikme olmaması, gerçekten çok faydalı

      • Bir wrapper araç yazarken onu binlerce kez çalıştırmak sorun olmuyor
      • Python benzeri ortamların dağıtım karmaşıklığı olmadığı için dağıtım da kolaylaşıyor

    • Go ile CLI yapmak gerçekten gayet iyiydi, her ne kadar Go dilini kendim çok sevmesem de

      • Python tabanlı CLI'lar bağımlılık çoğaldıkça dağıtımda zorlaşıyor; Rust ve Zig de Go gibi statik binary dağıtımının kolay olması sayesinde popüler

    • Ben bir dil seçerken sum type, pattern matching ve async desteğini öncelikli ararım

      • Rust olmasa bile hataları derleme zamanında yakalayan özellikleri seviyorum

    • GC'siz geliştirmenin sadece oyun alanına özgü olduğu itirazına karşılık

      • Pratikte birçok mobil oyun da Unity + il2cpp gibi ortamlarda GC kullanıyor ve GC performansı çoğu zaman çok iyi değil

    • GC tartışması bana biraz bandwagon etkisi gibi geliyor

      • 50 yıl önce bile Interlisp ve Cedar gibi büyük workstation sistemleri GC tabanlı dillerle başarıyla yapılmıştı
      • Bugünün donanımı 1970'lerin CLI'larından ya da Electron uygulamalarından çok daha güçlü ama bunu verimli kullanmakta hâlâ zayıfız

  • Rust'ın built-in borrow/reference modeliyle basit bir not aracı yaptım ve düşündüğüm kadar karmaşık değildi

    • Bir notes listesinde indeksleri saklayıp bunları bir map ile bağlayan bir yapı düşünürsen, hız farkı neredeyse yok ve güvenlik açısından da bir eksisi yok

    • İndekste hata yapsan bile bu, kernel belleğini ezmektense sınır aşımı hatası olarak yakalanır; bu çok daha iyi

    • printf debugging sırasında da çok daha kolay ve sezgisel oluyor

    • raw pointer ya da reference genelde allocator veya async runtime gibi gerçekten gerektiği yerlerde kullanılmalı; genel mantıkta index-based yaklaşım daha uygun

    • Rust async tarafında self-referential struct kullanılamadığı için Pin ile ilgili sorunların çıkmasının meşhur nedeni de bu

    • vec içine konmuş değerlerin pointer'ları realloc gibi durumlarda geçersiz olabildiğinden, bu durumda Miri hemen hata verir

  • Bir C++ geliştiricisi olarak güvenli bir dil arıyor olsam Swift bana en uygun seçenek gibi gelirdi

    • İnsanın tanıdık ya da benzer bir dile daha hızlı alışması doğal

    • Swift son dönemde cross-platform desteğini de güçlendirdi ve aktif C++ standart komitesi üyelerinden birkaç kişi de işin içinde

    • Ama Apple bağlantısı ve yerel UI framework eksikliği gibi nedenlerle Apple dışı tarafta yayılması daha sınırlı kaldı

    • Swift'in daha da popülerleşmesini isterim

    • Swift ile Zig/C'yi karşılaştıran iyi kaynaklar varsa öneri almayı isterim

  • Zig'in biraz dikkatle bellek güvenli yazılım üretebileceği söyleniyor ama aslında C de yeterince disiplinli kullanılırsa benzer sonuca ulaşabiliyor

    • Sonuçta sorun da bu “biraz disiplinin” gerçek hayatta çoğu zaman eksik olması

    • Zig ayrıca şu sorunları da çözüyor

      • sınır dışı erişim (tüm CVE'lerin %70'ini oluşturuyor)
      • null pointer dereference
      • type safety
      • C'den katbekat iyi ve use-after-free gibi hatalar da sınır dışına çıkılmadığı sürece çok daha kolay önlenebiliyor
      • Zig'in mükemmel cross-platform build sistemi, comptime optimizasyonları ve C++/Rust'tan onlarca kat hızlı build time'ı da güçlü yanları arasında
      • standart kütüphane hâlâ zayıf ve ufak tefek sorunlar sürüyor ama perf-oriented programlar için geleceğinin parlak olduğunu düşünüyorum

    • C 50 yıldan uzun süredir bu disiplin meselesinde başarısız olduysa, demek ki bu iş "Shaolin yolu"ndan bile daha zor