Haskell Node.js'ye yanıtı nedir?

Erlang topluluğunun yerel olarak engellemeyen G / Ç'yi yaptığı ve konuşlandırmaları birden fazla işlemciye (Node.js'de yerleşik olmayan bir şey bile) kolayca ölçeklendirme yollarına sahip olduğu için Node.js'yi kıskanmamış olduğuna inanıyorum. Http://journal.dedasys.com/2010/04/29/erlang-vs-node-js ve Node.js veya Erlang adresinde daha fazla ayrıntı

Haskell ne olacak? Haskell, Node.js'nin bazı avantajlarını, yani çok iş parçacıklı programlamaya başvurmadan G / Ç'yi engellemekten kaçınmak için temiz bir çözüm sağlayabilir mi?

Node.js ile çekici olan birçok şey var

1. Olaylar: İş parçacığı manipülasyonu yok, programcı yalnızca geri aramalar sağlar (Snap çerçevesindeki gibi)
2. Geri aramaların tek bir iş parçacığında çalıştırılması garanti edilir: yarış durumu mümkün değildir.
3. Güzel ve basit UNIX dostu API. Bonus: Mükemmel HTTP desteği. DNS de mevcuttur.
4. Her G / Ç varsayılan olarak eşzamansızdır. Bu, kilitleri önlemeyi kolaylaştırır. Ancak, bir geri aramada çok fazla CPU işlemesi diğer bağlantıları etkileyecektir (bu durumda, görev daha küçük alt görevlere bölünmeli ve yeniden programlanmalıdır).
5. İstemci tarafı ve sunucu tarafı için aynı dil. (Ancak, bu bir çok değer görmüyorum. JQuery ve Node.js olay programlama modelini paylaşmak ama gerisi çok farklı. Sadece sunucu tarafı ve istemci tarafı arasında paylaşım kodu nasıl olabilir göremiyorum pratikte yararlı olabilir.)
6. Bütün bunlar tek bir üründe paketlenmiştir.

Tamam, @ gawi'nin bana işaret ettiği node.js sunumundan biraz izledikten sonra, Haskell'in node.js ile karşılaştırması hakkında biraz daha fazla şey söyleyebilirim. Sunumda Ryan, Green Threads'ın bazı faydalarını açıklıyor, ancak daha sonra bir dezavantaj olarak bir iplik soyutlamasının eksikliğini bulamadığını söylemeye devam ediyor. Özellikle Haskell bağlamında bu konuya katılmıyorum: Bence iş parçacıklarının sağladığı soyutlamalar, sunucu kodunun daha kolay ve daha sağlam olmasını kolaylaştırmak için gerekli. Özellikle:

• bağlantı başına bir iş parçacığı kullanmak, tüm istemcilerle aynı anda ilgilenen kod yazmak yerine, tek bir istemciyle iletişimi ifade eden kod yazmanıza olanak tanır . Şöyle düşünün: iş parçacıkları olan birden çok istemciyi işleyen bir sunucu neredeyse tek bir istemciyi işleyen sunucuyla aynı görünüyor; temel fark, forkbirincisinde bir yer olması. Uyguladığınız protokol tamamen karmaşıksa, durum makinesini birden çok istemci için aynı anda yönetmek oldukça zorlaşırken, iş parçacıkları tek bir istemciyle iletişimi komut dosyası haline getirmenize izin verir. Kodun düzeltilmesi daha kolay, anlaşılması ve bakımı daha kolaydır.

• Tek bir OS iş parçacığındaki geri çağrılar, iş parçacığı ile elde ettiğiniz önleyici çoklu görevlerin aksine, ortak çoklu görevdir. İşbirlikçi çoklu görevle ilgili ana dezavantaj, programcının açlık olmadığından emin olmaktan sorumlu olmasıdır. Modülerliği kaybeder: tek bir yerde hata yapın ve tüm sistemi sıkıştırabilir. Bu gerçekten endişelenmek istemediğiniz bir şeydir ve preemption basit bir çözümdür. Dahası, geri aramalar arasında iletişim mümkün değildir (kilitlenecektir).

• eşzamanlılık Haskell'de zor değildir, çünkü çoğu kod saftır ve inşaat tarafından iş parçacığı için güvenlidir. Basit iletişim ilkelleri vardır. Haskell'deki eşzamanlılık ile kendinizi ayağa vurmak, sınırsız yan etkilere sahip bir dilde olduğundan çok daha zor.

Haskell, Node.js'nin bazı avantajlarını, yani çok iş parçacıklı programlamaya başvurmadan G / Ç'yi engellemekten kaçınmak için temiz bir çözüm sağlayabilir mi?

