Why Erlang is Ideal for Building Scalable and Reliable Systems
•Descargar como PPTX, PDF•
3 recomendaciones•712 vistas
The document discusses the benefits of using the Erlang programming language. It highlights Erlang's abilities in horizontal and vertical scalability, hot swapping of code, asynchronous processing, supervision, live debugging, predictability, and requiring 4-10x less code that is faster to create, easier to reason about, and has fewer bugs. It compares Erlang favorably to other languages in terms of scalability, speed, and reliability due to its built-in concurrency, error handling, fault detection and recovery capabilities.
Recomendados
Más contenido relacionado
Similar a Why Erlang is Ideal for Building Scalable and Reliable Systems
Similar a Why Erlang is Ideal for Building Scalable and Reliable Systems (20)
Más de Mahesh Paolini-Subramanya
Más de Mahesh Paolini-Subramanya (6)
Why Erlang is Ideal for Building Scalable and Reliable Systems
- 1. Erlang FTW! { Mahesh Paolini-Subramanya (@dieswaytoofast) V.P. Ubiquiti Networks James Aimonetti (@jamesaimonetti)
- 3. Why Erlang?
- 4. Horizontal Scalability
- 5. Horizontal Scalability
- 6. Horizontal Vertical Scalability
- 7. Horizontal Vertical Scalability
- 8. Live! Hot Swapping
- 9. Live! Hot Swapping
- 13. Supervision
- 14. Live Debugging
- 15. Stack Traces
- 16. Predictability
- 17. Why Erlang?
- 18. 4x – 10x less code
- 19. Faster to create 4x – 10x less code
- 20. Faster to create Easier to reason about 4x – 10x less code
- 21. Faster to create Easier to reason about Fewer bugs 4x – 10x less code
- 22. Faster to create Easier to reason about Fewer bugs Speedy refactoring 4x – 10x less code
- 23. vs Scalability
- 24. Speed
- 25. Reliability
- 26. Concurrency by default Error encapsulation Fault detection Fault identification Code upgrade Stable Storage From http://www.erlang.org/download/armstrong_thesis_2003.pdf Concurrency Oriented
- 27. My Blue Heaven My Blue Heaven Concurrency Hell Concurrency Oriented
- 28. My Blue Heaven My Blue Heaven Deep Problem s Concurrency Hell Deep Problem s Concurrency Oriented
- 29. Cheap Actors
- 30. Shared vs shared-nothing OO vs Actors
- 31. Shared vs shared-nothing Inheritance vs Behavior OO vs Actors
- 32. Shared vs shared-nothing Inheritance vs Behavior Sync vs Async OO vs Actors
- 33. Why Not Java? (Ruby/…)
- 36. Trivial thread management (hint: none) Erlang Architecture
- 37. Trivial thread management (hint: none) Trivial monitoring / load-balancing Erlang Architecture
- 38. Trivial thread management (hint: none) Trivial monitoring / load-balancing One process per session Erlang Architecture
- 39. X = 1. Immutable Variables
- 40. X = 1. X = 2. Huh? Immutable Variables
- 41. X = 1. X = 2. X = X + 1. Huh? Immutable Variables
- 42. [ do_something_with(X) || X <- ListOfItems ] List Comprehensions
- 43. function greet( Gender, Name ) if Gender == male then print( "Hello, Mr. %s!", Name ) else if Gender == female then print( "Hello, Mrs. %s!", Name ) else print( "Hello, %s!", Name ) end vs greet( male, Name ) -> print_out( “Hello Mr. ”, Name ); greet( female, Name ) -> print_out( “Greetings Mrs. ”, Name ); greet( _, Name ) -> print_out( “Wotcher ”, Name ). Functions From http://learnyousomeerlang.com/
- 44. Module:code_change( OldVersion, OldState, Stuff ) -> NewState = whatever_you_need_to_do( OldVersion, OldState, Stuff ), { ok, NewState }. vs Monkey Patching? Really? You sure? Functions
- 45. << Header:16, Checksum:4, Payload/binary >>. Bit Syntax
- 46. [ process_payload(Payload) || <<_Header:16, _Checksum:4, Payload/binary>> <= BunchOfData ]. Binary Comprehensions!
- 47. … proc:spawn( fun( X ) -> do_stuff( X ) end ), … do_stuff( OnePerson ) -> change_the_world( OnePerson ). Processes
- 48. if ( X instanceof Integer ) { try { change_position( X ); } catch ( ArithmeticException a ) { // can't happen. ignore } catch ( PositionException p ) { // why would this happen? } catch ( Exception e ) { // The other code has this here } catch ( Throwable t ) { // Dunno why this was in the other code vs } } proc:spawn( fun( X ) -> change_position( X ) end ), Defensive Programming
- 49. mahesh#dieswaytoofast.com / @dieswaytoofast james#2600hz.com / @jamesaimonetti Questions
Notas del editor
- Erlang is everywhere. You don’t realize it, but you’re using it. It just works
- Its how the world works. ‘Synchronous’ and ‘semaphore’ and ‘mutex’ are all (artificial) programming constructs
- Its how the world works. ‘Synchronous’ and ‘semaphore’ and ‘mutex’ are all (artificial) programming constructs
- Its how the world works. ‘Synchronous’ and ‘semaphore’ and ‘mutex’ are all (artificial) programming constructs
- Corresponds to how we think, and helps deal with edge-cases much *much* better!
- Why wait? Just log on to a node
- Testing is infinitely easier. Trivial to simulate (its all messages!)
- Soft real-time. Brief discussion of instrumentation and ‘reductions’
- Yeah, yeah. And my fish has a bicycle
- Productivity
- Because you don’t know how you are going to end up scaling!
- Really?Yeah, really. Except for FFTs No defensive code, distribution, efficiency
- Part and parcel of The Erlang WayYou can almost claim that This is how we build Reliable systems!
- The language is designed from the ground up for concurrency.Why does this even matter? Hold your horses, we’ll get to that in just a moment
- ‘Distributed’ problems mean you spend a huge chunk of your time dealing with theadminstrivia of distribution.With erlang you get that for free!
- Ok, not really true. You still have to deal with ‘deep problems’ (hard core parallelization issues, etc.)But you’d have to deal with that anyhow!
- “Actors” Think “OO” + “Processes”. Its just that these processes are really cheap
- Whyerlang? Why not <insert language here>
- Yup. You can (and people do!) use assembler
- Don’t shoot yourself in the foot before you get started…
- Yeah, yeah. Understandable lies. But the bottlenecks are pretty far down the road (and much further than you would have gotten before!)
- Yeah, yeah. Understandable lies. But the bottlenecks are pretty far down the road (and much further than you would have gotten before!)
- One process per session + immutable variables = happiness
- Garbage Collection, Referential Integrity, Testing!!!
- Syntactic sugar, but so easy to understand
- Simple, encapsulated, and discreet casses.
- And even for JVMs hot-swap is limited to the body of methods
- Erlang has very useful abstractions that help deal with binary data
- Trivially easy to process
- Ridiculously light-weight processes. Trivial to create, Automatically GCd.
- “Let it Crash!”
- Yeah, yeah. Understandable lies. But the bottlenecks are pretty far down the road (and much further than you would have gotten before!)