I think, Functional languages will rule the future programming world.
You know, processors have stopped getting faster, shocked! Actually that’s why we need multiprocessor computer. So our software needs to become concurrent as well.
Compilers can’t automatically parallelize imperative/object oriented code. So programming style has to change. Algorithmically simple concurrency can be achieved using libraries and extensions to existing language. You can use the concurrent package in java.
But building complex, fine-grained concurrent system like Facebook, twitter is not possible. So here we need a functional language. So Erlang or Scala is a solution. You probably don’t know, Facebook use Erlang to handle concurrency. Erlang is a highly fault-tolerant language. Not only Erlang, Facebook use C++, Huskell, Thrift in backend also. You can go with Huskell even; it can go even further with software transactional memory and nested data parallelism.
Learning a functional programming language should be your obvious choice as I think future programming world is parallel programming world. Go for any functional language eg- Erlang, Scala, maybe Clojure. Why you should learn functional programming language, it may be your obvious question. But the answer is simple, to write a maintainable, scalable, concurrent and fault-tolerant code for a big parallel system, it’s not possible with object oriented programming language and that will cost a lot. Think about Facebook, Google+, if you add any new features today, you can surely assume that immediately millions of user will use it by tomorrow. So its a really big challenge to make an application scalable.
Let me quote an example from a Facebook developer note, its about Facebook chat system :
The most resource-intensive operation performed in a chat system is not sending messages. It is rather keeping each online user aware of the online-idle-offline states of their friends, so that conversations can begin. Each Facebook Chat user now needs to be notified whenever one of his/her friends
(a) takes an action such as sending a chat message or loads a Facebook page (if tracking idleness via a last-active timestamp) or (b) transitions between idleness states (if representing idleness as a state machine with states like “idle-for-1-minute”, “idle-for-2-minutes”, “idle-for-5-minutes”, “idle-for-10-minutes”, etc.). Note that approach (a) changes the sending a chat message / loading a Facebook page from a one-to-one communication into a multicast to all online friends, while approach (b) ensures that users who are neither chatting nor browsing Facebook are nonetheless generating server load. Another challenge is ensuring the timely delivery of the messages themselves. Fault tolerance is a desirable characteristic of any big system: if an error happens, the system should try its best to recover without human intervention before giving up and informing the user. The results of inevitable programming bugs, hardware failures, et al., should be hidden from the user as much as possible and isolated from the rest of the system.
The way this is typically accomplished in a web application is by separating the model and the view: data is persisted in a database with each short-lived request retrieving only the parts relevant to that request. This architecture works pretty well in general; it isn’t as successful in a chat application due to the high volume of long-lived requests, the non-relational nature of the data involved, and the statefulness of each request.
For Facebook Chat, we rolled our own subsystem for logging chat messages (in C++) as well as an epoll-driven web server (in Erlang) that holds online users’ conversations in-memory and serves the long-polled HTTP requests. Both subsystems are clustered and partitioned for reliability and efficient failover. Why Erlang? In short, because the problem domain fits Erlang like a glove. Erlang is a functional concurrency-oriented language with extremely low-weight user-space “processes”, share-nothing message-passing semantics, built-in distribution, and a “crash and recover” philosophy proven by two decades of deployment on large soft-realtime production systems.
You can read the full story from here:
By the way, these programming language’s syntax are very much weird though, but no big deal.
My Friend Collin Rusk wrote another note after this one, it is here
My friend Bazlur recently wrote a note that asserts, “Functional language will rule the future programming world.” His assertion has merit, but it misses a key point: programming languages have tradeoffs. Each language has its own advantages that are well suited for a particular domain.
Bazlur’s affinity for functional programming languages is well founded. Erlang in particular has been able to achieve dazzling amounts of concurrency. In fact, Erlang actually runs better on multi-core machines than it does on single-core; its performance in clouded environment is better still. Other production-ready functional languages like Scala have properties, so Bazlur’s admiration for functional languages is very well grounded.
Given the need for massive amounts of concurrency in today’s applications, languages that are less amenable to high concurrency would seem to go by the wayside. Why would anyone use C, C++, C#, or Java anymore? Functional languages that are designed to be massively parallel have a weakness. While a given environment can support more threads with such languages, each thread takes longer to accomplish a given task. C# and Java are faster at executing a given piece of code; C and C++ are faster than any of those languages. As a result, the benefits that functional languages provide have tradeoffs.
Balancing the tradeoffs between languages is a discussion for another time. Where the tradeoffs become a detriment is highly dependent upon the project and the utilization of the language in question, but that question is beyond the scope of this note as well. Programming languages have tradeoffs and that must be taken into consideration when building an application. Functional languages clearly provide benefits that other types of languages do not, but they are hardly a magic bullet and must be used prudently like every other technology.