Evet, aslında Haskell'de olaylar ve evreler birleştirildi.

• Açık hafif iş parçacıklarıyla (örneğin, tek bir dizüstü bilgisayarda milyonlarca iş parçacığı) programlayabilirsiniz.
• Veya; ölçeklenebilir olay bildirimini temel alarak zaman uyumsuz bir olayla programlayabilirsiniz.

İş parçacıkları aslında olaylar açısından uygulanır ve sorunsuz iş parçacığı geçişi, belgelenmiş performans ve uygulamalar ile birden fazla çekirdek üzerinde çalışır.

Örneğin

• büyük ölçüde eşzamanlı iş düzenlemesi
• eşzamanlı koleksiyonları 32 veya 48 çekirdeği ölçekleme
• çok iş parçacıklı / çok olaylı programların profilini oluşturma ve hata ayıklama için araç desteği .
• yüksek performanslı olay güdümlü web sunucuları .
• ilginç kullanıcılar: yüksek frekanslı ticaret gibi .

Eşzamanlı koleksiyonlar 32 çekirdekli kimse

Haskell'de hem olaylar hem de iş parçacıkları var ve tüm başlık altında olduğu gibi.

Uygulamayı açıklayan makaleyi okuyun .

Öncelikle, node.js'nin tüm bu geri çağrıları ortaya çıkaran doğru şeyi yaptığını düşünmüyorum. Sonunda programınızı CPS (devam geçiş tarzı) olarak yazıyorsunuz ve bence bu dönüşümü yapmak derleyicinin işi olmalı.

Olaylar: İş parçacığı manipülasyonu yok, programcı yalnızca geri aramalar sağlar (Snap çerçevesindeki gibi)

Bunu göz önünde bulundurarak, isterseniz eşzamansız bir stil kullanarak yazabilirsiniz, ancak bunu yaparak, her bir istek için bir iş parçacığı ile verimli bir eşzamanlı tarzda yazmayı kaçırırsınız. Haskell, özellikle diğer dillerle karşılaştırıldığında senkron kodda gülünç derecede etkilidir. Tüm olayların altında.

Geri aramaların tek bir iş parçacığında çalıştırılması garanti edilir: yarış durumu mümkün değildir.

Hala node.js'de bir yarış durumunuz olabilir, ancak daha zor.

Her istek kendi iş parçacığında. Diğer iş parçacıklarıyla iletişim kurması gereken kod yazdığınızda, haskell'in eşzamanlılık ilkelleri sayesinde iş parçacığı güvenli hale getirmek çok basittir.

Güzel ve basit UNIX dostu API. Bonus: Mükemmel HTTP desteği. DNS de mevcuttur.

Hacking'e bir göz atın ve kendiniz görün.

Her G / Ç varsayılan olarak eşzamansızdır (bu bazen sinir bozucu olabilir). Bu, kilitleri önlemeyi kolaylaştırır. Ancak, bir geri aramada çok fazla CPU işlemesi diğer bağlantıları etkileyecektir (bu durumda, görev daha küçük alt görevlere bölünmeli ve yeniden programlanmalıdır).

Böyle bir sorununuz yok, ghc çalışmanızı gerçek işletim sistemi iş parçacıkları arasında dağıtacaktır.

İstemci tarafı ve sunucu tarafı için aynı dil. (Ancak, bu bir çok değer görmüyorum. JQuery ve Node.js olay programlama modelini paylaşmak ama gerisi çok farklı. Sadece sunucu tarafı ve istemci tarafı arasında paylaşım kodu nasıl olabilir göremiyorum pratikte yararlı olabilir.)

Haskell burada kazanamaz ... değil mi? Tekrar düşünün, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

Bütün bunlar tek bir üründe paketlenmiştir.

İndir ghc, cabal ateş. Her ihtiyaç için bir paket var.

Ben şahsen Node.js'yi ve geri çağrılarla programlamayı gereksiz yere düşük seviyeli ve biraz doğal olmayan bir şey olarak görüyorum. GHC'de bulunan gibi iyi bir çalışma zamanı sizin için geri aramaları işleyebiliyorsa ve bunu oldukça verimli bir şekilde gerçekleştirebiliyorsa neden geri aramalarla programlanmalı?

Bu arada, GHC çalışma zamanı büyük ölçüde iyileşti: şimdi MIO adı verilen "M" nin çok çekirdekli olduğuna inanan "yeni bir yeni IO yöneticisi" bulunuyor . Mevcut IO yöneticisinin temeli üzerine kuruludur ve asıl amacı 4+ çekirdek performans düşüşünün nedeninin üstesinden gelmektir. Bu makalede verilen performans numaraları oldukça etkileyicidir. Kendini gör:

