Выступление Максима Лапшина на FP митапе 2014. Тема доклада — введение в Erlang.

1. Erlang
Макс Лапшин
Эрливидео
max@erlyvideo.ru

2. Что такое Erlang?
1. Язык программирования
2. Виртуальная машина
3. Фреймворк для создания сетевых
сервисов

3. Откуда взялся Erlang?
1. Более 20 лет эксплуатации
2. Создан и развивается в Ericsson
3. Проектировался инженерами, которые
любят спать по ночам
4. Unix среди DOS в мире VM

4. Для чего нужен Erlang?
1. Разработка долгоживущих сетевых
серверных приложений с высокой ценой
простоя
2. Построение систем с изолированными
компонентами
3. Безболезненное масштабирование по
ядрам и компьютерам

5. Когда нужен Erlang?
1. большой поток данных
2. массовый сетевой и дисковый I/O
3. много состояний в памяти
4. разделяемые ресурсы
5. большое время жизни данных
6. multicore и multinode

6. Почему не Java?
1. Erlang гораздо проще, чем Java
2. Легче создать стабильную систему
(правильное управление ошибками)
3. Упрощенное управление ресурсами
4. Сильная ориентированность на сетевой
ввод-вывод и подключенных клиентов

7. Опыт эксплуатации
1. Гораздо дешевле разрабатывать софт
2. Быстро искать и переучивать людей
3. Легко поддерживать
4. Быстрая реализация VM
5. В несколько раз меньше кода

8. Введение

9. Введение в Erlang
1. Как хранятся данные?
2. Как их обрабатывать?
3. Как группировать логику?
4. Как обрабатывать ошибки?
5. Ввод-вывод
6. Виртуальная машина

10. Типы данных
1. Числа
2. Атомы
3. Блобы (binary)
4. Reference
5. Функции
6. Порты
7. Пиды
8. Кортежи (tuple)
9. Хеш-таблицы (map)
10. Списки

11. Немутабельность
1. Переменных нет, есть только значения
2. Композитные структуры create once
3. Невозможно создать ссылочную петлю
4. Сравнение только по значению
5. Массивы с O(N) обновлением и не нужны
6. Хитрая реализация мутабельного
состояния (ниже)

12. Функции
1. Код есть только в функциях
2. Вне функций кода нет
3. Функции определяются именем и
количеством аргументов
4. Значений по-умолчанию нет
5. Есть разные тела одной функции (клозы)
6. Рекурсия вместо цикла

13. Модули
1. Модуль — группа функций
2. Функций вне модуля нет
3. Анонимные функции привязаны к
модулю
4. Единица горячей замены кода
5. Компилируются в байткод. JIT не
работает

14. Обработка данных
1. Ввод-вывод данных
2. Управляющие конструкции
3. Обработка массива данных
4. Структуры данных
5. Изменение данных

15. Ввод-вывод данных
1. file:open, file:pread, file:pwrite
2. gen_tcp:connect, send, recv
3. gen_tcp:listen, accept

16. Pattern-matching
1. Перебор разных веток кода подходящих
по значению
2. Это вместо ООП: классификация данных
не глобальная, а локальная
3. Автоматическая деструктуризация
данных
4. Вместо if

17. Массивы
1. Список — основной контейнер
2. for(i = 0) не используется
3. Рекурсивный перебор списков в
различных вариантах
4. map, fold, mapfoldl, flatmap, partition…
5. Кортежи фиксированной длины, но O(1)

18. Структуры данных
1. Immutable версии структур
2. Композиция из списков и кортежей
3. dict, set, graph, array и т.п.
4. Используются не очень часто

19. Мутация данных
1. Все значения неизменяемые
2. Все значения обрабатываются в функциях
3. Надо получить из функции новое
значение и отдать его дальше
4. Рекурсия вместо бесконечного цикла
5. Аргумент функции как эксплицитное
состояние

20. Процесс
1. Рекурсивно зацикленная функция — это
процесс
2. Её состояние снаружи ненаблюдаемо
3. Процессы порождаются отстреливанием
новой функции
4. Pid — идентификатор процесса
5. Всё как в Unix

21. Коммуникация процессов
1. Обмен только через сообщения и I/O
2. Асинхронная посылка сообщений по Pid
3. Глобальная регистрация Pid по atom
4. Блокирующее получение с таймаутом
5. Оповещение о смерти другого процесса

