Небольшой доклад про то, зачем нужен 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. Pattern-matching
content(8) -> audio;
content(9) -> video;
content(18) -> metadata.

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

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

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

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

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

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

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

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

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

27. Псевдо-методы
handle_call(balance, _, State) ->
{reply, State#s.balance, State};
….

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

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

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

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

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

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

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

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

36. Отладка

37. Отладка
1. printf
2. trace (debugger)
3. process_info

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

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

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

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