Mio ile Haskell'deki gerçekçi HTTP sunucuları, 20 CPU çekirdeğine kadar ölçeklendirilir ve önceki GHC sürümlerini kullanan aynı sunuculara kıyasla 6,5 ​​kata kadar daha yüksek performans elde eder. Haskell sunucularının gecikme süresi de artırıldı: [...] ılımlı bir yük altında, önceki GHC sürümleriyle karşılaştırıldığında beklenen yanıt süresini 5,7x azaltır

Ve:

Ayrıca Mio ile McNettle'ın (Haskell'de yazılmış bir SDN denetleyicisi) 40'tan fazla çekirdeğe etkili bir şekilde ölçeklenebileceğini, tek bir makinede saniyede 20 milyondan fazla yeni talebe ulaştığını ve dolayısıyla mevcut tüm SDN denetleyicilerinin en hızlısı haline geldiğini gösteriyoruz. .

Mio GHC 7.8.1 sürümüne girdi. Şahsen bunu Haskell performansında atılmış önemli bir adım olarak görüyorum. Önceki GHC sürümü ve 7.8.1 tarafından derlenen mevcut web uygulamaları performansını karşılaştırmak çok ilginç olurdu.

IMHO olayları iyidir, ancak geri aramalar yoluyla programlama iyi değildir.

Web uygulamalarının kodlanmasını ve hata ayıklamasını özel kılan sorunların çoğu, bunları ölçeklenebilir ve esnek yapan şeylerden gelir. En önemlisi, HTTP'nin durumsuz doğası. Bu gezinilebilirliği artırır, ancak bu, G / Ç öğesinin (bu durumda web sunucusu) uygulama kodundaki farklı işleyicileri çağırdığı bir denetimin tersine çevrilmesini sağlar. Bu olay modeli -veya daha doğru bir şekilde söylenen- geri arama modeli bir kabustur, çünkü geri aramalar değişken kapsamları paylaşmadığından ve navigasyonun sezgisel bir görünümü kaybolur. Kullanıcı diğer sorunların yanı sıra ileri geri hareket ettiğinde olası tüm durum değişikliklerini önlemek çok zordur.

Sorunların olay modelinin iyi çalıştığı GUI programlamasına benzediği söylenebilir, ancak GUI'lerde gezinme ve geri düğmesi yoktur. Bu, web uygulamalarındaki olası geçişleri çoğaltır. Bu sorunu çözme girişiminin sonucu, karmaşık yapılandırmalara sahip ağır çerçevelerdir ve sorunun kökünü sorgulamadan birçok yaygın sihirli tanımlayıcı vardır: geri arama modeli ve değişken kapsamların paylaşılmasının doğal eksikliği ve sıralama yok. tanımlayıcılar bağlanarak oluşturulur.

Ocsigen (ocaml) deniz kenarı (smalltalk) WASH (üretilmiyor, Haskell) ve mflow (Haskell) gibi navigasyon ve REST dolgunluğunu korurken durum yönetimi sorununu çözen ardışık tabanlı çerçeveler vardır. bu çerçeveler içinde, programcı navigasyonu, programın sayfaları gönderdiği ve tek bir iş parçacığında yanıt beklediği, değişkenlerin kapsamda olduğu ve geri düğmesinin otomatik olarak çalıştığı zorunlu bir sıra olarak ifade edebilir. Bu, doğal olarak, navigasyonun programcı tarafından açıkça görülebildiği daha kısa, daha güvenli, daha okunabilir bir kod üretir. (adil uyarı: mflow'un geliştiricisiyim)

Soru oldukça saçma çünkü 1) Haskell bu konuyu çok daha iyi bir şekilde çözdü ve 2) kabaca Erlang'ın yaptığı gibi. Düğüme karşı kıyaslama: http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

Haskell'e 4 çekirdek verin ve tek bir uygulamada saniyede 100k (basit) istekte bulunabilir. Düğüm çok fazla iş yapamaz ve tek bir uygulamayı çekirdekler arasında ölçeklendiremez. Haskell çalışma zamanı engellenmediği için bunu elde etmek için hiçbir şey yapmanız gerekmez. Çalışma zamanında yerleşik olmayan ve engelleme olmayan IO'ya sahip diğer tek (nispeten yaygın) dil Erlang'dır.

Tıpkı nodejs libev düşmüştür çekin Haskell Web Çerçeve libev düşmüştür de.