erlang in production leads to haskell

Erlang으로 프로젝트를 시작한지 3주.
아주 만족스럽다.
deployment와 management,scale 이슈만 커버하면 거의 다 마스터 될 듯.

Erlang을 입문하는데, 어려움을 겪고 있다면,
webmachine,mochiweb을 써서 간단한 것이라도 만들어 보길 권한다.
금새 익숙해 질 것이다. ^^

최근에 다시 haskell을 보기 시작했는데,
Erlang에 익숙해지니, 전에 어렵게 느껴지던 haskell도 훨씬 쉬워 보인다.

Haskell에 OTP의 기능들이 들어오면 좋을텐데...
Haskell/OTP 프로젝트 없을까? ^^

DB는 mnesia와 riak을 프로젝트에 쓸 것이다.
두개의 성능 테스트의 결과가 흥미진진하다.

Yesod Web Framework in Haskell

http://docs.yesodweb.com/

Rails와 같은 식으로 프로그래밍하는 것이 요즘 대세이다.
그래서 그런지, 프레임웍들도 Rails식으로 따라 하고 있다.

Haskell문법 역시 간결하다!  semi-colon(;) 없는 코드를 보니 마음이 시원할 정도;;;

http://docs.yesodweb.com/screencasts

소개 비디오를 보면 정말 놀랍다.


Yesod Screencast: Yammer from Michael Snoyman on Vimeo.

core팀 3명으로 짧은 기간에 해낸 것도 놀랍다.

하루 빨리, Haskell이 hot-code swap이랑, process간 통신, distributed 환경을 위한 feature들이 추가되면 좋겠다.
당장은, Haskell도 단일한 독립 사이트 만들기에는 부족함이 없어보인다.
Ruby on Rails보다 성능은 물론이고, 생산성에서 앞지르는 것은 시간 문제로 보인다.

Erlang은 대규모 서비스용이다보니,
Agile Development에 맞는 framework가 나오지 않는 것이 안타깝다.
(내가 할까? ㅎ)
그것만 맞춰준다면, 인기를 얻었을때, 다시 아키텍쳐를 잡지 않아도 될텐데 말이다.
mochi-web등이 잘 해주길 응원한다.


도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

OpenCL binding for Erlang and Haskell

cuda와 Erlang binding은 아직 나오지 않은 듯 하다.

대신 OpenCL과 Erlang binding은 나와있다.
https://github.com/tonyrog/cl


다음은 OpenCL Haskell binding이다.

http://hackage.haskell.org/package/OpenCLRaw



OpenCL에 대한 tutorial도 몇개 있다.
http://www.multicoreinfo.com/2009/08/parprog-part-9/

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Elliot Game Engine Blog

My Name is Elliot Shin.

I am from South Korea.

I've been working primarilly as a programmer in Game Industry for about 16 years.



Thanks to my boss, I come to have a chance to make use of my full time for myself,at last.



I decided to start to make a new MMO game engine.



I chose Erlang for server-side,and Haskell for client-side.

I will use jMonkeyEngine or somethine else temporarilly.



This challenge will be a long and lonely journey.



I am just learning the two languages.



And, I decided to blog in English to become better at.

I want to make good foriegn friends,too.



I will post my decisions,references I search, and on-going results.

Any help would be greatly appreciated.

Erlang vs Haskell in Server Side Programming

Erlang은 산업에서도 증명되었고, 특히 concurrent oriented programming과 Hotcode swap이 매우 매력적이다.
Haskell이 문법적인 면에서 우수하나(staticcaly typed), 아직 증명해야 할 것들이 많다.

Erlang은  soft real-time application에 적합하다. 즉, 아직 single-core에서 C++만큼의 성능이 나오지 않는다. 따라서, frontend보다는 middle-tier에 적합하다. hard real-time이 요구되는 상황에 적합하지 않다. Haskell도 아직 증명하지 못했다.

Hard Real-time이 요구되는 상황에 대해서 C++프레임워크와 비교해가면서 테스트를 해야되겠다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

Erlang , Haskell hybrid?

http://haskell.org/haskellwiki/Applications_and_libraries/Interfacing_other_languages/Erlang

Erlang Application과 Haskell Application간의 IPC를 위해서 준비하고 있는 모습.

Erlang은 Fault-tolerant, Scability, Stability가 인정되었기 때문에,
Frontend Server로 사용하고,
Haskell은 Logic Solver로 쓰려고 하려는 시도인 듯 하다.

