Node.js에 대한 Haskell의 응답은 무엇입니까?

Node.js에 대한 Haskell의 응답은 무엇입니까?

Erlang 커뮤니티는 Node.js를 부러워하지 않습니다. Node.js는 기본적으로 비블로킹 I/O를 수행하고 배포를 두 개 이상의 프로세서(Node.js에 내장되어 있지도 않은 프로세서)로 쉽게 확장할 수 있기 때문입니다.자세한 내용은 http://journal.dedasys.com/2010/04/29/erlang-vs-node-js 및 Node.js 또는 Erlang을 참조하십시오.

해스켈은?Haskell은 Node.js의 이점 중 일부, 즉 멀티스레드 프로그래밍에 의존하지 않고 I/O 차단을 피할 수 있는 깨끗한 솔루션을 제공할 수 있습니까?

---

Node.js에는 많은 매력이 있습니다.

1. 이벤트: 스레드 조작 없음, 프로그래머는 콜백만 제공합니다(Snap 프레임워크에서처럼).
2. 콜백은 단일 스레드에서 실행되도록 보장됩니다. 레이스 조건은 불가능합니다.
3. 멋지고 간단한 UNIX 친화적인 API.보너스: 우수한 HTTP 지원. DNS도 사용할 수 있습니다.
4. 모든 I/O는 기본적으로 비동기식입니다.이렇게 하면 잠금을 더 쉽게 피할 수 있습니다.그러나 콜백에서 CPU를 너무 많이 처리하면 다른 연결에 영향을 미칠 수 있습니다(이 경우 작업을 더 작은 하위 작업으로 나누고 다시 예약해야 합니다).
5. 클라이언트 측과 서버 측에서 동일한 언어를 사용합니다. (그러나 이 언어에서는 큰 가치가 보이지 않습니다. jQuery와 Node.js는 이벤트 프로그래밍 모델을 공유하지만 나머지는 매우 다릅니다.서버 측과 클라이언트 측 간의 코드 공유가 실제로 어떻게 유용한지 알 수 없습니다.)
6. 이 모든 것이 하나의 제품으로 포장되었습니다.

네, @gawi가 고기를 가리킨 node.js 프레젠테이션을 조금 본 결과, Haskell이 node.js와 어떻게 비교하는지에 대해 조금 더 말할 수 있습니다.프레젠테이션에서 Ryan은 Green Threads의 몇 가지 이점에 대해 설명하지만 스레드 추상화의 부족이 단점이라고는 생각하지 않는다고 말합니다.저는 특히 해스켈의 맥락에서 그의 입장에 동의하지 않을 것입니다.저는 스레드가 제공하는 추상화가 서버 코드를 더 쉽게 올바르게 만들고 더 강력하게 만드는 데 필수적이라고 생각합니다.특히:

• 연결당 하나의 스레드를 사용하면 모든 클라이언트를 동시에 처리하는 코드를 작성하는 대신 단일 클라이언트와의 통신을 표현하는 코드를 작성할 수 있습니다.이렇게 생각해 보십시오. 스레드로 여러 클라이언트를 처리하는 서버는 단일 클라이언트를 처리하는 서버와 거의 동일하게 보입니다. 주요 차이점은fork 중인할 경우을 동시에 것이 까다롭지만 수 있습니다.구현 중인 프로토콜이 복잡할 경우 여러 클라이언트의 상태 시스템을 동시에 관리하는 것이 매우 까다롭지만 스레드를 사용하면 단일 클라이언트와의 통신을 스크립팅할 수 있습니다.코드를 올바르게 적용하고 이해하고 유지 관리하기가 더 쉽습니다.

• 단일 OS 스레드의 콜백은 스레드로 얻을 수 있는 선제적 멀티태스킹과 반대되는 협력적 멀티태스킹입니다.협동 멀티태스킹의 주요 단점은 프로그래머가 기아가 발생하지 않도록 해야 한다는 것입니다.모듈성을 잃습니다. 한 곳에서 실수를 하면 전체 시스템을 망칠 수 있습니다.이것은 정말로 여러분이 걱정하고 싶지 않은 것이고, 선입견은 간단한 해결책입니다.게다가, 콜백 간의 통신은 불가능합니다(그것은 교착 상태가 될 것입니다).

• 대부분의 코드가 순수하고 구성에 의해 스레드 안전하기 때문에 동시성은 Haskell에서 어렵지 않습니다.단순한 의사소통의 기본 요소들이 있습니다.하스켈어로 동시에 자신의 발을 쏘는 것은 제한되지 않은 부작용이 있는 언어보다 훨씬 어렵습니다.

