Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Introduction to Erlang
Transcript of Introduction to Erlang
10Ghz? In 2002 we hit a peculiar physical limit: it became impossible to reach the entire chip in one clock cycle. The number of transistors on a chip will double about every two years. Intel co-founder Gordon E. Moore (aka "Moore's Law") The hardware folks figured out a solution: Multiple
cores! Sadly, the software
folks fell behind. “... for the first time in history, no one is building a much faster sequential processor. If you want your program to run significantly faster, say, to justify the addition of new features, you’re going to have to parallelize your program.” Hennessy and Patterson
“Computer Architectures” (4th edition)
Programming languages haven't changed for the last 25 years... because hardware hasn't changed for the last 25 years. Machines simply got faster... so there was no pressure to change programming languages. The world is concurrent! Yet we program in sequential languages... which makes programming many problems artificially difficult. The industry's dilemma: The shift to multicore is inevitable Parallelizing legacy C#, Java, C++
code is difficult. Debugging parallelized code is even
harder. … but what choice do we have? Make programs run N times faster on an N-core CPU with no changes to the program. big idea How? Taking the sequential part out of your code is the key to going faster on a parallel computer. it call comes down to mutable state 2 models
of concurrency Shared state concurrency Message passing concurrency Shared state concurrency involves the idea of “mutable state” (literally memory that can be changed).
This is fine as long as you have only one process doing the changing. To protect against the simultaneous
modiﬁcation of shared memory,
we use locking. But locking doesn’t scale! In message passing concurrency, there is no shared state.
All computations are done in processes, and they only exchange data through asynchronous message passing. But locking doesn’t scale! The Erlang view of the world is that everything is a process that lacks shared memory and influences another only by exchanging asynchronous messages. This style of programming is called... Large number of processes.
Complete isolation of processes.
No shared memory.
Pure messaging: no pointers; you copy data you pass.
Avoid sequential bottlenecks.
Location transparency. Concurrency Oriented Programming Fault
tolerance To make a fault-tolerant system, you need at least 2 isolated computers. You are now doing concurrent, distributed programming! To do very fault-tolerant computing, you need lots of computers. We've also made the system
more scalable! Scalability comes from having lots of isolated things -- which also makes it more fault tolerant.
Fault tolerance, distribution, concurrency, scalability are indispensable and intertwined! Sharing is what stands in the way of fault tolerance and scalability! Erlang espouses all the concepts we’ve discusses so far: • No shared memory
• “Pure” message passing
• High concurrency
• Robust fault tolerance
• Hot swappability of code
Erlang wasn’t developed with multi-cores in mind, but it just happens to run on multi-cores very nicely thanks to the above properties. A breif history of Erlang 1984—1986: technology evaluations 1987—1989: use in prototypes 1993—1995: limited use in products 1996: Use for product development; OTP team created 1998: Banned inside Ericsson, Erlang is open sourced What is OTP? Erlang’s
nature Erlang is a functional language.
In functional programming, you avoid state and mutable data. Functions are first-class citizens:
you can assign them as variables, you can pass them around, you can return them from other functions. Side effects are strictly controlled:
if you call the same function twice with the same arguments, it should return the same value. Referential transparency:
state has to be carried in and out. Imperative programming is known for uncontrolled, promiscuous use of side effects. In functional programming, side effects are rarely used. Resources Who's this guy? Erlang the Movie http://infoq.com/erlang A lot of presentations, articles, interviews at A nice tutorial at http://learnyousomeerlang.com Getting started: http://www.erlang.org/starting.html A side note about OOP Just a gentle reminder that I took some pains at the last OOPSLA to try to remind everyone that Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.
The big idea is "messaging" […]
Alan Kay, a pioneer of OOP http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html