ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
4 года разрабатывает видеостриминговый сервер эрливидео и в этом докладе расскажет о некоторых отличительных возможностях Erlang, которые позволяют быстро развиваться и поддерживать высочайшее качество ПО минимальными усилиями.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
ELK: менеджмент логов, быстрая локализация проблем / Сергей Шумов (News360)Ontico
Сначала несколько слов про предпосылки задачи.
1. Что нам завещали деды: zcat | cut | sort | uniq -c | sort -nr . На самом деле, нормально работает, когда на проекте есть только лог nginx и не больше пары ГБ в день. В случае аварий tail -f | grep позволяет найти проблему за пару минут.
При первой же попытке параллелизации инстансов работать становится неудобно, нужна
2. Сборка логов: syslog-ng, rsyslog etc. Логи с локальных syslogd по UDP агрегируются в одно общее файловое хранилище.
Помогает собирать файлы логов с разных инстансов или сервисов. Минусы:
* Мы по-прежнему ограничены общим объемом логов. Текущие аварии на одном сервисе локализуются сравнительно быстро, но ретроспективная статистика строится часами.
* Появляются неприятные артефакты: задержки при доставке логов в хранилище, неупорядоченность событий в логах из-за разной задержки на разных инстансах. Последнее - вообще, беда, так как по-хорошему требует полной пересортировки лога.
* Поскольку события хранятся как строки в файлах логов, нет жесткой необходимости соблюдать формат. Значит, он соблюдаться и не будет. Нет, все будут стараться, но косяки все равно постоянно будут возникать.
* Отвратительно (муторно, медленно, вручную) работает трекинг проблемных реквестов, особенно в сложных системах с десятками взаимосвязанных сервисов.
3. Ок, давайте сделаем все правильно:
* для всех логов будет описан формат полей;
* события вместо файлов будут храниться в горизонтально масштабируемой БД;
* большинство агрегатов будет рассчитано заранее.
Дальше пара слайдов про компоненты ELK и переходим к главному: как Kibana помогает в локализации проблем.
Полезные фичи Elastic & Kibana:
* мгновенное масштабирование от месяцев до долей секунд;
* статистика распределения для каждого поля по любому диапазону и фильтру;
* field templates;
* significant terms filtering;
* geohashing;
Несколько кейсов, где Кибана выступает отлично:
* Получение списка объектов/пользователей, на которых возникают проблемы;
* Трекинг связанных проблем на разных сервисах;
* Просмотр сессии конкретного пользователя;
* Выявление аномальных пользователей (ботов);
* Отслеживание последующих действий пользователей, попавших во всплеск активности. Средства вроде graphite визуализируют только суммарные значения, а сильная сторона Kibana именно в трекинге отдельных пользователей.
Метрики и дашборды: тут они с graphite примерно одинаково гибки, но упомянуть об этом надо.
* Как отслеживать связанные события в разных логах? Связка через общий request_id vs полное добавление контекста в событие.
* LogStash vs fluentd для доставки? Мы выбрали fluentd - меньше затраты ресурсов.
Кратенько об альтернативах, плюсы-минусы:
* realtime log readers: LogWatch
* LaaS: Splunk
Планирование требуемых ресурсов, (не-)линейность масштабирования.
4 года разрабатывает видеостриминговый сервер эрливидео и в этом докладе расскажет о некоторых отличительных возможностях Erlang, которые позволяют быстро развиваться и поддерживать высочайшее качество ПО минимальными усилиями.
Golang в действии: Как нам удается писать highload приложение на (не?)подходя...Daniel Podolsky
Последние 2 года язык Go является моим - нашим - основным средством заработка на хлеб. Хватает, в общем-то, и на хлеб, и на масло, а иногда и на красную икру.
Не покривив душой, я могу сказать, что мы относимся к языку Go и его создателям с симпатией и уважением.
Однако, при всем нашем уважении, заявить, что Go предназначен для "тяжелых" проектов, я, не покривив душой, не могу.
Во-первых, Go молодой язык, для которого еще не известны паттерны и - что важнее - антипаттерны. Тем, кто пишет на Go тяжелое приложение сегодня, приходится тратить существенное время на тесты и оптимизации
Во-вторых, выразительные средства Go довольно скудны, что приводит к появлению в коде ужасающего количества boilerplate, за которым эффективно прячется бизнес-логика. Программу на Go бывает трудно охватить взглядом и поместить ее модель себе в голову просто из-за количества строк, которые надо для этого прочесть.
В-третьих, у Go есть проблемы с эффективностью кода. У Go плохой оптимизатор. У Go плохо с "заточкой" под железо - вспомним хотя бы историю с патчем CloudFlare для TLS. Патч ведь так и не попал в основную ветку...
Возникает вопрос - почему же, не по наслышке зная о вышеперечисленных проблемах, мы пишем наш реально тяжелый проект именно на Go?
Ответ прост: Go не идеален, но под наши задачи он подходит лучше всего.
Раньше мы строили разные тяжелые бекенды на perl, python, java, groovy и даже lua+nginx. Нам есть, с чем сравнивать.
Во-первых, Go достаточно быстр. Во всяком случае, он быстрее perl и python на нашем профиле нагрузки.
Во-вторых, и это важнее, Go предоставляет вполне достаточные средства контроля за потреблением как RAM, так и CPU. Например, регулярные выражения Go не такие гибкие, как pcre, и, по моим наблюдениям, медленнее, чем pcre. Но! регулярные выражения в Go всегда отрабатывают за предсказуемое время!
В-третьих, создатели языка не врут нам - они, действительно, постарались сделать язык, на котором человекочитаемую программу написать проще, чем нечитаемую. И у них - с некоторомы оговорками - получилось! Даже пресловутый boilerplate не способен этому помешать.
Наконец, Go просто сумел нам понравиться, чего уже давно не случалось с языками программирования.
Итак, на основании опыта, полученного при создании пилотной версии проекта inCaller.org я расскажу о том, как мы писали на Go тяжелое приложение.
Миллионы одновременных персистентных websocket соединений, десятки тысяч коннектов по ssl в секунду, сотни тысяч в секунду обновлений записей в БД.
Я расскажу об антипаттернах, нами обнаруженных, о методике тестирования производительности, анализа проблем и способах с проблемами справиться.
Доклад рассчитан на backend-программистов, как на языке Go, так и на других.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Рельсы прекрасный инструмент, но в некоторых ситуациях они не справляются.
В этом докладе рассказывается о таких ситуациях и одном из вариантов решения
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
BED-Con 2016 - I have a stream - Einsichten in Reactive ProgrammingJan Carsten Lohmüller
Eine der häufigsten Beschreibungen von Reactive Programming ist, dass Reactive Programming aus der Kombination von Immutable Streams und propagation of change besteht. Bei dem Begriff propagation of change, der Verbreitung von Änderungen, denkt man direkt an das Observer-Pattern, welches in diesem Vortrag klar von Reactive Programming abgegrenzt wird.
Mithilfe von kleinen Beispielen wird das Prinzip von Observables, eine der Grundsteine des Reactive Programming betrachtet. Dabei tauchen alte Bekannte, wie Lambda-Expressions und Map/Reduce auf.
Natürlich existiert bereits ein Manifest, welches beschreibt, was ein Reaktives System ist: Responsiv, Widerstandsfähig, Elastisch und Nachrichtengetrieben.
Nach diesem Überblick stellen wir uns folgende Fragen:
Ist Reactive Programming überhaupt ein neues Paradigma?
Wie testen wir Reaktive Systeme?
Wer hat die Kontrolle über Reaktive Systeme, wenn alles auf ständiger Veränderung basiert?
The paper with description of the climate change, approaches for addressing it, hurdles in the way for needful changes in policy presents importance of interfaith commons as the grounds on which a comprehensive strategy needs to be built. This paper should be read by all seeking an answer to the kinds of changes required for addressing the critical challenge.
“Чем хорош Erlang вообще и для веб-разработки в частности?” Olga Lavrentieva
Юрий Жлоба (TvZavr.ru, Москва)
Доклад: “Чем хорош Erlang вообще и для веб-разработки в частности?”
О чем: Для какого именно веба хорош Erlang? Он не имеет ничего, сопоставимого с Ruby on Rails, тогда зачем его использовать в вебе? Вносим ясность. Примеры успешных веб-проектов на Erlang.
Что такое REPL, как он устроен и какие крутые возможности в нём заложены. Поговорим о выполнении кода в REPL и о том как работает автокомплит в динамических языках. Ответим на вопрос что такое vm.runInContext, перехватим парочку промисов, сделаем вывод результатов действительно приятным и даже узнаем как подгрузить нужные модули и не подать виду. В заключение рассмотрим потрясающие возможности, которые даёт нам инфраструктура npm и как это всё можно использовать в работе.
Доклад ориентирован на тех, кому небезынтересен мир Node.js, но будет доступен также и более широкому кругу JS-разработчиков. Надеюсь, для кого-нибудь этот доклад станет очередной ступенькой в изучении любимого языка.
32 подводных камня OpenMP при программировании на Си++Tatyanazaxarova
С распространением многоядерных систем задача параллельного программирования становится все более и более актуальной. Данная область, однако, является новой даже для большинства опытных программистов. Существующие компиляторы и анализаторы кода позволяют находить некоторые ошибки, возникающие при разработке параллельного кода. Многие ошибки никак не диагностируются. В данной статье приводится описание ряда ошибок, приводящих к некорректному поведению параллельных программ, созданных на основе технологии OpenMP.
Mobile Monday Kiev#1 - How to save time in Mobile Apps DevelopmentIntersog
Intersog acted as a general partner of relaunched Mobile Monday (MoMo) event in Ukraine that took place in Kyiv on June 25, 2015. See the top moments from Mobile Monday Kyiv #1!
MoMo is a global platform for IT knowledge sharing and professional networking that is currently being active in 140+ cities worldwide. MoMo offers different networking formats aimed to enhance public knowledge of the most trending mobility topics and innovation. Read more and join Mobile Monday: http://intersog.com/news/intersog-helps-relaunch-mobile-monday-ukraine/
Плюсы и минусы Go для разработчиков на C++, Вячеслав БахмутовYandex
В докладе речь пойдёт о языке Go. Вячеслав расскажет о внутреннем устройстве языка (структуре, оптимизации, сборщике мусора и т.д.), о том, как и почему Go используют в Яндексе и что о нём говорят разработчики на С++. Отдельно Вячеслав остановится на многопоточном программировании и особенностях отладки и профилирования в Go.
Сергей Крыжановский - Языки программированияYandex
В мире существует не один, и даже не два языка программирования, их очень и очень много. В лекции рассказано про то какими бывают языки программирования, почему их так много, и зачем вообще нужно и полезно смотреть в сторону каках-то новых языков, кроме своего любимого.
1. Организационные и формальные вопросы.
2. Пользователь всегда прав!
3. Что такое язык программирования?
4. Краткая история развития языков программирования: машинные коды, ассемблер, языки высокого уровня.
5. Способы трансляции: компиляция и интерпретация.
6. Виртуальные машины.
7. Ученье — свет, неученье — тьма (для программиста: потеря работы).
1. Кое-что про
Erlang
а также OCaml, Haskell
Perl, PHP, C и C++
Лев Валкин, 2010
1
2. О докладчике
Драйверы на Asm x86 (1993)
Веб-сайты на C, Shell, Perl (1996+)
Математические обучалки на Delphi (1998)
SMS-гейт на C, C++, Visual Basic (2001)
Ускорял HTTP[S] на C, M4 (2003, два раза изобрёл LISP)
Куски embedded-платформы Cisco ASA/PIX
2
4. 2006: Быстрый старт
Цель: быстро сделать эксперимент
4 дня программирования на Perl, через неделю
— анонс на TechCrunch (2006)
Привалило трафика (Sun SPARC 600 MHz)
Часть функциональности сброшено на C
(для скорости)
4
5. 2007: Развитие
Количество программистов: 1
Perl; в критических участках — C
Сложность дебага: 0
Сложность развития: удовлетворительная
Когда нет команды, любая знакомая
технология будет приемлемо работать!
5
6. 2007: Развитие
Количество программистов: 4
Perl; в критических участках — C
Сложность дебага: начинаются проблемы
Развитие:
Perl: разводится бардак в коде
C: разводятся sigsegv в продакшне
6
7. 2008: Развитие
Количество программистов: 5-10
В Perl растёт лапшизм в коде
Perl заменяется на Erlang (для нового кода)
Те же люди (!)
Без опыта в ФП (!!)
В условиях ограниченного времени и бюджета
7
8. Интермиссия: Erlang
Считается функциональным языком
Неизменяемость «переменных»
Горячая замена кода
«Конкурентно-ориентированный»
— Процессы изолированы, общаются
сообщениями
Чрезвычайно простой
8
9. Простой Erlang
«Erlang действительно учится за две недели,
это не миф»
http://grey-kristy.livejournal.com/87271.html
«По информации от различных источников: 2
недель хватит»
http://levgem.livejournal.com/285670.html
9
10. Мини-опрос
Спросил наших разработчиков
«Я бы положил на эрланг от одной до двух
недель плотного изучения с упражнениями».
«Достаточно одной — двух недель (прочитать
getting started guide или книгу Армстронга)».
«Можно учить специально и непрерывно, а
можно по наличию задач. Изучал по второму
варианту; за месяц».
10
11. Мини-опрос
«Писать можно на эрланге через неделю — с
докой, через две — с докой на полке, через месяц
— комфортно».
«Уверен, что можно выучить erlang и уже
попробовать OTP за месяц. Без OTP вообще
наверное недели две».
«По эрлангу, чтобы начать писать модули — недели
две чтения мануалов и тьюториалов. И еще пару
недель доучиваться erlang-style кодописанию».
11
12. С точки зрения
руководителя
Нанимаемые специалисты имели опыт от PHP
+JavaScript до C/C++, но не имели опыта в ФП.
Предыдущий опыт на скорость обучения не влияет.
Возраст — 22-35 лет, на скорость изучения не
влияет.
При наличии задач, обучение происходит быстро,
в горизонте оперативного планирования
(2-4 недели).
12
13. С точки зрения
code nazi
«Набеговое программирование» в команде
располагает делать спагетти-код, кишащий сайд-
эффектами.
Erlang «сопротивляется» эффектам, к которым
приводит спагетти-код:
Процессы изолированы, эффекты плохого кода в
одной подсистеме не влияют на другую.
Связанные процессы не позволяют редкой ошибке
привести к отказу системы.
13
14. С точки зрения
code nazi
Неизменяемые переменные и отсутствие
глобальных переменных поощряют разработку с
минимумом сайд-эффектов.
Эти же свойства упрощают независимое
тестирование подсистем.
14
15. Адвокат дьявола
В распространённых языках проблема спагетти-кода
облегчается инструктажем, соглашениями о коде,
юнит-тестами и ревью кода. А если проблема не
стоит, зачем использовать Erlang? Тем более, для
программ в функциональном стиле сложно
проводить code-review.
В нашей компании делается ревью Erlang-кода.
Спросим инженеров, что легче, ревью скриптового
языка, на котором они писали до эрланга, или ревью
Erlang-кода?
15
16. Ревью P* vs. Erlang?
(Знание языков. «Отзыв»)
Erlang >> P*. «Конечно, [Erlang] проще. Меньше
возможностей для сайд-эффектов. Функции из других
модулей qualified, проще искать код».
Erlang (0.7) Perl (0.5). «[Erlang] Проще».
Erlang (0.8) Perl (0.5). «[Erlang] Однозначно проще.
Когда пару раз столкнешься с проблемами в перле,
начинаешь понимать, что ревью там делать очень
сложно».
16
17. Ревью P* vs. Erlang?
PHP (1.0) Erlang (0.7). «Одинаково».
PHP (0.7) Erlang (0.6). «Владея контекстом, легче
делать ревью на erlang код».
Perl (0.9) Erlang (0.8). «Думаю, одинаково. Ревью
функционального кода требует более глубокого
вникания, но менее "богатый" синтаксис и компактный
код упрощают понимание».
Perl (1.0) Erlang (0.8). «Проще [Erlang]».
17
18. Ревью P* vs. Erlang?
Те, кто знают Erlang лучше (кстати, почему?), говорят,
что для Erlang проще делать код-ревью. Логично.
Те, кто знает P* языки лучше, говорят, что для Erlang
не сложнее делать код-ревью. Почему?
«Менее богатый синтаксис и компактный код
упрощают понимание».
«Меньше возможностей для сайд-эффектов».
18
19. 2009: Ускорение
Напомню: Perl → (Perl, C) → (Erlang, C/C++)
Проблема: никто не хочет работать с C/C++. Сложно
найти или обучить людей (N.B.: обычно этот аргумент
выдвигают против FP!)
«Набеговое программирование» даёт сбой и здесь.
Sigsegv в продакшн становятся ежедневной
проблемой, а то и бизнес-риском. Valgrind и анализ
корок помогают, но симптоматично, не устраняя
причины.
19
20. 2009: Ускорение
Идея: попробовать Haskell (я знал неплохо).
Риски: кривая обучения, производительность
решения.
Сделан аналог C++ кода на Haskell.
В 10 раз медленнее (в 10 раз больше машин?!)
После оптимизаций — в 3 раза медленнее. Плохо.
20
21. 2009: Ускорение
Альтернатива: попробовать
OCaml (никто не знал).
Риски те же: кривая обучения,
производительность.
Аналог нашего основного C++
компонента:
Решение в лоб: ~5-10%
быстрее (да, свежий код).
В ~5 раз — на несколько тысяч
строк — короче (см. рис.)
Пришлось задействовать две
глобальные переменные.
21
22. 2010: Настоящее
Эволюция ядра системы:
Perl → (Perl, C) → (Erlang, C/C++) → (Erlang, OCaml)
Другие языки тоже используются: Perl, PHP, Python,
JavaScript (на клиенте), C, C++, Haskell (для генерации
JS).
Примерно в 3-5 раз больше функционального кода.
22
23. Кококомл
— Он спрашивает, «как ока?»
— Ну и ответь ему, «ко-ко-ко»
Изучаемость: «Примерно в два раза дольше, чем
эрланг». «Без опыта в ФП — месяца два, если есть
опыт, то хватит месяца». (А также «две недели» и «месяца
три»)
«Окамл я знаю хуже C++, но разбираться в нем
(окамле) проще, чем в C++». Кстати, как в OCaml с код-
ревью?
23
24. Ревью C/C++ vs. Ocaml
(Знание языков. «Отзыв»)
C+/C++ >> OCaml: «По сравнению с c/c++ окамл я знаю
намного хуже. При солидной форе в сторону
c/c++ я считаю, что код-ревью в ocaml проще, опять
же, из-за почти отсутствующих сайд-эффектов».
OCaml (0.4): «Сложнее».
C/C++ (0.8) OCaml (0.6): «Для меня пока сложнее или
одинаково».
24
25. Ревью C/C++ vs. Ocaml
OCaml (0.7) C (0.5): «Сложнее. Причина в основном в
каринге и использовании функций без точечной
нотации».
OCaml (0.6) C (0.6): «Если изменения в коде
масштабные, ocaml ревьюить сложнее».
25
26. Erlang vs. OCaml
executive summary
Erlang быстро изучается и положительно
воспринимается командой, быстро переходя в список
«комфортных, своих» языков.
«Из всех перечисленных языков эрланг нравится
больше всех, не для решения конкретных задач, а
просто по ощущениям» (респондент знает PHP глубже, чем Erlang)
OCaml воспринимается тяжеловато, как типичный
«неосновной язык». Делать ревью кода для него
сложнее, чем для C/C++. Может ли это быть артефактом
лаконичности (количество смысла на строчку) кода?
26
27. Erlang vs. OCaml
executive summary
Инженеры отметили положительное влияние отсутсвия
сайд-эффектов на программирование и код-ревью OCaml
и Erlang.
Erlang прост! Необычность синтаксиса более чем
компенсируется его простотой. Понятная и элементарная
семантика. REPL.
Идиосинкразии (не просто необычности, а реальный shit)
синтаксиса OCaml вызывают нарекания в процессе
обучения. Ограниченный REPL.
OCaml компилируем и быстр! Если не делать специальных
оптимизаций, то OCaml ~= C/C++, особенно если
переписывать существующий код.
27
28. Erlang
Erlang хорошо себя зарекомендовал для общего
серверного программирования: command-and-
control, координирование потоков данных,
управление функциональностью, написанной на
других языках (OCaml, C/C++, Perl, Python).
В нашей компании он занял нишу динамических
серверных языков (Perl, PHP, Python).
Независимость процессов и лёгкость
коммуникации между ними приводят к простоте
решений и изоляции негативных эффектов. В
продакшн можно пускать неидеальный код.
28
29. OCaml
OCaml хорошо зарекомендовал себя при
необходимости делать символические вычисления,
порождая эффективный код.
В нашей компании он занял нишу C/C++.
Если есть возможность, рекомендую учить Haskell
(ради стройности на концептуальном и
синтаксическом уровне), затем использовать
OCaml, если появится нужда в скорости,
предсказуемости поведения или желание иногда
использовать сайд-эффекты без излишнего
монадизма.
29