Hacker News new | past | comments | ask | show | jobs | submit login

A week with the Erlang language, which will enable to write projects that would be on par or better than anything written in node.js as far as resilient and scalability.

Probably another week to get up to speed with OTP for all the promises of resilient Erlang applications.

What is often missed about Erlang is that it's not really about highly concurrent applications. That property is actually a means to accomplish its primary goal: fault-tolerant applications.

See: http://www.erlang.org/download/armstrong_thesis_2003.pdf to understand the motives of the Erlang designers.




Firstly, I apologise for down-voting this response.

A week to learn Erlang. Where do I start?


http://learnyousomeerlang.com/

You can pick up the basic syntax in one full day easily (if you are an experienced developer and already understand functional programming) ... 3 or 4 days if you are new to functional coding or just very inexperienced.

It is a very brief / minimalist language from a syntax point of view. Then, it will take a week or two to get your head around OTP, which is the primary framework and has years (decades?) of mission critical work under its belt.

Then, at the end of your journey will be the really hard problems... dealing with massive netsplits at a cluster level, elections for new masters, and all the other hard problems that happen at the upper-tier of massive clusters.

If you are building an HTTP(S) app -- you can blessedly avoid a lot of these by avoiding a true massive cluster all together and using lots of individual "micro clusters"(note) balanced / routed by HTTP middle-ware.

Also, check out Cowboy [webserver] (https://github.com/extend/cowboy/), Agner [package manager] (http://erlagner.org/) and of course, the always awesome rebar [build tool] (https://github.com/basho/rebar/)

.. and I love lager [log tool, make those erlang logs less alien looking] (http://basho.com/blog/technical/2011/07/20/Introducing-Lager...)

(note) This is basically a strategy of using small clusters based on locations -- so if you are across lets say 3 locations, you would build 3 node clusters, 1 node per location and have them work as a unit localizing workloads and responding to requests, and then you allow your higher level middle-ware to deal with your many groups of "micro clusters". High reliability rather cheaply, but means you need your own system for pushing out updates.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: