Konrad Gądek @ SFI 2014

1. Jak ugryźć 19 mld,
czyli o programowaniu w
Erlangu
Konrad Gądek

2. Plan
1. Wprowadzenie
2. Stwórzmy Erlanga!
3. Weryfikacja tego, co osiągnęliśmy
4. Słowo końcowe

3. Hipoteza Sapira–Whorfa
• „Używany język wpływa w mniejszym lub większym
stopniu na sposób myślenia”
• Czy odnosi się też do języków programowania?

4. Back to the furniture
• Jest rok 1984, znajdujemy się w Computer
Science Laboratory firmy Ericsson$
• Główne źródło dochodów: AXE — switch
telekomunikacyjny
• Dedykowany procesor (APZ), dedykowany język
programowania (PLEX), dedykowany system
operacyjny, dedykowany software development
environment, dedykowany…

5. Zadanie do wykonania
• Mamy do dyspozycji
MD110
• PLEX niby OK, jednak
dość czasochłonny
• Własny, dedykowany
procesor? Koszty!
• Migracja AXE na wiele
procesorów: porażka
http://www.erlang-factory.com/upload/presentations/416/MikeWilliams.pdf

6. W roku 1984…
• Algorytm W (Hindley–Milner) opublikowany 2 lata
temu. Statyczne typowanie jak w Pascalu?
• C++ powstał niespełna rok temu
• Python powstanie za 7 lat
• Java oraz Javascript powstaną za 11 lat

7. Wyniki eksperymentów
• Testowane >20 języków / technologii
• Pierwsze wyniki: język musi być wysokopoziomowy
• Najlepiej spisały się LISP, Prolog, Parlog, ale…

8. Nowy język!
• Wydajność pracy programistów jest istotna
• Niezawodność jest kluczowa!
• o awariach piszą w gazetach
• Dedykowany dla switchy
• low latency > throughput

9. 1. Jestem programistą i
żaden błąd nie jest mi obcy
• Programowanie jest trudne
• Ego do kieszeni i załóżmy, że nasz kod będzie
zawierać błędy
• Język ma być prosty w pisaniu
• wysokopoziomowy
• Język ma być prosty w czytaniu
• funkcyjny

10. Świat jest współbieżny!
• Najlepiej modelować problem podobnie,
współbieżnie (niezależne zdarzenia)
• PLEX oferuje „zadania”, ale…
• „cooperative scheduling”
• nie gwarantują bezpieczeństwa systemu
• Procesy…?

11. Procesy są współbieżne!
• Lekkie procesy — 327 słów/proces (233 to stos)
• Szeregowanie z wywłaszczaniem
• Za ~20 lat świat stanie się „wielordzeniowy” —
idealnie!

12. Osobne procesy
• Komunikacja (wyłącznie) przez wiadomości
• Kopiowanie — niezależność
(Garbage Collector!)
• Atomowo > gwarantcja dostarczenia wiadomości
• Wnioskowanie o systemie (casual ordering)
„In many primitive religions it was believed that humans had powers over
spirits if they could command them by their real names” — Joe Armstrong
• Co nam to daje w starciu z błędami?

13. Błędy i ich propagacja
• Błędy mogą rozprzestrzeniać się w nieprzewidywany sposób
• Izolacja błędu
• nie jesteśmy w stanie przewidzieć wszystkich
sposobów awarii
• często sprawdzajmy, czy jest OK
{A, B} = {1,2}
{ok, C} = {ok, 123}
{die, james_bond} ≠ query_goldfinger("do you expect me to talk?")
• jak nie to KILL! Tak szybko jak się da. A potem restart

14. Jak to „kill”? A dane?!
• Pamięć tymczasowa a persystencja
• Przepięcia / Chwilowa awaria sprzętu / Promienie
kosmiczne
• …a permanentna awaria sprzętu?