22. Ошибки в процессах
1. Изоляция данных и исполнения
2. Изоляция ошибок и проблем
3. Автоматический контроль за ресурсами
4. Оповещение соседей о смерти
5. Автоприбивание соседей

23. Объекты на процессах
1. Обмен сообщенями вместо вызова метода
2. Pid вместо ссылки
3. Глобальные переменные через register
4. Внутреннее состояние скрыто
5. Нереентерабельны
6. Сериализованный вызов методов

24. gen_server
1. Реализация generic объекта на процессах
и сообщениях
2. Сериализованные и синхронизированные
вызовы методов
3. Горячее обновление кода
4. Откладываемый ответ на вызов метода
5. Конструкторы, деструкторы
6. Автоматический контроль дедлоков

25. Псевдо-методы
1. Отдельный клоз handle_call — вызов
метода
2. Есть асинхронные методы: handle_info

26. BEAM
1. Одна из 4-х платформ с многоядерностью
2. Epoll/kqueue
3. Собственные аллокаторы

27. Multicore
1. Процессы расползаются по ядрам
2. Обмен сообщениями с минимум локов
3. Нет шаринга данных — нет мьютексов
4. Работает на 72 ядрах
5. Черная магия мьютексов в ETS

28. Приложения на Erlang

29. Приложения на Erlang
1. Erlang OTP
2. supervisor
3. application
4. ets
5. потоки данных
6. многоядерность

30. Erlang OTP
1. Фреймворк на Erlang
2. Сообщения и процессы — это примитивы
3. Реализация ряда паттернов на базе
процессов
4. Обеспечение гарантированной
работоспособности в рамках паттернов

31. supervisor
1. Процесс, следящий за другими
2. Поддерживает синхронно группу
процессов
3. Реализует паттерн «выключателя» для
заглючившей системы
4. Выключается, если слишком часто всё
ломается

32. application
1. В простонародье «библиотека»
2. Но со своими тредами — процессами
3. Со своим пулом данных в памяти

33. gen_event
1. Процесс, в который можно положить
коллбеки
2. Коллбеки с состояниями
3. Годится прежде всего для логов

34. Как хранить данные?
1. В процессах
2. На диске
3. В сети
4. В БД в памяти (ets)

35. ETS
1. Глобальное хранилище кортежей
2. Очень хорошо оптимизировано
3. Пользоваться только как хеш-таблицей
4. Вторичные индексы через mnesia
5. Легко можно свалиться в race conditions
6. Писать через процесс (*), читать через ets

36. Поток данных
1. Вызовы методов — сообщения
2. Сообщения — память
3. Бутылочное горлышко — утечка памяти
4. Надо контролировать входную скорость
5. Развязывать бутылочные горлышки

37. Flow control
1. Бесконтрольная посылка сообщений —
зло
2. gen_server:call помогает
3. process_info(Pid, message_queue_len)

38. Пулы воркеров
1. Вместо одного процесса можно поставить
8 или 16
2. Шардирование по воркерам помогает
распределению по ядрам

39. Отладка

40. Отладка
1. printf
2. trace
3. process_info
4. recon

41. Печать
1. io:format — это плохо
2. логгирование с lager — хорошо
3. уровни журналирования, метадата

42. trace
1. Мониторинг всех сообщений, вызовов
функций и событий процесса
2. Лучше чем gdb, потому что локален для
одного процесса

43. process_info
1. Неинвазивный способ мониторинга
процесса снаружи
2. Интроспекция стека, состояния,
потребления памяти и CPU

44. recon
1. Библиотека для отладки аллокаторов
2. Иногда помогает покрутить ручки для
настройки их эффективности

45. Тестирование

46. Тестирование
1. eunit
2. common_test
3. meck

47. eunit
1. считается простым
2. хорошие сообщения об ошибках
3. нет логов
4. тяжелый синтаксис конфигурации

48. common_test
1. умеет делать HTML логи
2. похуже сообщения об ошибках
3. умеет быть распределенным

49. meck
1. Временное перекрытие функций
2. очень медленно
3. лучше избегать
4. иногда очень полезно

50. Полезные инструменты

51. Полезные инструменты
1. инфраструктура (rebar)
2. веб-сервер (cowboy)
3. логи (lager)
4. json (jsx, jiffy)
5. http-клиент (lhttpc)

52. Вопросы?
Макс Лапшин
max@erlyvideo.ru