Haskell은 Node.js의 이점 중 일부, 즉 멀티스레드 프로그래밍에 의존하지 않고 I/O 차단을 피할 수 있는 깨끗한 솔루션을 제공할 수 있습니까?

네, 사실 이벤트와 스레드는 Haskell에서 통합됩니다.

• 명시적인 경량 스레드(예: 단일 노트북의 수백만 개 스레드)로 프로그래밍할 수 있습니다.
• 또는 확장 가능한 이벤트 알림을 기반으로 비동기 이벤트 기반 스타일로 프로그래밍할 수 있습니다.

스레드는 실제로 이벤트 측면에서 구현되며 여러 코어에서 실행되며, 원활한 스레드 마이그레이션, 문서화된 성능 및 애플리케이션을 통해 실행됩니다.

예를 들어

• 대규모 동시 작업 조정
• 32개 또는 48개 코어에서 동시 수집 확장
• 다중 이벤트/다중 이벤트 프로그램의 프로파일링 및 디버깅을 위한 도구 지원.
• 고성능 이벤트 중심 웹 서버입니다.
• 흥미로운 사용자: 고주파 거래와 같은.

32개 코어에서 동시 수집 nbody

하스켈에는 사건과 스레드가 모두 있으며, 모든 사건이 후드 아래에 있기 때문입니다.

구현에 대해 설명하는 문서를 읽습니다.

먼저, 저는 node.js가 모든 콜백을 노출시키는 것이 옳다고 생각하지 않습니다.당신은 당신의 프로그램을 CPS(계속 전달 스타일)로 작성하게 되고, 저는 그 변환을 하는 것이 컴파일러의 일이라고 생각합니다.

이벤트: 스레드 조작 없음, 프로그래머는 콜백만 제공합니다(Snap 프레임워크에서처럼).

따라서 이러한 점을 염두에 두고, 원한다면 비동기식을 사용하여 작성할 수 있지만, 그렇게 하면 요청당 하나의 스레드가 있는 효율적인 동기식으로 작성하는 것을 놓치게 됩니다.하스켈은 특히 다른 언어와 비교할 때 동기식 코드에서 터무니없이 효율적입니다.모든 것이 밑에 있는 사건들입니다.

콜백은 단일 스레드에서 실행되도록 보장됩니다. 레이스 조건은 불가능합니다.

여전히 node.js에서 레이스 상태를 유지할 수 있지만, 더 어렵습니다.

모든 요청은 자체 스레드에 있습니다.다른 스레드와 통신해야 하는 코드를 작성할 때, 해스켈의 동시성 프리미티브 덕분에 스레드 세이프로 만드는 것이 매우 간단합니다.

멋지고 간단한 UNIX 친화적인 API.보너스: 우수한 HTTP 지원. DNS도 사용할 수 있습니다.

해킹을 보고 직접 확인하세요.

모든 I/O는 기본적으로 비동기식입니다(그러나 때때로 성가실 수도 있습니다).이렇게 하면 잠금을 더 쉽게 피할 수 있습니다.그러나 콜백에서 CPU를 너무 많이 처리하면 다른 연결에 영향을 미칠 수 있습니다(이 경우 작업을 더 작은 하위 작업으로 나누고 다시 예약해야 합니다).

당신은 그런 문제가 없습니다, ghc는 당신의 작업을 실제 운영체제 스레드들 사이에 분배할 것입니다.

클라이언트 측과 서버 측에서 동일한 언어를 사용합니다. (하지만 이 경우에는 큰 가치가 없습니다.)JQuery와 Node.js는 이벤트 프로그래밍 모델을 공유하지만 나머지는 매우 다릅니다.서버 측과 클라이언트 측 간의 코드 공유가 실제로 어떻게 유용한지 알 수 없습니다.)

하스켈은 여기서 이길 수 없어요그렇죠? 다시 생각해보세요, http://www.haskell.org/haskellwiki/Haskell_in_web_browser .

이 모든 것이 하나의 제품으로 포장되었습니다.

ghc 다운로드, 케이블 발사.모든 필요에 맞는 패키지가 있습니다.

저는 개인적으로 Node.js와 콜백을 사용한 프로그래밍을 불필요하게 낮은 수준이고 약간 부자연스러운 것으로 봅니다.GHC에서 발견된 것과 같은 좋은 런타임이 당신을 위해 콜백을 처리하고 꽤 효율적으로 수행할 수 있는데 왜 콜백이 있는 프로그램입니까?

그 동안 GHC 런타임은 크게 개선되었습니다. 이제 "M"이 멀티코어를 나타내는 MIO라는 "새로운 IO 관리자"를 특징으로 합니다.기존 IO 관리자를 기반으로 구축되며 4개 이상의 코어 성능 저하 원인을 극복하는 것이 주요 목표입니다.이 문서에 제공된 성능 수치는 매우 인상적입니다.직접 보기:

