Why Erlang? GDC Online 2012

15,526 views
15,349 views

Published on

Why am I hearing more and more about Erlang these days? What are EA, Blizzard, Zynga and Wooga using this functional programming language for? Is it for me, too? Faster implementation, way better maintenance, 4 times shorter code: these slides present the case for Erlang as server language, where it shines, how it looks, what caveats there are and how to get started fast. The lecture details the differences between a Java / C# / C++ and an Erlang game server architecture, and between Erlang's Actor Model and OO. Tutorial style, a minimal Erlang program is explained to show Erlang's main features in action: microprocesses, actors, atoms, immutable variables, message passing and pattern matching. Anyone passionate about programming will be surfing the web for more before the presentation is over. The theory and advantages of each of the concepts are touched upon, a list of good matches is given, tips for pitching for Erlang in-house and links to get started immediately.

Published in: Technology
0 Comments
25 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,526
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
408
Comments
0
Likes
25
Embeds 0
No embeds

No notes for slide

Why Erlang? GDC Online 2012

  1. 1. Why … Erlang?Henning DiedrichCEO Eonblastcorrected and minimally enhanced post talk version 2.3.3
  2. 2. Your Host : Henning Diedrich • Founder, CEO Eonblast • CTO Freshworks • CTO, Producer at Newtracks • Team Lead, Producer at Bigpoint • OS Maintainer Emysql, Erlvolt|2
  3. 3. Acknowledgements : Thank You! Joe Armstrong Robert Virding Erlang Solutions Ulf Wiger Feuerland Labs Felix Geisendörfer Transloadit Richard OKeefe University of Otago … for vetting and improving these slides in various stages. All errors and omissions are, of course, mine.|3
  4. 4. Why Erlang? : 1. Why Care About It? 2. Who Uses It? 3. What for? 4. Is It for Me? 5. How It Looks 6. Getting Started!|4
  5. 5. Erlang may be to Java what Java was: to C++|5
  6. 6. Erlang may be to Java what Java was: to C++ C++ – pointers = Java Java – deadlocks = Erlang|6
  7. 7. Erlang may be to Java what Java was: to C++ „Drop Slides 5 and 6“ Joe Armstrong|7
  8. 8. Erlang may be to Java what Java was: to C++ Erlang is a lot more ...|8
  9. 9. : Who Uses It?|9
  10. 10. You are Using It : „You probably use systems based on Erlang/OTP every day without knowing it.“ Mike Williams| 10
  11. 11. Erlang Game Servers : Zynga: FarmVille via membase, Activision Blizzard: Call of Duty, Bigpoint: Battle Star Galactica, Wooga: Magic Land| 11
  12. 12. Distributed DBs using Erlang : Membase, riak, BigCouch Handling state: secure, fast and distributed.| 12
  13. 13. EA contributed Emysql : http://eonblast.github.com/Emysql| 13
  14. 14. The Erlang Poster Child : Klarna AB • Financial Services for E-Commerce • 600 Employees, $38M revenue • 12,000 e-commerce stores • 30 seconds downtime in 3 years • Investment by Sequoia Capital| 14
  15. 15. Sequoia Capital : 1975 Atari 2000 Rackspace 1978 Apple 2003 LinkedIn 1982 Electronic Arts 2005 YouTube 1987 Cisco 2007 Dropbox 1993 Nvidia 1995 Yahoo! 2009 Unity 3D 1999 Google 2010 Klarna 1999 Paypal 2012 Instagram| 15
  16. 16. : Why Use It?| 16
  17. 17. Why Erlang? : Business Perspective • Reduce Costs • Improve Retention • Shorten Time To Market| 17
  18. 18. Why Erlang? : Production Perspective • High Productivity • Low Hardware Requirements • More Robust Servers| 18
  19. 19. Why Erlang? : Design Perspective • More Complex Designs • Profitable On Smaller Markets • Less Mainstreaming Pressure| 19
  20. 20. : When Use It?| 20
  21. 21. Sweet Spots : • Stateful Servers with High Throughput • Cluster Distribution Layers • Chats*| 21 * Chats are a bitch. The Facebook Chat was written in Erlang.
  22. 22. : Why Is It Good At These Things?| 22
  23. 23. Origins : PLEX • Ericsson makes billions with telecom switches • They used PLEX, an all proprietary software • PLEX delivers, but has bad productivity| 23
  24. 24. Origins : • The 80s: Ericsson Computer Science Lab Joe Armstrong, Robert Virding, Mike Williams „What aspects of computer languages make it easier to program telecom systems?“| 24
  25. 25. Origins : Mission ● Keep features, but invent a more productive PLEX. Approach ● Programmed a small telephone exchange (MD110) in Prolog, CHILL, Ada, Concurrent Euclid, Rules Based Systems, AI Systems, Functional Langs Conclusion ● Many good abstractions ● None could match the characteristics of PLEX| 25 The True story about why we invented Erlang and A few things you don’t want to tell your Manager Mike Williams www.erlang-factory.com/upload/presentations/416/MikeWilliams.pdf
  26. 26. Origins : PLEX ● Safe pointers ● Ability to change size of arrays etc without memory leaks ● Fine grained massive concurrency ● Ability to develop software in independent “blocks” ● Ability to change code at runtime without stopping ● Advanced tracing ability at runtime ● Restart Mechanisms to recover software & hardware failure| 26 The True story about why we invented Erlang and A few things you don’t want to tell your Manager Mike Williams www.erlang-factory.com/upload/presentations/416/MikeWilliams.pdf
  27. 27. Erlang was Built For : • Reliability • Maintenance • Distribution • Productivity| 27
  28. 28. Features Achieved : ● Productive ● Reliable ● Fast ● Scalable ● Great to Maintain … how?| 28
  29. 29. The Magic : • Microprocesses • Pattern Matching * • Immutable Variables * Not your familiar Regex string matching| 29
  30. 30. : What Is That?| 30
  31. 31. Thinking Erlang : • The Actor Model • Thinking Parallel • Thinking Functional • Thinking Processes • Let It Crash!| 31
  32. 32. : Actor Model vs. OO| 32
  33. 33. The Actor Model : Carl Hewitt 1973 • Behavior • State • Parallel • Asynchronous Messages • Mailboxes • No Shared State| 33
  34. 34. Object Oriented : Data Code Object ● Data + Code ● Encapsulation ● Inheritance ● Polymorphy ● Late Binding| 34
  35. 35. Actor Model : Actor Data Data Code Code Object Process ● Data + Code + Process ● Self-Contained Machines ● Stronger Encapsulation ● Less Inheritance ● Type Inference| 35 ● Hot Code Upgrades
  36. 36. Actor Model : Actor Actor Actor DataData Code Code Data Data Code Code Data Data Code Code Object Process Object Process Object Process ● Data + Code + Process ● Self-Contained Machines ● Stronger Encapsulation ● Less Inheritance ● Type Inference | 36 ● Hot Code Upgrades
  37. 37. OO Inheritance : Base BaseData Code Base Data Code Base Data Code Data Code Data Code Object ● Inheritance of Class ● Multi-Level, Multi-Branch ● Overloading| 37
  38. 38. Erlang Behavior : Behavior Actor Code Data Code Process ● Inheritance of Behavior only. ● Usually only one level deep. ● Usually one of the standard OTP behaviors: Generic Server, Event, State Machine, Supervisor.| 38
  39. 39. OO Methods: Synchronous Calls : o.method(a) ● OO “method calls” are simply synchronous function calls. ● Not really the OO “messages” once promised. ● OO fails itself where building on Algol.| 39
  40. 40. Actors: Asynchronous Messages : Pid ! Msg ● Message dispatch is one-way, truly asynchronous. ● Not function calls but something in their own right. ● Clean break from the FP paradigm.| 40
  41. 41. Actor Model: Benefits : • More true to the real world • Better suited for parallel hardware • Better suited for distributed architectures • Scaling garbage collection (sic!) • Less Magic| 41
  42. 42. : Thinking Processes| 42
  43. 43. Thinking Processes : • What should be a Process? „Easy!“| 43 Joe Armstrong
  44. 44. Thinking Processes : • Three Elevators • Ten Floors • How many processes?| 44
  45. 45. Thinking Processes : Thirteen! „Its so obvious!“ - Joe Armstrong The Algorithm courtesy Joe: 1. each floor has its own stop list • elevators hold state 2. when you press the "up" button on floor K you broadcast to all lifts "I want to go up, how long will it • floors hold state take to get to me?“ 3. each lift computes this independentally and • All live separate lives 4. sends the result to floor K. 5. Floor K waits for 3 messages then 6. Chooses the minimum • All dont share state 7. then sends a message to this list "add me to your stop list." • Elevators and floors interact independently| 45
  46. 46. Thinking Processes : Processes • Don’t share State • Communicate Asynchronously • Are Very Cheap to create and keep • Monitor Each Other • Provide Contention Handling • Constitute the Error Handling Atom| 46
  47. 47. Objects share Threads : ● Multiple objects share threads. ● Objects can be accessed across threads. ● Threads - and objects - share state.| 47
  48. 48. Actors are Processes : ● State, code and process form a unity: the actor. ● Like processes, actors do not share state. ● In fact, like humans. Who mostly work quite well.| 48
  49. 49. Objects and Threads : Lifetime & Destruction| 49
  50. 50. Objects and Threads : C C++ C# Java JavaScript Node Lua Python| 50
  51. 51. Objects and Threads : Idle Threads| 51
  52. 52. Objects and Threads : Controller Thread Pooling for Recycling| 52
  53. 53. Objects and Threads : Leeroy Jenkins!!! Unwanted surviving objects| 53
  54. 54. Objects and Threads : 2*B || !2*B ? Prematurely destroyed objects| 54
  55. 55. Erlang Processes : Erlang Actors: State + Code + Process| 55
  56. 56. Erlang Processes : One dies.| 56
  57. 57. Erlang Processes : The Erlang way: the process is restarted.| 57
  58. 58. Processes are Cheap : → No Process Pooling in Erlang| 58
  59. 59. Processes are Cheap : spawn(fun). Have millions of them.| 59
  60. 60. : Locks and Deadlocks| 60
  61. 61. Objects share : State ● State can be contested. ● Locks invite deadlocks. ● Truly parallel architectures increase fringe case race conditions.| 61
  62. 62. Actors message Copies : ● Messages can only communicate via copies of state. ● Eliminates most race conditions. ● (But references and locks do exist for global lists.)| 62
  63. 63. Objects reference State : ● Multiple objects share threads. ● Objects can be accessed across threads. ● Threads - and objects - share state.| 63
  64. 64. Objects need Locks : Worker 1 Doing X1 Resource Locked Locked Worker 2 Waiting Doing X2 ● System design is disrupted by explicit locks. ● Overly cautious locking slows things down. ● Forgotten locks create errors that show under load.| 64
  65. 65. Crashed Locks : Stall Worker 1 Doing X1 Resource Locked Locked Worker 2 Waiting Doing X2 ● Locks can need cross-thread error handling. ● Stalling and time outs aggravate load.| 65
  66. 66. Processes are Transactional : Do X1 for me! Funnel Doing X1 Doing X2 Do X2 for me! Obviously: ● One actor is one process and so, cannot “race itself”. ● Mandating a job kind to an actor creates a transactional funnel.| 66 ● Only one such job will ever be executing at any one time.
  67. 67. Couldnt I just : ... … be disciplined? And program like this in Java? :-) Almost, yes, plus some extensions. :-) Like, you can avoid null pointers in C by discipline. :-) And Conways Game of Life is Turing Complete. :-( So realistically, not at all. :-( Erlang encourages the right way. :-( Erlang performs better at what it is made for. :-( Erlang/OTP is made for servers. → you will be faster learning and using Erlang.| 67
  68. 68. : Server Architecture| 68
  69. 69. OO Server Architecture : Client Client Client Client Client Client Client Client Client Client Client Request / Response Controller Thread Pool Objects Database| 69
  70. 70. Fitting Recycled Threads : Worker → Execute Controller → Fitting Dispatch ● One thread fitting per single request. ● Pooling owed to heavy footprint of system threads. ● Cracks traumatically under pressure.| 70
  71. 71. Fitting Recycled Threads : Activated Session Pool → Worker → Execute Sessions → Controller → Fitting Dispatch ● One thread fitting per single request. ● Pooling owed to heavy footprint of system threads. ● Cracks traumatically under pressure.| 71
  72. 72. OO Server Architecture : Client Client Client Client Client Client Client Client Client Client Client Request / Response Controller Controller Multi-Thread Execution Database| 72
  73. 73. Erlang Server Architecture : Client Client Client Client Client Client Client Client Client Client Client Request / Response Shared-Nothing Processes Database| 73
  74. 74. Erlang: One Process per Session : ● Natural congruence of requirements and system. ● Thread management way simpler. ● Enabled by light-weight processes.| 74
  75. 75. Sessions & Processes : Sessions and Processes correlate. • VM schedules & spreads across Cores • Asynchronous Messages + Mailboxes • Shared-Nothing: Messages are Copies • Individual Memory Management & GC • Strong Built-In Monitoring Features| 75
  76. 76. Sessions & Processes : One Player Session per Process + Immutable State = Transactional Behavior Hello CloudDB!| 76
  77. 77. Sessions & Processes : 1 Session per Process + VM is Process-Aware = VM is Session-Aware → Process Stats = session stats → Per Process GC = per session sweep| 77 Courtesy Wooga: http://www.slideshare.net/wooga/erlang-the-big-switch-in-social-games
  78. 78. OO vs Erlang Architecture : Controller Router Controller| 78
  79. 79. Thinking Parallel : „Its not easy.“ Robert Virding| 79
  80. 80. Thinking Parallel : • The Generals’ Problem • Lamport Clocks • No Guarantees| 80
  81. 81. Generals’ Problem : State Two generals must agree on a time to attack.| 81
  82. 82. Generals’ Problem : State One sends a messenger.| 82
  83. 83. Generals’ Problem : State The other acknowledges.| 83
  84. 84. Generals’ Problem : State ACK the ACK. Etc.| 84
  85. 85. Generals’ Problem : State The messenger may get lost.| 85
  86. 86. Byzantine Generals : State The generals, actually, too.| 86
  87. 87. Lamport Clocks : Order matters more than time.| 87 Source: Lamport http://research.microsoft.com/users/lamport/pubs/time-clocks.pdf
  88. 88. Thinking Parallel : • Erlang makes it easy • Some things have no clean solution • Some things have complicated solutions| 88
  89. 89. : Thinking Functional| 89
  90. 90. Thinking Functional : Small Functions + Immutable Variables → Don’t assign variables: return results! Complete State in Plain Sight → Awful for updates in place. → Awsome for debugging & maintenance.| 90
  91. 91. Side Effects : Erlang is not side-effect free at all. • Messages between Processes • Terminal Output • Logging • Global Registry • Database Access| 91
  92. 92. : Let It Crash!| 92
  93. 93. Let It Crash! : • No Defense Code • On Error, restart Entire Process • Built-In Process Supervision & Restart • Missing Branches, Matches cause Crash → Shorter, Cleaner Code → Faster Implementation → More Robust: handles All Errors| 93
  94. 94. : What Does That look Like?| 94
  95. 95. Hello, World! : io:format(“Hello, World!”).| 95
  96. 96. The Optics : • Alien 60ies-looking Prolog heir • Variables start with capitals • Very short functions • No type declarations • Statements end with commas, semicolons, dots, arrows, nothing • Pattern matched function heads • A Church of Short Variable Names exists| 96
  97. 97. Declarative : Fibonacci looks like a Math explanation of it. fib(0) -> 0; fib(1) -> 1; fib(N) when N>1 -> fib(N-1) + fib(N-2).| 97
  98. 98. Pattern Matching : Function heads matching 0, 1 or anything. fib(0) -> 0; fib(1) -> 1; fib(N) when N>1 -> fib(N-1) + fib(N-2).| 98
  99. 99. The Syntax : • Small • Easy • Stable • Declarative • Started out as Prolog • Inspired by Prolog and ML • Obvious State, Implicit Thread| 99
  100. 100. Compiling & Executing : $ erlc hello.erl $ erl -s hello| 100
  101. 101. Hello, World! Full Module : -module(hello). -export([start/0]). start() -> io:format("Hello, World!~n").| 101
  102. 102. Creating a Process : Pid = spawn(mod, func, [A, B, C]).| 102
  103. 103. Creating a Process : Pid = spawn(mod, func, [A, B, C]). New Process ID Code Module Start Function Parameters to the function.| 103
  104. 104. Sending a Message : Pid ! Msg.| 104
  105. 105. Sending a Message : Pid ! Msg. Process ID Message| 105
  106. 106. Receive a Message : receive Msg -> Msg end.| 106
  107. 107. Receive a Message : receive Msg -> Msg end. Assign Name Return Value of this block| 107
  108. 108. Hello, World! The Erlang Way : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 108 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  109. 109. Start : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 109 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  110. 110. Output : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 110 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  111. 111. Process Spawning : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> New Process receive hello -> io:format("Hello, World!~n"), loop() end.| 111 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  112. 112. Blocking Receive : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 112 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  113. 113. Message Passing : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 113 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  114. 114. Pattern Matching : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 114 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  115. 115. Atoms : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 115 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  116. 116. Tail Recursion : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 116 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  117. 117. Dots : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 117 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  118. 118. Commas : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 118 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  119. 119. End : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 119 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  120. 120. Arrows : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 120 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  121. 121. Arrows : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 121 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  122. 122. Nothing : -module(hello). -export([start/0, loop/0]). start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> receive hello -> io:format("Hello, World!~n"), loop() end.| 122 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  123. 123. Modules mix Processes : -module(hello). -export([start/0, loop/0]). Calling Processes start() -> Pid = spawn(hello, loop, []), Pid ! hello. loop() -> Modules Own Process receive hello -> io:format("Hello, World!~n"), loop() end.| 123 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  124. 124. Modules mix Processes : -module(hello). -export([start/0, say/1, loop/0]). Calling Processes start() -> spawn(hello, loop, []). say(Pid) -> Pid ! hello. loop() -> Modules Own Process receive hello -> io:format("Hello, World!~n"), loop() end.| 124 From Edward Garsons Blog at http://egarson.blogspot.de/2008/03/real-erlang-hello-world.html
  125. 125. : Immutable Variables| 125
  126. 126. Immutable Variables : Can’t assign a second time: A = A + 1. A = 1, A = 2.| 126
  127. 127. Immutable Variables : It has to be: B = A + 1. A = 1, B = 2.| 127
  128. 128. Immutable Variables : • Prevent Coding Errors • Provide Transactional Semantic • Allow for Pattern Matching Syntax • Can be a Nuisance S1 = dosomething(S), S2 = dosomemore(S1) ...| 128
  129. 129. : Pattern Matching| 129
  130. 130. Pattern Matching : This can mean two things: A = func(). The meaning depends on whether A is already assigned.| 130
  131. 131. Pattern Matching : The common, mixed case: {ok, A} = func(). ok is an assertion AND A is being assigned.| 131
  132. 132. Pattern Matching : The common, mixed case: {ok, A} = func(). „This makes it hard to remodel Erlang syntax into a more C-like syntax.“ Robert Virding| 132
  133. 133. : Erlang Compared| 133
  134. 134. Erlang vs. Stackless Python : • Truly parallel VM Stackless inherits the global interpreter lock (GIL) from Python thus in reality works sequential, only its paradigm is parallel • Pattern Matching • Immutable Variables| 134
  135. 135. Erlang vs. C : • More productive • More concise • More reliable • Much slower for Number Crunching • Microprocesses • Pattern Matching • Immutable Variables| 135
  136. 136. Erlang vs. C++: • Virtual Machine • Actor Model • Less Magic • Much Safer • Much Slower for Number Crunching • Microprocesses • Pattern Matching • Immutable Variables| 136
  137. 137. Erlang vs. Java: • Made For Microprocesses • Actor Model • Less Boilerplate • No Type Wrangling • Fewer Deadlock Opportunities • Microprocesses • Pattern Matching • Immutable Variables| 137
  138. 138. Erlang vs. Lua : • Made to Scale • Single Paradigm • Less Magic • Much Bigger Footprint • Microprocesses • Pattern Matching • Immutable Variables| 138
  139. 139. Great Matches : ● C ● Redis ● MySQL ● VoltDB ● AWS S3 ● EC2 ● Ubuntu| 139
  140. 140. : Productivity| 140
  141. 141. Productivity & :Maintainability “Erlang systems have 4 – 10 x less code than C / C++ / Java systems“ Ulf Wiger| 141
  142. 142. Productivity & :Maintainability Shorter programs: ● Faster to develop ● Fewer errors ● Easier to maintain Erlang LOCs show the same error frequency as C / C++ / Java code.| 142
  143. 143. Scientific Proof: The Motorola Study of 2002 – 2006 • Motorala UK Labs • Heriot-Watt University • EPSRC UK Govt Project| 143 http://www.slideshare.net/JanHenryNystrom/productivity-gains-in-erlang
  144. 144. Scientific Proof: “High Level Techniques for Distributed Telecoms Software“ Looking at • Robustness • Configurability • Productivity • Maintainability| 144
  145. 145. Scientific Proof: “Erlang shows … • 2x higher throughput • 3x better latency • 3 - 7x shorter code … than the equivalent C++ implementation.”| 145
  146. 146. Scientific Proof: Reasons ● Lightweight process management ● Code only the successful case – saves 27% ● Automatic memory management – saves 11% ● High-level communications – saves 23% ● Telecom design pattern libraries (suit games)| 146
  147. 147. Scientific Proof: Overload & Hardware Failure • C++ “fails catastrophically“ • Erlang – Never completely fails – Recovers automatically after load drops| 147
  148. 148. : Challenges| 148
  149. 149. The Warts : • Untidy Standard Libs • Egregious String Handling • „Records Suck“ • Cryptic Error Messages • Lack of Advanced Tutorials & Books • No-One Seems To Know All of OTP • Hard To Find Developers| 149
  150. 150. Strings : • Are* Lists. Or Binaries. • Slow* • Clumsy* • Error prone* • Cure announced for next release (R16) Erlang was not built for text processing . *according to Joe Armstrong these are myths. „Erlang has no strings. The only sane way to handle UTF-8 is lists of integers.“| 150
  151. 151. Records : • “Records Suck“ • Verbose • Error Prone • Pure syntactic sugar over tuples • Cure announced for next release (R16) “Records were added as a hack.“| 151
  152. 152. Raw Number Crunching Speed : • Erlang is fast • Except at Shoot Outs • Benchmark your real problem • Use C NIFs to outsource crunching Perceived reaction after asking about benchmarks on the Erlang mailing list.| 152
  153. 153. Hiring : • Can Be Difficult • Roll Your Own Programmers – Good Programmers Are Interested – High Productivity Can Be Reached Fast – Excellent Workshops can be booked| 153
  154. 154. : Getting Started!| 154
  155. 155. Learning Erlang : • Scour Post-Mortems • Download and Install from erlang.org • Fred’s site Learn You Some Erlang! • Joe’s book Programming Erlang • IRC #erlounge • Erlang Mailing List • Local Erlounge Meetings • Erlang Factories & User Conferences| 155
  156. 156. Expected Timeframe : Ballparks • Language – 2 Weeks • OTP – 3 Months • First Product – ½ Year • Thinking Erlang – 2 Years| 156
  157. 157. Business View : Makes Sense For • New Projects • Rewrites Starting Out • Find a Senior Erlang Developer • Or Hire Erlang Solutions • You Will Train Your Own Developers| 157
  158. 158. Pitching It In-House : A Waste of Time Joe Armstrong Just tell your boss that Erlang is used for banking applications. Mike Williams • Most Often a Top-Down Thing • Demonstrate the Productivity: prototype a demo solution to a real problem.| 158• Cite Facebook, Zynga, Blizzard, Wooga
  159. 159. References : Web http://www.erlang.org/ http://learnyousomeerlang.com/ http://www.erlang.org/static/getting_started_quickly.html List http://erlang.org/mailman/listinfo/erlang-questions http://groups.google.com/group/erlang-programming Books http://pragprog.com/book/jaerlang/programming-erlang http://shop.oreilly.com/product/9780596518189.do References http://erldocs.com/ http://www.erlang.org/doc/ Post Mortems http://www.facebook.com/note.php?note_id=14218138919| 159 http://www.slideshare.net/wooga/erlang-the-big-switch-in-social-games
  160. 160. Your Talk Evaluation : Please check your Email now and give your evaluation of this talk to the GDC. Any questions, feedback now or later, please email me at hd*eonblast.com| 160
  161. 161. Questions : • Email: hdiedrich*eonblast.com • Twitter: @hdiedrich • IRC: #erlounge • List: erlang-questions@erlang.org| 161

×