http://stackoverflow.com/questions/1831520/relation-between-language-and-scalability?lq=1
Erlang comes from another culture in thinking about reliability and how to achieve it. Understanding the culture is important, since Erlang code does not become fault-tolerant by magic just because its Erlang.
A fundamental idea is that high uptime does not only come from a very long mean-time-between-failures, it also comes from a very short mean-time-to-recovery, if a failure happened.
One then realize that one need automatic restarts when a failure is detected. And one realize that at the first detection of something not being quite right then one should "crash" to cause a restart. The recovery needs to be optimized, and the possible information losses need to be minimal.
This strategy is followed by many successful softwares, such as journaling filesystems or transaction-logging databases. But overwhelmingly, software tends to only consider the mean-time-between-failure and send messages to the system log about error-indications then try to keep on running until it is not possible anymore. Typically requiring human monitoring the system and manually reboot.
Most of these strategies are in the form of libraries in Erlang. The part that is a language feature is that processes can "link" and "monitor" each other. The first one is a bi-directional contract that "if you crash, then I get your crash message, which if not trapped will crash me", and the second is a "if you crash, i get a message about it".
Linking and monitoring are the mechanisms that the libraries use to make sure that other processes have not crashed (yet). Processes are organized into "supervision" trees. If a worker process in the tree fails, the supervisor will attempt to restart it, or all workers at the same level of that branch in the tree. If that fails it will escalate up, etc. If the top level supervisor gives up the application crashes and the virtual machine quits, at which point the system operator should make the computer restart.
The complete isolation between process heaps is another reason Erlang fares well. With few exceptions, it is not possible to "share values" between processes. This means that all processes are very self-contained and are often not affected by another process crashing. This property also holds between nodes in an Erlang cluster, so it is low-risk to handle a node failing out of the cluster. Replicate and send out change events rather than have a single point of failure.
The philosophies adopted by Erlang has many names, "fail fast", "crash-only system", "recovery oriented programming", "expose errors", "micro-restarts", "replication", ...
http://stackoverflow.com/questions/8051087/language-best-for-a-photo-sharing-site-php-python-ruby-or-something-else?rq=1
Any. The language doesn't matter. Ruby-fanatics (especially the RubyOnRails sort) will try and tell you that their language will do everything in only 10 lines and it'll make you dinner and pick the kids up from school. Others will tell you that their language is the most secure, fastest, quickest to develop in, etc. Ignore them.
I love Python and I'd love to recommend it - but seriously, it won't make a difference. Just pick the language you know the best and get writing. So if that's Java, start writing Java. If that's C++, hell, start writing C++.
I don't believe the people who say that [insert language here] is fastest to develop in. It's all about what you find comfortable. Some langauges provide extra functionality but you can always write a library that provides that if you need it - it shouldn't take too long and, chances are, someone has already done it.
Remember: Facebook is written in PHP (though they compile a lot of that PHP to C++ now for speed), MySpace was written in C#/Cold Fusion (I believe), Twitter uses Ruby On Rails (though they plan to abandon it apparently), Google uses Java/Go (I think) and LinkedIn uses ASP.net or something I think. My point is - tonnes of services, tonnes of languages and they're all doing ok. Right now, any language will do.
My favourite little phrase is "just build it". Whilst it's a good idea to have a nice architecture and think about performance and scalability - if those things will make you abandon the project half way through, what's the point in bothering? Besides, chances are you'll need to recode a large part of it anyway later on, assuming the project grows. Really think that Facebook are using the same code they were at the start?
So, in summary, pick whichever language you want. It'll be fine.
http://stackoverflow.com/questions/1779191/how-to-push-erlang-to-my-workplace?lq=1
There are a few approaches, and neither have any guarantees to actually work
- Implement something substantial in a short time frame, perhaps using your own time. Don't tell anyone until you have something to display that works. Unless you have a colleague in on it.
- Pull up lots of Erlang projects that are good demonstrations of the features you want. Present it to your managers and try to frame them about the risk in keeping using Java with this kind of technology available.
If the company you work for actually have a working code base in Java already, they're not likely to take you seriously when you suggest to rewrite it in another language.
The true test that you believe in Erlang being a much better choice: Quit and start up a competing company and bring the technology insight you have in your current industry. Your managers are really comparing a similar risk-scenario as you would do if you were to quit your job, and they are looking for the same assuring facts for success as you would do, to consider leaving a "safe" paycheck.
As for how to integrate, check out the jinterface application in Erlang. It allows Java code to send messages to Erlang nodes, and it allows Java to expose mailboxes to the Erlang nodes as if there were Erlang processes.
http://www.erlang.org/download/erlang-book-part1.pdf
No comments:
Post a Comment