Erlang railsclub - 1

944 views

Published on

Небольшой доклад про то, зачем нужен Erlang

Published in: Engineering
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
944
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
8
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Erlang railsclub - 1

  1. 1. Erlang Макс Лапшин Эрливидео max@erlyvideo.ru
  2. 2. Что такое Erlang? 1. Язык программирования 2. Виртуальная машина 3. Фреймворк для создания сетевых сервисов
  3. 3. Откуда взялся Erlang? 1. Более 20 лет эксплуатации 2. Создан и развивается в Ericsson 3. Проектировался инженерами, которые любят спать по ночам 4. Unix среди DOS в мире VM
  4. 4. Для чего нужен Erlang? 1. Разработка долгоживущих сетевых серверных приложений с высокой ценой простоя 2. Построение систем с изолированными компонентами 3. Безболезненное масштабирование по ядрам и компьютерам
  5. 5. Когда нужен Erlang? 1. большой поток данных 2. массовый сетевой и дисковый I/O 3. много состояний в памяти 4. разделяемые ресурсы 5. большое время жизни данных 6. multicore и multinode
  6. 6. Почему не Java? 1. Erlang гораздо проще, чем Java 2. Легче создать стабильную систему (правильное управление ошибками) 3. Упрощенное управление ресурсами 4. Сильная ориентированность на сетевой ввод-вывод и подключенных клиентов
  7. 7. Опыт эксплуатации 1. Гораздо дешевле разрабатывать софт 2. Быстро искать и переучивать людей 3. Легко поддерживать 4. Быстрая реализация VM 5. В несколько раз меньше кода
  8. 8. Введение
  9. 9. Введение в Erlang 1. Как хранятся данные? 2. Как их обрабатывать? 3. Как группировать логику? 4. Как обрабатывать ошибки? 5. Ввод-вывод 6. Виртуальная машина
  10. 10. Типы данных 1. Числа 2. Атомы 3. Блобы (binary) 4. Reference 5. Функции 6. Порты 7. Пиды 8. Кортежи (tuple) 9. Хеш-таблицы (map) 10. Списки
  11. 11. Немутабельность 1. Переменных нет, есть только значения 2. Композитные структуры create once 3. Невозможно создать ссылочную петлю 4. Сравнение только по значению 5. Массивы с O(N) обновлением и не нужны 6. Хитрая реализация мутабельного состояния (ниже)
  12. 12. Функции 1. Код есть только в функциях 2. Вне функций кода нет 3. Функции определяются именем и количеством аргументов 4. Значений по-умолчанию нет 5. Есть разные тела одной функции (клозы) 6. Рекурсия вместо цикла
  13. 13. Модули 1. Модуль — группа функций 2. Функций вне модуля нет 3. Анонимные функции привязаны к модулю 4. Единица горячей замены кода 5. Компилируются в байткод. JIT не работает
  14. 14. Обработка данных 1. Ввод-вывод данных 2. Управляющие конструкции 3. Обработка массива данных 4. Структуры данных 5. Изменение данных
  15. 15. Ввод-вывод данных 1. file:open, file:pread, file:pwrite 2. gen_tcp:connect, send, recv 3. gen_tcp:listen, accept
  16. 16. Pattern-matching 1. Перебор разных веток кода подходящих по значению 2. Это вместо ООП: классификация данных не глобальная, а локальная 3. Автоматическая деструктуризация данных 4. Вместо if
  17. 17. Pattern-matching content(8) -> audio; content(9) -> video; content(18) -> metadata.
  18. 18. Массивы 1. Список — основной контейнер 2. for(i = 0) не используется 3. Рекурсивный перебор списков в различных вариантах 4. map, fold, mapfoldl, flatmap, partition… 5. Кортежи фиксированной длины, но O(1)
  19. 19. Структуры данных 1. Immutable версии структур 2. Композиция из списков и кортежей 3. dict, set, graph, array и т.п. 4. Используются не очень часто
  20. 20. Мутация данных 1. Все значения неизменяемые 2. Все значения обрабатываются в функциях 3. Надо получить из функции новое значение и отдать его дальше 4. Рекурсия вместо бесконечного цикла 5. Аргумент функции как эксплицитное состояние
  21. 21. Процесс 1. Рекурсивно зацикленная функция — это процесс 2. Её состояние снаружи ненаблюдаемо 3. Процессы порождаются отстреливанием новой функции 4. Pid — идентификатор процесса 5. Всё как в Unix
  22. 22. Коммуникация процессов 1. Обмен только через сообщения и I/O 2. Асинхронная посылка сообщений по Pid 3. Глобальная регистрация Pid по atom 4. Блокирующее получение с таймаутом 5. Оповещение о смерти другого процесса
  23. 23. Ошибки в процессах 1. Изоляция данных и исполнения 2. Изоляция ошибок и проблем 3. Автоматический контроль за ресурсами 4. Оповещение соседей о смерти 5. Автоприбивание соседей
  24. 24. Объекты на процессах 1. Обмен сообщенями вместо вызова метода 2. Pid вместо ссылки 3. Глобальные переменные через register 4. Внутреннее состояние скрыто 5. Нереентерабельны 6. Сериализованный вызов методов
  25. 25. gen_server 1. Реализация generic объекта на процессах и сообщениях 2. Сериализованные и синхронизированные вызовы методов 3. Горячее обновление кода 4. Откладываемый ответ на вызов метода 5. Конструкторы, деструкторы 6. Автоматический контроль дедлоков
  26. 26. Псевдо-методы 1. Отдельный клоз handle_call — вызов метода 2. Есть асинхронные методы: handle_info
  27. 27. Псевдо-методы handle_call(balance, _, State) -> {reply, State#s.balance, State}; ….
  28. 28. BEAM 1. Одна из 4-х платформ с многоядерностью 2. Epoll/kqueue 3. Собственные аллокаторы
  29. 29. Multicore 1. Процессы расползаются по ядрам 2. Обмен сообщениями с минимум локов 3. Нет шаринга данных — нет мьютексов 4. Работает на 72 ядрах 5. Черная магия мьютексов в ETS
  30. 30. Приложения на Erlang
  31. 31. Erlang OTP 1. Фреймворк на Erlang 2. Сообщения и процессы — это примитивы 3. Реализация ряда паттернов на базе процессов 4. Обеспечение гарантированной работоспособности в рамках паттернов
  32. 32. supervisor 1. Процесс, следящий за другими 2. Поддерживает синхронно группу процессов 3. Реализует паттерн «выключателя» для заглючившей системы 4. Выключается, если слишком часто всё ломается
  33. 33. Поток данных 1. Вызовы методов — сообщения 2. Сообщения — память 3. Бутылочное горлышко — утечка памяти 4. Надо контролировать входную скорость 5. Развязывать бутылочные горлышки
  34. 34. Flow control 1. Бесконтрольная посылка сообщений — зло 2. gen_server:call помогает 3. process_info(Pid, message_queue_len)
  35. 35. Пулы воркеров 1. Вместо одного процесса можно поставить 8 или 16 2. Шардирование по воркерам помогает распределению по ядрам
  36. 36. Отладка
  37. 37. Отладка 1. printf 2. trace (debugger) 3. process_info
  38. 38. Печать 1. io:format — это плохо 2. логгирование с lager — хорошо 3. уровни журналирования, метадата
  39. 39. trace 1. Мониторинг всех сообщений, вызовов функций и событий процесса 2. Лучше чем gdb, потому что локален для одного процесса
  40. 40. process_info 1. Неинвазивный способ мониторинга процесса снаружи 2. Интроспекция стека, состояния, потребления памяти и CPU
  41. 41. Вопросы? Макс Лапшин max@erlyvideo.ru

×