Chuks v0.2.0-rc.1, geliştiricilerden dual bytecode ve native modlarını kırmalarını istiyor

Hem bir bytecode sanal makinesine hem de native binary'lere derlenen bir dil olan Chuks, v0.2.0-rc.1'i yayınladı — ve sürüm duyurusu bir özellik tanıtımı değil, bir çağrı gibi kurgulanmış: gerçek programları alın, her iki yürütme yolundan çalıştırın ve sonuçların farklılaştığı her durumu bildirin.

İstek

dev.to'daki duyuruya göre her Chuks sürümü, iki derleme modunun aynı sonucu üretmesine bağlı. Projenin iç kontrol sistemi zaten her iki backend'de golden testler, bir differential fuzzer, 24 differential suit ve beş hedefe çapraz derleme çalıştırıyor. Gönderinin belirttiğine göre bu makinelerin yapamadığı şey, daha önce hiç görmediği bir programı çalıştırmak. Bu yüzden ekip, geliştiricilerden release candidate ile bir şeyler inşa etmesini — ya da mevcut bir programı ona yönlendirmesini — ve iki şekilde de çalıştırmasını istiyor:

chuks run main.chuks # bytecode VM chuks build main.chuks # native binary

İki mod tam olarak aynı çıktıyı üretmiyorsa, bu ekibin kaydedilmesini istediği bir bug'dır; bildirime chuks --version çıktısı ve sorunu yeniden üreten en küçük dosya da eklenmelidir.

Açığı açıklayan iki bug

Gönderi, otomatik testlerle değil, gerçek programlar inşa edilerek bulunan iki yeni düzeltilmiş hatayı anlatıyor.

İlki, await ve spawn'ı etkileyen gramer düzeyinde bir öncelik (precedence) hatasıydı. "[" + await f() + "]" gibi bir ifade eskiden öyle ayrıştırılıyordu ki await çağrıya değil birleştirmeye uygulanıyordu. Hata her iki backend'de değil parser'da olduğundan, iki mod iki farklı yanlış sonuç üretiyordu: VM "Task(pending)" yazdırırken native binary "0" yazdırıyordu. Gönderinin açıkladığına göre ekibin fuzzer'ı programlar üretiyor ama henüz bir geliştiricinin elle yazdığı async pipeline'ı taklit etmiyor; hatanın yüzeye çıkması da böyle oldu.

İkinci bug daha öğretici olanı. Bir döngü içinde oluşturulan closure'lar her yinelemeye özel bir değer yerine hepsi aynı paylaşılan binding'i okuyordu; dolayısıyla her fonksiyon 3 döndürüyordu — iki backend'de de, aynı şekilde. Differential testing, VM ile native binary'nin hemfikir olduğunu doğrulayabilir; hemfikir oldukları şeyin doğru olduğunu doğrulayamaz. Gönderi bu hatayı, let'in yineleme başına binding'leri getirmesinden önceki JavaScript'teki var'a benzetiyor ve düzeltmenin her döngü turuna kendi binding'ini verdiğini söylüyor. Bu tür paylaşımlı bug'lar, yalnızca gerçek davranış konusunda beklentileri olan bir dışarıdan kişinin yakalayabileceği şeylerdir.

Release candidate'te ayrıca neler var

• String indeksleme artık her iki backend'de tutarlı biçimde byte sayıyor; at ve slice gibi erişimciler Unicode karakterlerin tamamına hizalanıyor; daha önce bazı metotlar VM'de karakter, native tarafta byte sayıyordu.
• Başarısızlığı eskiden sessizce kaybolan terk edilmiş bir spawn'lanmış task artık bildiriliyor — bir CLI programı için çıkışta, bir embedding host için hemen.
• Rezerve kelimeler artık record alan ve anahtar adları olarak kullanılabiliyor; böylece bir payload'ın alanlarının dili memnun etmek için yeniden adlandırılması gerekmiyor.
• Generic temel sınıflar artık modül sınırları boyunca doğru çalışıyor ve .stringify(this) üzerinden reflection tüm nesneyi, alt sınıf alanları dahil, iki backend'de de aynı şekilde görüyor.

Tüm breaking change'leri ve migration notlarını içeren tam changelog Chuks blogunda yayınlandı.

Nasıl deneyeceksiniz

Aday sürümü edinmek opt-in. Mevcut kullanıcılar chuks upgrade --prerelease çalıştırabilir; yeni kurulumlar projenin install script'i üzerinden yapılıp ardından aynı upgrade komutu veriliyor. Düz bir chuks upgrade, son v0.2.0 gerçekten yayınlanana kadar kullanıcıları v0.1.2'de tutuyor.

Neden önemli

Chuks'un dual-backend tasarımı her programı bir tutarlılık kontrolüne dönüştürüyor; ancak gönderi bu stratejinin sınırlarına dünkü kadar açık: iki backend'in eşleşen çıktıları tutarlılığı kanıtlar, doğruluğu değil — çünkü paylaşılan front-end mantığına yerleşmiş bir bug ikisini de kandırabilir. Bu itiraf — ve release candidate'yi gerçek iş yükleriyle kırmaya dair açık davet — bir uygulamayı diğeriyle doğrulayan her proje için yararlı bir şablon. Genç dilleri değerlendirenler içinse bu, ekibin kör noktalarının nerede bildiğini ve bunları bulmaları için aktif olarak kullanıcı devşirdiğini gösteriyor. rc.1'e kaydedilen tutarsızlıklar, v0.2.0'ın yayınlanmaya hazır olup olmayacağını doğrudan şekillendirecek.