하지만, Erlang을 쓸바에야, 차라리 C++ Frontend를 쓰는 편이 낫다.
왜냐하면, Erlang의 강력한 기능인 Hot code swap을 쓰지 못하고,
Logic Programming의 안정성을 Haskell에서 확보한다는 뜻인데,
결국, Logic Programming의 안정성(특히, 위기상황 대처능력)은 Haskell의 수준에 맞춰지고,
Latency만 올라가는 꼴이 된다. C++이 안정성은 확보 못할지라도, latency를 줄여줄 것이다.

Erlang은 VM의 garbage collection을 per-process단위로 heap을 만들었다.
그것은, 작은 프로세스 단위로, 분산 컴퓨팅이 되길 바라는 의미이다.
그런데, Erlang을 frontend로 쓰는 것은 어불성설인 것 같다.
( http://yarivsblog.blogspot.com/2008/05/erlang-vs-scala.html )

다른 구조로, Erlang의 작은 process들을 여러개 쓰고, 반대로 haskell process가 main controller역할을 한다고 해도, Erlang의 hotspot swap기능을 살릴 수 없다.

기본적으로 hybrid형태는 복잡도를 증가시키기 때문에 바람직한 architecture가 아니라고 생각한다.

하루 빨리 Haskell에 Distributed Computing(Actor Style System), Frontend Server로서의 안정성이 확보되길 바라고, Erlang의 hot code swap/remote shell기능마저 자체적으로 들어가길 바란다.
( http://stackoverflow.com/questions/394645/haskell-for-a-server )
( http://www.haskell.org/pipermail/haskell-cafe/2010-July/080427.html: hot-swap 빨리 구현 되길 ^^
 http://www.flickr.com/photos/48809572@N02/5304662424/lightbox/
http://www.0x61.com/forum/programming-haskell-cafe-f245/hot-swap-with-haskell-t1289472-10.html )


아직까지는 Erlang이 대규모 서비스에는 적합한 듯 하다. 다만, dynamic typing 만 보완되면 좋겠고, syntax도 보완되면 좋겠다;;
( http://jjinux.blogspot.com/2009/02/haskell-or-erlang.html )
( http://stackoverflow.com/questions/532176/erlang-type-system )

현재는, Erlang on server-side, Haskell on client-side가 답이다.
( http://learnyousomeerlang.com/content )
( http://learnyouahaskell.com/chapters )

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

complains about some programming languages

C++은 생산성이 떨어지고,
Haskell은 concurrent programming 이 아직 부족하고,
ErLang은 dynamically-typed라서 생산성이 조금 부족하고,
OCaml은 pure-functional이 아니고, 세미콜론이 거슬린다!;;; 게다가, community가 활성화 안되고 있다.
Scala는 JVM에 종속되어 있고,
Python은 성능이 떨어지고,
Ruby도 성능이...,

Java은 C++과 생산성이 비슷하고,
Lua는 Garbage Collection이 안 좋고,함수형 언어들은 처음에 배우기 어렵고...

그래도 haskell에서 희망을 찾아본다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

haskell for an alternative programming languages

주류(main-stream)가 아닌 프로그래밍 언어를 대안 프로그래밍 언어라고 부른다.

나는 C++프로그래머이다.
최근 3년 동안, 여러 언어들을 알아보았다.
Erlang,OCaml,Scala,Python,Java,Ruby,SmallTalk,Ada,Lua
ErLang은 가장 reliable,fault-tolerant한 것으로 잘 알려져 있다. CouchDB등에서 쓰여지고 있다.
OCaml은 Imperative,OOP에 익숙했던 사람도 쉽게 함수형 언어로 넘어갈 수 있게 되어있다.MS도 OCaml을 차용하여, F#을 만들었다. 즉, MS도 인정한 언어이다.
Scala는 JVM내에서의 OCaml과 같은 식이다. 다양한 패러다임들을 수용하고 있다. 프로그래머에게 많은 편안함을 제공한다. Scala는 이름처럼 Scalability를 위해서 많이 수용되고 있다.
Python은 극한의 생산성을 제공하는 듯 하다. 대규모 서비스의 front-end언어로는 적합하지 않아 보인다. 중급 이하에서는 문제가 되지 않아 보인다. 툴 제작에는 아주 훌륭한 언어라고 생각한다.
Java는 대안언어라기 보다는 주류언어지만, 비판을 많이 받아왔다. 하지만 요즘은 나쁘지 않다. 왜냐하면, Java기반의 좋은 framework들이 많이 나왔다. spring,playframework등... 게다가 성능이 이들 중에서는 가장 최적화가 많이 된 상태이다.
Ruby는 Ruby on Rails를 통해 인기를 얻기 시작하여, 커뮤니티가 매우 크다. 천재적인 패러다임들이 가장 먼저 적용되고 있는 언어이다.
smalltalk,ada도 관심을 두고 알아보았고, 나름 매력이 있다. ADA는 literate programming에 가장 가까운 언어인 듯 하다. 구문이 영어와 많이 닮아 있다.
lua는 큰 규모에는 쓰기 어렵다.

불행히도, 이들 언어에 모두 제대로 입문하진 못했다.
모든 언어를 경험해보고 몸소 그 장단점을 깨달아보고 싶다.
모든 언어로 하나 이상의 프로젝트를 해 볼 계획이다.
하지만 간접적으로나마 깨달은 것 중에 가장 중요한 깨달음은 다음과 같았다.
1. 커뮤니티의 크기 : 커뮤니티가 크다는 것은 도메인 문제들을 잘 해결해주고 있다는 증거이고, 헌신하는 팬들과 투자가 많다는 것이다.
2. 프레임워크가 언어를 압도한다. : 루비의 예에서 보듯이, 언어 자체의 한계성보다는 마찬가지로 도메인 문제를 잘 해결해주기 때문에 인기를 얻을 수 있는 것이다.

앞으로 10년을 개발할 프로젝트에 쓰일 언어의 기준은 뭐가 되어야 할까?
패러랠,멀티코어,CPU/GPU 컨버젼스의 시대이다.
아키텍쳐의 변화를 수용하지 못하면, 결국 성능 결쟁에서 밀려날 것이다.
그러려면, 가장 자연적스러운 병렬 프로그래밍이 가능해야 한다!

아직 어느 언어도 그 기준에 맞지 않다.
그래서 새로운 언어를 만들어 보고 싶다.
그러기전에 '최선'의 선택, 또는 '차선'의 선택이 될 수 있는 언어에 익숙해지는 순서가 필요하다고 생각한다.
그 생각에서 가장 적합안 언어로 꽂힌 언어는 haskell이다.
haskell : 순수 함수형 언어이다. 배우기 어려울 뿐, 함수형 언어에 익숙해지면, 생산성이 매우 높아진다고 한다.(나도 아직 경험해 보지 못했고, 그렇게 되길 바란다. ) 최근 커뮤니티가 급성장하고 있다.

programming language shoot-out 을 보면, 성능 비교가 잘 되어 있다.
http://shootout.alioth.debian.org/
아마도 특정 분야에서는 C/C++을 버리지 못할 것 같다.
haskell에 기대를 걸어본다. 커지고 있는 커뮤니티가 더 최적화된 컴파일러를 만들어주리라 기대해 본다.

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^

using thrift

thrift 는 간단히 말하면, IDL 을 정의해서, 서버/클라이언트간 통신을 손쉽게 해주는 소스 생성기 입니다. RPC 라이브러리라고 생각해도 됩니다.
놀라운 것은 C++이외에도 많은 언어를 지원해줍니다.
C#,ErLang,OCaml,Haskell,Java,C/Cocoa,PHP,Python,Perl,Ruby까지~
기본적인 async operation도 지원합니다.
게다가,Binary Protocol과 JSon Protocol을 모두 지원하네요.

아쉬운 점은 thrift 자체가 robust한 서버를 위한 것은 아니라서,
외부 인터넷 클라이언트가 접속하는 서버용은 아니라는 점이죠.
향후 발전 되길 바라구요.
아직 알아보지 못했지만, protocol header 와 protocol의 내용의 암/복호화를
정의할 수 있어야 할텐데, 가능한지 아직 모르겠네요.

어쨌든, 서버 프로세스간 통신하기에는 안성맞춤입니다.
트위터가 사용한 flockdb에서도 thrift를 사용했습니다.

사용방법도 매우 간단합니다.

http://wiki.apache.org/thrift/ThriftUsageC%2B%2B

MacOSX에서의 설치도 간단한 편입니다.
boost의 설치가 먼저 필요합니다.
http://wiki.apache.org/thrift/ThriftInstallationMacOSX

haskell binding은설치하다가 에러가 납니다.
haskell을 굳이 쓰지 않는다면,
lib/Makefile에서 hs부분을 제거하고 설치하시면 됩니다.

Nonblocking Socket방식의 통신을 원한다면,
libevent를 설치해야 합니다.
http://monkey.org/~provos/libevent/

flockdb를 사용하기 위해서는 thrift 0.2.0을 사용해야 하네요.
조심하시길..

저도 앞으로 서버간 통신에는 thrift를 사용하려고 합니다.
제가 아쉬웠던 점을 commit할 수 있는 영광이 있으면 더 좋겠네요. ^^

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^