The mystique of erlang


Published on

Published in: Technology, News & Politics
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Created by Dr. Joe Armstrong after finding that Prolog didn’t do exactly what he wanted. First came a log meta-interpreter that added parallel processes to Prolog, and then error handling mechanisms were added, and then a new language was born.
  • The buzz for Erlang is growing steadily because it provides what many other languages can’t: scalable concurrency and reliability
  • Erlang is a product of years of research from Ericsson (one of Sweden’s largest companies) to develop real-time fault-tolerant distributed applications for telecom applications – systems which could not often be taken down for maintenance.

    Erlang is a functional language with many reliability features built-in. You can’t take a phone switch down for maintenance, so you don’t have to take Erlang down to replace entire modules. Some of its applications have run for years without ever coming down for maintenance (or crashed). Reliability and concurrency are Erlang’s key capabilities.

    Erlang is threadless. Threads take fewer resources, so theoretically, you should be able to get better performance from them. However, threads allow shared resources, which lead to unnecessary complexity. Locks, bottlenecks, bugs…

    Instead Erlang takes a different approach, and rather than wade through the quagmire of shared resources and resource bottlenecks, Erlang embraces the philosophy of lightweight processes. Erlang has aimed to simplify the creation, management and communication within applications with many processes. Erlang aims to remove side effects and mutability using the functional programming paradigm.

    Erlang processes are managed entirely by the runtime, not the OS.

    Distributed message passing is a basic language-level construct in Erlang, which eliminates the need for locking and improves concurrency.

    Erlang makes it easy to monitor the death of a process. Killing related processes and starting new ones is a trivial exercise.

    Erlang allows code hot-swapping. You can replace pieces of your applications without stopping your code. This allows for simpler maintenance strategies. Erlang combines the robust “Let it crash” error strategies with hot-swapping and lightweight processes that can be started with minimal overhead. No wonder some Erlang applications can run for years without downtime.
  • When you remove mutable state from the equation, concurrency gets dramatically simpler. Erlang programs are built from the inside out for concurrency.
  • Traditionally, functions and methods have side effects, which make it impossible for us to prove the correctness or predict their outcomes. Threads have shared state rather than shared-nothing processes for performance, which means we have to do more work to protect code.
  • Erlang is built for reliability. The core libraries have been tested, and applications written with Erlang are among the most reliable systems in the world.
  • The mystique of erlang

    1. 1. © 2010 Shivercube “Do you hear that, Mr. Anderson?That is the sound of inevitability.” - Agent Smith
    2. 2. © 2010 Shivercube “HelloWorld”. or -module(hello). -export([start/0]). start() -> io:format(“HelloWorld~n”).
    3. 3. © 2010 Shivercube  Makes hard things easy  But also makes easy things hard  Virtual machine called BEAM  Brutally efficient, and brutally ugly  Based on Prolog
    4. 4. © 2010 Shivercube  Cloud-based databases  CouchDB  SimpleDB  Facebook Chat  GitHub egitd  Yaws  Wings 3D
    5. 5. © 2010 Shivercube  Functional programming language  Dynamic typing  Built for concurrency  Extremely reliable  No threading  Lightweight processes  “Let it crash” mantra  Hot-swappable code
    6. 6. © 2010 Shivercube  Programs built entirely out of functions  No objects anywhere  Functions are first-class citizens  Functions usually return the same values, given the same inputs  Functions usually do not have side effects  They usually not modify program state  Variables can only be assigned to once
    7. 7. © 2010 Shivercube -module(hellov2). -export([start/0]). start() -> spawn(fun() -> loop() end). loop() -> receive hello -> io:format(“Hello World~n”), loop(); goodbye -> ok end.
    8. 8. © 2010 Shivercube  Reality hurts  Concurrency is hard  We’ve been using the wrong programming model ▪ Functions and methods with side effects ▪ Threads with shared state
    9. 9. © 2010 Shivercube  Share-nothing processes  Side effect free  Concurrency primitives  Sending messages (!)  Spawning messages (spawn)  Receiving messages (receive)
    10. 10. © 2010 Shivercube  Makes hard things easy and easy things hard  Prolog-style syntax alien to most  Functional programming paradigm  Extremely efficient  Extremely reliable  “Let it crash” philosophy simplifies code  Dynamic typing results in better productivity  Simple concurrency  Hot swapping code
    11. 11. © 2010 Shivercube  Erlang Programming  Erlang (programming language) ming_language)  The *Real* Erlang "Hello,World!“ erlang-hello-world.html  Erlang for C, C++ and Java Programmers