ClojureScript'e Async/Await eklendi

 (clojurescript.org)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • ClojureScript 1.12.145 ile derleyici, ^:async ipucu eklenmiş fonksiyonları JavaScript async function olarak üretecek şekilde değiştirildi
  • await ile Promise değerlerini bekleyen ClojureScript fonksiyonları yazılabildiği için JavaScript birlikte çalışabilirliği iyileşti
  • Testlerde de ^:async kullanılabiliyor ve await ile asenkron fonksiyon çağrılarının sonuçları doğrulanabiliyor
  • Yakın tarihli Clojure anketinde async functions desteği, JavaScript birlikte çalışabilirliğiyle ilgili ClojureScript iyileştirme talepleri arasında en yüksek paya sahip oldu
  • Modern tarayıcı API'leri ve popüler kütüphanelerle çalışılan yaygın durumlarda ek bağımlılık ekleme ihtiyacı azalıyor; değişikliklerin tam listesi ClojureScript changelog içindeki 1.12.145 girdisinde görülebilir

^:async ve await kullanımı

  • ClojureScript 1.12.145 ile derleyici, ^:async ipucu eklenmiş fonksiyonları JavaScript async function olarak üretecek şekilde değiştirildi
  • ClojureScript'in ECMAScript 2016 hedeflemesiyle birlikte, JavaScript birlikte çalışabilirliğini iyileştirme alanları daha dikkatli seçilebilir hale geldi
  • await kullanarak Promise değerlerini bekleyen ClojureScript fonksiyonları yazmak mümkün hale geldi 
    (refer-global :only '[Promise])

(defn ^:async foo [n]
  (let [x (await (Promise/resolve 10))
        y (let [y (await (Promise/resolve 20))]
            (inc y))
        ;; not async
        f (fn [] 20)]
    (+ n x y (f))))
  • Testlerde de ^:async kullanılabiliyor ve await ile asenkron fonksiyon çağrılarının sonuçları doğrulanabiliyor 
    (deftest ^:async defn-test
  (try
    (let [v (await (foo 10))]
      (is (= 61 v)))
    (let [v (await (apply foo [10]))]
      (is (= 61 v)))
    (catch :default _ (is false))))

Arka plan ve değişiklik listesi

  • Yakın tarihli Clojure anketinde async functions desteği, JavaScript birlikte çalışabilirliğiyle ilgili ClojureScript iyileştirme talepleri arasında en yüksek paya sahip oldu
  • Bu iyileştirmeyle birlikte, modern tarayıcı API'leri ve popüler kütüphanelerle çalışılan yaygın durumlarda ek bağımlılık ekleme ihtiyacı azalıyor
  • Tüm düzeltme, değişiklik ve iyileştirme listesi ClojureScript changelog içindeki 1.12.145 girdisinde görülebilir
  • ClojureScript 1.12.145'e topluluk üyesi Michiel Borkent katkıda bulundu

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri

  • borkdude bu başlığı açmış, ayrıca bu sürümün katkıcıları arasında da yer aldığını gördüm
    Uzun zamandır async/await desteğine karşı ana argümanlar kabaca iki taneydi: bunun CLJS derleyicisinin geneline derin değişiklikler gerektirmesi ve Promesa gibi kütüphanelerin makrolarla benzer bir kullanım kolaylığı sunması
    Bunun dışında core.async kullanmanın yeterli olduğu ya da ifade odaklı bir dilin async/await ile pek iyi uyuşmadığı da söyleniyordu, ama bunlar forumlarda tekrar edilen baskın görüşlerden çok kişisel kanaatlere yakındı
    borkdude, Clojurians Slack'te desteğin eklenmesinin gerçek dışı olduğuna kesin gözüyle bakmadığını söylemişti; sonunda zaman ayırıp bunu hayata geçirmiş gibi görünüyor, gerçekten minnettarım

    • Borkdude önce kendi alternatif ClojureScript uygulaması olan Squint içinde async/await'i hayata geçirerek bunun mümkün olduğunu göstermiş gibi duruyor; oradan öğrendiklerini de ana CLJS derleyicisine taşımış olmalı

  • İlginç olan şu ki ClojureScript, JavaScript'in kendisine async/await gelmesinden çok önce core.async kütüphanesiyle asenkron programlama paradigmasını destekliyordu
    Bununla bu sürümün değerini küçümsemeye çalışmıyorum; sadece, bağımlılıklara bir kütüphane ekleyerek ana dilde henüz var olmayan yeni bir dil özelliğini kullanabilmenin ne kadar havalı olduğundan bahsediyorum. Clojure gerçekten etkileyici

    • Kesinlikle öyleydi. Çok kullandım, iyi de çalışıyordu; bazı küçük tuhaflıkları olsa da fiilen 10 yıldan uzun süredir async/await'e sahiptik
      Sanırım bunu David Nolen'in bir konuşmasından öğrenmiştim
      Sonrasında ön yüzde JavaScript'i minimumda tutmaya yöneldim ve SSE tek yönlü olduğu için bu açıdan çok zarif. Bugünlerde farklı dil topluluklarından geliştiricilerin SSE'ye ilgi duyması hoşuma gidiyor
      David Nolen'in yakın tarihli “A ClojureScript Survival Kit” sunumu da çok iyiydi: https://youtu.be/BeE00vGC36E
      David “Swannodette” Nolen'in ClojureScript ve core.async'in ilk günlerinden beri yaptığı işler için ne kadar teşekkür etsek az. Bu sunumda özellikle şaşırtıcı olan, onun ClojureScript'i bırakıp sunucu tarafında saf Clojure, server-sent events ve çok az miktarda JavaScript kullanılan bir yöne gerçekten heyecanla bakması
      Asıl demo yaklaşık 26:30'da başlıyor. İstemcide çalışan web uygulamasının kaynak kullanımını gösterdikten sonra, aynı uygulamayı sunucuda çalıştırıp SSE ile istemciye tek yönlü olarak ittiğini gösteriyor; kaynak kullanımı neredeyse sıfıra indiği için oldukça çarpıcı
      Her duruma uymaz ama minimum DOM değişikliği yapan bir kütüphane kullanınca web uygulamasını ve durumunu zihinde modellemek çok daha kolay hale geldi. Eskiden hem Clojure için bir REPL hem de ClojureScript için bir REPL açıp iki yönlü trafiği ve yeniden üretmesi zor durumları uğraşmam gerekirdi; şimdi her şey çok daha hızlı ve yeniden üretmesi daha kolay
    • Doğru, ama 2026'da core.async'ten kaçınmak için de pek çok neden var
      JavaScript çıktısı büyüyor, yerleşik bir hata modeli yok ve işler ters gidince okunması ve debug edilmesi zor durum makinesi koduna dönüşüyor
      Üstelik go makrosu kendi S-ifadesinin dışındaki kodu dönüştüremediği için işlevlerin gereğinden fazla büyümesine yol açıyor
      Cognitect'ten birinin dediği gibi, “core.async güzel bir saçmalık”

  • Son zamanlarda sosyal medyada Clojure/ClojureScript'i daha sık görmem biraz şaşırtıcı
    2012 civarında birkaç yıl işte kullanmıştım ama diğer birçok kişi gibi JVM'den ayrılıp tipli fonksiyonel dillere geçtim
    Bugünlerde ilginin artması etken kodlama yüzünden mi? Tip kontrolünün olmaması, daha az yanlış sözdizimi hatası ve daha az ayrılmış sözcük olması nedeniyle kodu gözden geçirmek daha mı hızlı? S-ifadelerinin dönüşü mü geliyor diye merak ediyorum

    • Ben şahsen tipli fonksiyonel dillerden ClojureScript'e, ardından da yaklaşık 10 yıl önce Clojure'a geçtim
      Bildiğim ciddi Clojure kod tabanları test paketlerine çok yatırım yapıyor; bu yüzden yapay zekaya testleri en etkili şekilde kullanmayı öğreten birkaç teknik eklerseniz oldukça iyi sonuç alabiliyorsunuz
      Bazı iş arkadaşlarım etkenleri REPL ile etkileşime sokuyor; her seferinde başlangıç maliyeti ödenmediği için daha hızlı olduğunu söylüyorlar. Ben o kadarına üşendim ama şu haliyle bile yeterince hızlı
      Clojure'un ayağa takılan unsurları az. false ve nil dışında her şey doğru kabul edilir, işlem önceliği tablosu yoktur ve çekirdek dil değişmez, kalıcı veri yapılarını varsayılan olarak destekler
      Her şey bir ifadedir; operatörlerle ifadelerin karıştığı bir yapı yoktur. map, reduce, filter yerleşiktir ve normal kodda doğal biçimde kullanılır
      10 yıl önce yazılmış Clojure kodunun bugün de büyük olasılıkla çalışıyor olması beklenir; ekosistem ve dil tasarımcıları geriye dönük uyumluluğu bozmayı neredeyse tabu gibi görür
      Kullandığım diller içinde fikirleri ifade etmekte en özgür hissettiren ve en az baş ağrısı yaşatan dil oldu. Fiili bir tersine debugger sayılabilecek Flowstorm da programlamada adeta bir rüya aracı
      Memnun yaşamak istiyorsanız gerçekten çok iyi bir dil. Öte yandan kullanıcıların çoğu bunu doğal karşıladığı için pek gürültü koparmıyor
      Clojure'u ticari olarak kullanan programcılar arasında dili çok iyi anlamadığı için pek mutlu olmayan da çok kişi var. Çoğu bunu kendisi seçmedi ya da buna henüz hazır değildi; bence Clojure'a geçmeden önce başka dillerde sevmediğiniz şeyleri yaklaşık 10 yıl yaşamış olmanız gerekiyor
      Clojure'un yaratıcısı Rich Hickey'nin yazılım üzerine videoları meşhur ve etkili, ama bu iş arkadaşlarınızın onları izlemiş ya da önemsemiş olduğu anlamına gelmiyor
    • Son ilgi artışında Clojure belgeselinin yayımlanmasının payı büyük gibi görünüyor: https://clojure.org/about/documentary
    • Etken kodlamayla iyi giden bir diğer özellik de REPL odaklı geliştirme. Teorik olarak bunu destekleyebilen başka dillerde bu yaklaşımın neden daha yaygınlaşmadığını bilmiyorum
    • Birçok dilde etken kodlama denedim; tipli diller bununla çok daha iyi uyuşuyor. Çünkü etkenin halüsinasyonla ürettiği hataları tip sistemi fiilen düzeltiyor, özellikle de büyük refaktörlerde
      Büyük ölçekli, tipsiz Python kod tabanlarıyla AI kullanmak zordu. Testlerle kapsanmayan yerlerin bozulup bozulmadığını doğrulamak aşırı sıkıcıydı
      Tip sistemi ne kadar güçlü olursa o kadar iyi. Ayrıca AI modelleri kod üzerinde eğitildiği için dil ne kadar popülerse performansın da o kadar iyi olma ihtimali yüksek. ClojureScript iyi ama ana akım bir dil değil; bu yüzden AI performansının JavaScript'ten düşük olacağını düşünüyorum
      Sonuçta AI'ı hesaba katıyorsanız tipli bir dil seçmek ya da dinamik bir dil kullanacaksanız en azından tip ipuçları olan birini tercih etmek daha mantıklı
    • Belgeselin çıktığını ya da duyurulduğunu hatırlıyorum; etkisi o olabilir

  • Bu gerçekten büyük bir gelişme. Jank duyurulduğundan beri Clojure ekosisteminde bu kadar heyecan yaratan bir şey olmamıştı

  • Ön yüzde JavaScript alternatiflerinin belirsiz bir nişin ötesine geçip gerçekten tutunmuş olmasını isterdim
    ClojureScript gibi bir şeyi denemek istiyorum ama kişisel yan projeler dışında nerede kullanabileceğimi hayal etmek zor. Eğer arka uç zaten Clojure olan bir organizasyondaysanız benimsemek daha kolay olabilir

    • Endişeniz bunun ana akım olmaması ve ekip arkadaşlarınızın bilmemesi mi, yoksa dilin terk edilmesi ya da kötü çıkması mı, merak ettim
      Üretimde kullanmadım ama birkaç yan projeyi ve aile için yaptığım bazı şeyleri dağıttım. ClojureScript'in React sarmalayıcısı olan Reagent, dürüst olmak gerekirse bana React'in kendisinden daha anlamlı geldi
      Hiccup ile HTML oluşturuyorsunuz ve bileşenler Hiccup DSL'i içindeki fonksiyonlardan ibaret; bu DSL de aslında bir liste olduğu için ortaya çok temiz bir sonuç çıkıyor. Statik olan statik görünüyor, dinamik olan da açıkça dinamik görünüyor; normal React'e göre çok daha az sihir hissi veriyor
      Kötü hissettiren kısım NPM'den bulunan fonksiyonel olmayan bileşenleri kullanmaya çalışırken ortaya çıkıyordu. Ölümcül değil ama kodu çirkinleştiriyor. Sarmalayıcılarla düzeltilebiliyor ama bazı JS kütüphaneleri cljs tarafında varsayılan olarak gerçekten dağınık duruyor
    • Korkacak bir şey yok, gerçekten çok iyi. 10 yıldır karmaşık uygulamaları yüksek derecede optimize edilmiş istemci koduna derlemek için kullanıyorum; buna belirsiz bir niş demezdim
      Topluluk da çok sıcak ve olgun
    • Sadece hayal etmeyin, küçük başlayın. Ekipte kullanılan bash betikleri varsa onları Babashka ile yeniden yazabilirsiniz
      Önce kişisel betiklerinizi dönüştürüp el alışkanlığı kazanmak ve avantajlarını hissetmek iyi olur. Her durumda daha iyi değil ama sonra insanlar size danışmaya gelebilir, bu yüzden önce kendinizin ikna olması önemli
      Tanıdık olmayan bir teknolojiyi içeri sokarken daha az önemli bir şeyi seçip onu yeniden yazmak ve beklemek iyi bir stratejidir. Sorun olursa geri almak kolaydır; insanlar beğenmeye başlarsa yavaş yavaş genişletirsiniz
      Eskiden bir .NET organizasyonuna F#'ı gizlice sokarken de daha az kritik testleri F# ile yazarak başlamıştım
    • Gleam denemenizi öneririm. Üretimde kullanıyorum ve çok memnunum
      https://blisswriter.app/
      https://blog.nestful.app/p/how-we-dropped-vue-for-gleam-and
    • https://hypermedia.systems/ adresini okuduktan sonra en iyi ön yüzün hiç ön yüz olmaması olduğu sonucuna vardım

  • cljs'i uzun süredir takip etmiyorum ama başlangıçta bunun “JavaScript üzerindeki Clojure” gibi tanıtıldığını hatırlıyorum. En azından Rich başlarda böyle anlatıyordu diye anımsıyorum
    Amacın bunu olabildiğince bir başka çalışma zamanı gibi tutmak olduğunu düşünmüştüm
    Ama bu değişiklik cljs'e özgü bir özellik ekliyor gibi görünüyor ve await zaten clojure.core içinde bir anahtar sözcük olduğu için Clojure'un kendisiyle de çakışıyor
    İki uygulama zamanla ayrıştı mı, yoksa bu özellik kullanıcılar için o farkı kabullenecek kadar önemli miydi, merak ediyorum

  • Ek bir kütüphane eklemeden JavaScript birlikte çalışabilirliğini ele alabilmek açısından önemli
    Uzun süredir eksik olan bir özellikti; bu yüzden bu sürüm oldukça sevindirici

  • async/await işlevlerini CSP ile sarmak daha iyi bir yaklaşım gibi geliyor. Clojure'da zaten daha iyi örüntüler vardı

    • Bu sürüm, ana dilin yerleşik özelliğini ClojureScript'e açmakla ilgili
      core.async ortadan kalkmıyor; async/await, Promise tabanlı uygulamaya daha iyi uyuyorsa core.async'in .cljs tarafı da güncellenebilir
    • Bunu hâlâ yapabilirsiniz. ClojureScript dünyasında bu zaten yıllardır mümkündü; sonuçta bunların hepsi Promise
      Bu yeni işlev ipucunun gelmesiyle o yaklaşımın ortadan kalkacağını sanmıyorum
      https://clojurescript.org/guides/promise-interop#using-promi...

  • Buna nasıl yaklaşmam gerektiğinden emin değilim. core.async'in temel fikirlerinden biri zaten bunların hepsini kanallara taşımak değil miydi diye düşünüyorum
    JavaScript tarzı async anahtar sözcüğüne sahip olmanın bir yükseltme olduğundan emin değilim

    • Bunun amacı, core.async gibi ek bağımlılıklar getirmeden JS özelliklerini kullanabilmek
      Kullanmak zorunda değilsiniz; core.async'i kullanmaya devam edebilirsiniz. Ayrıca yakın tarihli ClojureScript anketinde en çok talep edilen özellik buydu da