Mio를 사용하면 Haskell의 현실적인 HTTP 서버가 CPU 코어 20개로 확장되어 이전 버전의 GHC를 사용하는 동일한 서버에 비해 최대 6.5배의 최대 성능을 달성할 수 있습니다.Haskell 서버의 대기 시간도 향상되었습니다. [...] 적당한 부하에서 이전 버전의 GHC에 비해 예상 응답 시간이 5.7배 단축됩니다.

그리고:

또한 Mio를 사용하면 McNettle(Haskell로 작성된 SDN 컨트롤러)이 40개 이상의 코어로 효과적으로 확장되고, 단일 시스템에서 초당 2천만 개 이상의 새로운 요청을 처리할 수 있으므로 기존의 모든 SDN 컨트롤러 중에서 가장 빠릅니다.

Mio는 GHC 7.8.1 릴리스로 출시되었습니다.저는 개인적으로 이것이 Haskell 성능의 주요 발전이라고 생각합니다.이전 GHC 버전과 7.8.1로 컴파일된 기존 웹 애플리케이션 성능을 비교하면 매우 흥미로울 것입니다.

IMHO 이벤트는 좋지만 콜백을 이용한 프로그래밍은 그렇지 않습니다.

웹 응용 프로그램의 코딩 및 디버깅을 특별하게 만드는 대부분의 문제는 확장 가능하고 유연하게 만드는 것에서 비롯됩니다.가장 중요한 것은 HTTP의 상태 비저장 특성입니다.이렇게 하면 탐색 기능이 향상되지만 IO 요소(이 경우 웹 서버)가 응용 프로그램 코드의 다른 핸들러를 호출하는 제어 기능이 역전됩니다.콜백은 가변 범위를 공유하지 않으며 탐색에 대한 직관적인 뷰가 손실되기 때문에 이 이벤트 모델 또는 더 정확히 말하면 콜백 모델은 악몽입니다.사용자가 다른 문제 중에서도 앞뒤로 탐색할 때 발생할 수 있는 모든 상태 변화를 방지하는 것은 매우 어렵습니다.

문제는 이벤트 모델이 정상적으로 작동하는 GUI 프로그래밍과 유사하다고 할 수 있지만 GUI에는 내비게이션과 뒤로 버튼이 없습니다.그것은 웹 애플리케이션에서 가능한 상태 전환을 증가시킵니다.이러한 문제를 해결하려는 시도의 결과는 콜백 모델과 가변 범위 공유의 본질적인 부족, 시퀀스가 없으므로 식별자를 연결하여 시퀀스를 구성해야 한다는 문제의 근본에 의문을 제기하지 않고 만연한 마법 식별자가 많은 복잡한 구성을 가진 무거운 프레임워크입니다.

Ocsigen(occaml) side(smalltalk) WASH(단종, Haskell) 및 mflow(Haskell)와 같은 순차 기반 프레임워크는 탐색성과 REST-fulness를 유지하면서 상태 관리 문제를 해결합니다.이러한 프레임워크 내에서 프로그래머는 프로그램이 페이지를 보내고 단일 스레드에서 응답을 기다리는 명령 시퀀스로 내비게이션을 표현할 수 있으며 변수가 범위 내에 있고 뒤로 버튼이 자동으로 작동합니다.이는 본질적으로 프로그래머가 내비게이션을 명확히 볼 수 있는 더 짧고 안전하며 더 읽기 쉬운 코드를 생성합니다. (공정한 경고:저는 mflow의 개발자입니다.)

1) 해스켈은 이미 훨씬 더 나은 방법으로 이 문제를 해결했고 2) 얼랑과 거의 같은 방식으로 문제를 해결했기 때문에 그 질문은 꽤 우스꽝스럽습니다.노드에 대한 벤치마크는 다음과 같습니다. http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks

Haskell에게 4개의 코어를 제공하면 단일 애플리케이션에서 초당 100k(단순)의 요청을 수행할 수 있습니다.노드는 코어 전체에 걸쳐 단일 애플리케이션을 확장할 수 없습니다.하스켈 런타임은 비블로킹(non-blocking)이기 때문에 여러분은 이것을 얻기 위해 아무것도 할 필요가 없습니다.런타임에 비블로킹 IO가 내장된 유일한 다른 (상대적으로 일반적인) 언어는 Erlang입니다.

nodejs가 livev를 삭제한 것처럼 Snap Haskell Web Framework도 livev를 삭제했습니다.

언급URL : https://stackoverflow.com/questions/3847108/what-is-the-haskell-response-to-node-js