15. Potrzebna jest strategia!
• Niech procesy mogą się dowiadywać o swojej
„śmierci” (wraz z jej powodem)
• Proces–nadzorca…
• taktyka rozwiązywania błędów
• kontekst grupy procesów
• bonus: logiczny podział systemu

16. Jak poprawiać błędy…?
1. Analiza problemu
2. Tworzenie poprawki
3. Wyłączenie systemu…
4. …aktualizacja…
5. …włączenie systemu…?
• Miało być bez
przestojów!
• Hot–code reload
• „Wojna pokoleń”

17. Gdzie jesteśmy?
• Jest dobrze, ale język musi być jeszcze dobry do
pisania sterowników…
• …bez przesady.
• Sterowniki w C mogą
mieć błędy!

18. PLEX vs Erlang
• niskopoziomowy — funkcyjny i
prosty
• bezpieczne wskaźniki — bez
wskaźników
• np. tablice o zmiennym rozmiarze
— dynamiczny z garbage
collectorem
• maszyna stanów, kolejki —
niezależne procesy z własnymi
kolejkami
• nieinterferujące bloki programowe
— niezależne procesy
• aktualizacja kodu w czasie
działania — aktualizacja modułu
w czasie działania
• ∅ — obliczenia rozproszone
• zaawansowane możliwości
debugowania
• odzyskanie sprawności po awarii
oprogramowania i sprzętu

19. Co uzyskaliśmy?
• Ericsson AXD301 — milion linii Erlanga, uptime
99,9999999% (tj. „downtime” 31 ms rocznie)
• W przyszłości WhatsApp: >2 mln połączeń TCP
per serwer; 32 inżynierów kontra 27 mld msg/dzień,
450 mln użytkowników/miesiąc
https://twitter.com/WhatsApp/status/344966710241161216
https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/

20. Don’t drink too much
kool–aid!
• „It is essential for security to be able to isolate
mistrusting programs from one another, and to
protect the host platform from such programs.
Isolation is difficult in object-oriented systems
because objects can easily become aliased”
— Ciaràn Bryce & Chrislain Razafimahefa, An approach to
safe object sharing. ACM Press, 2000.
• Trzeba wyjść poza poziom oprogramowania —
konieczny klaster wzajemnie kontrolujących się
maszyn

21. Budowa programów
„Erlang Style”
• „Disaster recovery” explicite i czytelnie
• „Optymistyczne” programy — kod skupia się na
logice biznesowej
• OTP — Open Telecom Platform
• gen_server, supervisor, application, …
• „release”

22. To wcale nie jest
live–coding!
https://github.com/kgadek/beat
branch v1

23. merge( [], [], Acc ) ->
lists:reversed( Acc );
merge( [ Head1 | Tail1 ],
[ Head2 | Tail2 ],
Acc
) when Head1 > Head2 ->
merge( Tail1, Tail2, [Head1, Head2] ++ Acc );
!
merge( [ Head1 | Tail1 ],
[ Head2 | Tail2 ],
Acc
) ->
merge( Tail1, Tail2, [Head2, Head1] ++ Acc ).
https://gist.github.com/kgadek/9837979

24. merge( [], [], Acc ) ->
lists:reversed( Acc );
merge( [ Head1 | Tail1 ],
[ Head2 | Tail2 ],
Acc
) when Head1 > Head2 ->
merge( Tail1, Tail2, [Head1, Head2] ++ Acc );
!
merge( [ Head1 | Tail1 ],
[ Head2 | Tail2 ],
Acc
) ->
merge( Tail1, Tail2, [Head2, Head1] ++ Acc ).
!
!
—————————————————————————————————————————————————————————————
merge [1,1,1,1] [2,2,2,2] → [1,2,1,2,1,2,1,2]
?! ?! ?!
!
merge [1,2,3,4] [5,6,7,8] → [1,2,3,4,5,6,7,8]
https://gist.github.com/kgadek/9837979

25. Erlang nie jest
złotym środkiem!
• Jest „wytrychem” stworzonym do rozwiązywania
konkretnych problemów
!
!
Pytania?