Comments 38
Вот интересно, а можно было без лямбд обойтись ? В чем необходимость такого решения ?
Смысл лямбд простой - они эластичны. Не нужно держать ресурсы пока у вас нет задачи. Ну и большинство "эластичных" сервисов амазона на это расчитаны. То есть платите только за "машинное время" потраченное на ваши вычисления. И то что их можно запустить больше или меньше в зависимости например от объёма логов - это облегчает получение результата за примерно ожидаемое время.
Наоборот нередко бывает, особенно в больших конторах, что какой-нибудь сервис занимает 3 пода в кубере - а вызывается раз в пару дней на несколько минут. Вот это неэффективно.
Так что лямбды тут (тем более что весь проект для сервисов на амазоне) - вполне обусловлены.
Если у вас код на арланге работает в 100 раз медленнее то вы будете платить значительно больше(если не менять архитектуру), неважно лямбды это, вирталки, контейнеры. В данном случае основная проблемав библиотеке, а в ней, судя по статье, от особенностей эрланга.
А если говорить про лямбды, то они один из самых простых и удобных механизмов когда нагрузка динамическая и резко скейлится, большинство других вариаций будут либо проставивать ожидая мощностей, либо по пару минут скейлится.
Либа для разбора наших кастомных пакетов была написана (на Эрланге же) отцами основателями, доки на формат не было и переделать бы её саму - но всем страшно.
Дело было не бабине Erlang...
Ну как, разгильдяйства в этом смысле я не отрицаю, но само по себе наличие док эрланговский код бы не ускорило. Я рассчитывал переписать эту либу на си, но решили что по времени не уложимся из-за необходимости ресерчить ее.
Вообще ситуация не уникальная. В spark например можно на питоне писать (удобнее) а можно на scala (быстрее). Интерпретируемые языки в бигдате надо с осторожностью юзать.
Можешь поделиться тестовым заданием, которое выдали чтобы самому разобраться и ознакомиться с языком?
Не проблема :) валяется у меня на гитхабе - в ридми постановка задачи как мне ее прислали.
https://github.com/RodionGork/erlang-movavg
Там видно что задачка не специфична для эрланга.Если захочется попробовать сначала на более обычном языке - то я как раз недавно воссоздал ее вот тут (это я планирую сделать сайт с разными заданиями собесов и т.п. но пока вещь в зачаточном состоянии) https://ca4pro.com/index/task_view/moving-average-on-metrics
Рекомендую взглянуть на язык Elixir. Это просто праздник какой-то!
И что было дальше? Всем спасибо за сотрудничество, до свидания?
Ну как обычно в таких случаях часть команды от скуки разбегается (и я в том числе) а проект (в лице оставшихся, менеджеров и пр) отряхивается от гуана, как-то оправдывается и через год-другой снова дымит как ни в чем не бывало. Это всё ж не самый критичный фэйл был - просто не успели к заявленным срокам, это было к амазоновской ежегодной конференции приурочено и т.п... В общем, никто не умер.
Тут недавно попался на эрлане один легаси проектик на починку. Пошел читать - что за зверь такой.....
Почитал (ну чуть глубже чем в статье) и поразился сумрачности разума того, кто такое придумать смог.
Ну реально, все должно возвращать результат. А раз так - в цикл - никак - только рекурсия. Вместо if определяется пачка функций с одной сигнатурой, но разным сочетанием входных параметров, часть из которых заменяется константами. А, да, if то все-таки есть, точнее он не if, а почему-то case???. Мессаджинг ну да, есть, но тоже какой-то загадочный и т.к. ... да, да все должно возвращать результат..... ну во общем и обмен сообщениями тоже изрядно через задний проход.
Как же хорошо, что оказалось, что там не в коде проблема, а провайдер API погасил, который этот проект использовал. Ну новый API есть только ни разу не совместим со старым и с-но надо новое писать практически с нуля. Поэтому erlang пошел в топку. RIP.
И, да, поглядев на проект первое, что пришло в голову "да ну его на..., проще на go переписать".
и поразился сумрачности разума того, кто такое придумать смог.
судя по Вашим возмущениям ФП по большей части обошло Вас стороной :) ну это необязательно плохо, хайп по нему сейчас маленько поутих - куда-то провалилась 3-я скала которую так ждали, сгинул 2020-й хаскель - зато очень далёкий от ФП Golang наоборот на коне. Ну я не говорю что это плохо - скорее любопытно рассматривать как меняются интересы сообщества, качаются туда-сюда. Лет дцать назад один тип в фидо с пеной у рта доказывал что скоро всё программирование будет функциональным, а компьютеры - квантовыми. Ну пока не случилось.
проще на go переписать
ну так всегда кажется что на языке Х переписать с нуля проще. пока не переписал и не устроил очередное болото :)
Да нет, например Lisp мне в студенческие годы зашел так хорошо, что я даже дипломную работу сделал на пару с однокурсником: типа Turbo Lisp (на мне интерпретатор, на нем IDE на основе библиотеки от Borland, в которой был сделан Turbo Pascal). Ох и давно это было, сейчас мало кто вспомнит эти названия.....
Да и другой всякой экзотики я пробовал много. Там fortran, и forth, и prolog, и даже java самая первая...
Но вот erlang не зашел. Видимо - не мое.
А go у меня, можно сказать, основной инструмент, ну еще иногда немного python, bash и прочее. Так что переписать на хорошо знакомом иногда действительно проще чем перелопачивать чужой код да еще на довольно загадочном языке.
Ну сам по себе Лисп - он не очень функциональный, он вполне позволяет в императивном стиле писать... А вот упомянутый пролог (если мы из времён Борланда - то наверное Турбо-Пролог вспомним) - он же кстати очень-очень подозрительно на Эрланг похож - все эти списки, мэтчинг... Правдоподобно звучит предположение что Эрланг возник как упрощённая и более приближенная к реальности переделка Пролога.
Правдоподобно звучит предположение что Эрланг возник как упрощённая и более приближенная к реальности переделка Пролога.
Ну prolog (чисто по моему мнению) все же сильно дальше от понятия функционального программирования чем Lisp. Я не пробовал на нем что-то рабочее писать и от для меня остался надстройкой над Lisp (его интерпретатор на Lisp реализуется в 20 или 30 строк, точно уже не вспомню) и это уже по сути экспертная система - то самое на что, в определенную эпоху, ставили как на самую правильную реализацию AI. И тут статья была про одного Чудака (с большой буквы), который до последних дней сам и с последователями набивал фактами экспертную систему которую начал создавать именно в ту эпоху, когда казалось что вот еще чуть-чуть докинуть фактов в экспертку и комп будет умнее человека.
Ну Вы правы что он не для ФП, он же для почти гипотетического "логического программирования" - но если на нём писать "что-то рабочее" - то как раз код будет сильно напоминать то ли Lisp/Scheme, то ли Erlang - те же рекуррентные определения, списки и т.п. Хотя действительно это немного не то для чего он придуман...
Я склоняюсь к мнению, что ФП все таки для промышленного программирования не очень подходит и изза этого хайп поутих. Мощные и компактно написанные конструкции тяжело обратно понять при чтении кода. Проблема с таким ФП кодом есть наглядная демонстрация цитаты Кернигана "Отладка кода вдвое сложнее, чем его написание. Так что если вы пишете код настолько умно, насколько можете, то вы по определению недостаточно сообразительны, чтобы его отлаживать", только к расширению и изменению это тоже относится. Когда система начинает разрастаться, новые люди подключаются к команде - все это выстреливает и код поддерживать становится очень сложно. А дальше "часть команды от скуки разбегается".
Но практиковать и перенимать опыт из ФП языков интересно. Многие императивные языки втаскивают себе удачные конструкции из ФП, а при умелом и сбалансированном использовании улучают читаемость не в ущерб поддерживаемости.
На мой взгляд промышленное программирование очень разное ведь бывает :) где нет вот этого bulk-processing, где не критична голая производительность - ФП более менее заходит. Ну даже польза есть (насчет паралеллизма и т.п.) - так-то если вдуматься - работа веб-сервиса во многом хорошо ложится на ФП - принимаем данные реквестом, отдаём респонзом - каждый эндпойнт можно функцией описать. То есть ФП хорошо в какой-то "фреймворк" обернуть.
Как мне кажется, порой беда с ФП не в языках а в программистах. Не в том смысле что они плохие - но вот именно как Вы описываете - стараются разрабатывать ну так умно, что никто не готов связываться с их творчеством. Наглядный пример по-моему - применение Haskell в компании Biocad. Теоретически логично - чем строже типизация - тем лучше ошибки на этапе компиляции отлавливаются. Но на деле выливается в то что и разработчиков (не то что знающих, но даже желающих изучить этот довольно мозголомный язык) трудно сыскать - и всевозможных библиотек под него написано не так много, и приходится писать самим то и сё, тратя на это в общем-то бизнес-ресурс или свободное время.
Многие императивные языки втаскивают себе удачные конструкции из ФП
В реальности "промышленные языки" просто всосали все "функциональные фишки", которые успели накопиться к 2010м:
Функции, как объекты первого рода - везде есть лямбды в том или ином виде.
Сборка мусора практически везде (в функциональных языках сборка мусора обязательна, либо надо делать как в Rust).
ADT - уже и в Питон завезли pattern-matching.
Иммутабельность - везде, просто не ультимативная, как в Haskell.
ну и т.д., что там я забыл.
Соответственно, если мы можем писать на C++ как на Haskell, при этом у нас куча уже имеющегося кода + значительно лучшая обратная совместимость, то зачем нам Хаскель?
, то зачем нам Хаскель?
ну, очевидно, чтобы нельзя было писать по другому :)
я не сторонник этой концепции, но я её понимаю. в больших проектах которые пишет достаточно большое количество людей, в зависимости от уровня команды может быть ситуация когда кто-то вкорячит что-то непотокобезопасное или немасштабируемое. конечно это во многом вопрос организации работы и подбора коллег - но иногда кажется что стоит взять язык в котором то другое и третье просто невозможно - и проблемы отпадут.
ну, очевидно, порождая другие проблемы
Проблема Хаскеля в том, что он - исследовательский йазыг. Поэтому "avoid success at all costs". Несмотря на великолепную систему типов, из-за самой культуры сообщества вокруг, переход на новый LTS всегда болезнее того же С++ или OCaml. Впрочем, и в OCaml находятся чудаки на букву М (могу прислать ссылку на Cmdliner), но они не в Core Team, и не в ppxlib.
При всём уважении, это - какой-то сумбур :-(
Начиная от "функциональный" и "довольно слабой" типизации c "присвоением", и до примеров кода, который ужасен. Даже разбирать не хочется.
Но...
Любое изменение требует, естественно, скопировать весь binary ...
Уверены, что проблема была именно в этом? Что bin_opt_info выдавало? Dialyzer что показывал?
Ну просто, чтоб заставить BEAM копировать binary - это прям специально стараться надо... и то, не факт, что получится.
Уверен, хотя не думаю что смогу вам привести подробности 6-летней давности.
По остальному... Ну можете сами написать статью, тьюториал, что угодно. Или возьмите второй пример и сделайте так чтобы он работал в 5-10 раз быстрее. Это будет конструктивно и интересно. Я безусловно многого не помню, многого не знаю об Erlang - так что ничего не имею против узнать как с ним работают профи.
Уверен, хотя не думаю что смогу вам привести подробности 6-летней давности.
А на чём базируется ваша уверенность?! Я - грешным делом - с Erlang знаком хорошо. И ваше утверждение что проблема в "копировании binary" - лично для меня выглядит ну очень странно.
Binary (это вот "такое" <<>>... вы же про него?) - отдельный, специальный тип данных. Он - by desing - сделан так, чтоб избежать копирования в пределах VM. И то, для чего Erlang и был придуман, как бы и есть обработка "непрерывного потока" binary. Поэтому - "странно всё это" (с)
Или возьмите второй пример и сделайте так чтобы он работал в 5-10 раз быстрее. Это будет конструктивно и интересно
Дык вся "прелесть" в том, что вы - как иллюстрацию - почему-то взяли решение, которое - в принципе - в декларативном виде выглядеть будет плохо.
Канонически, тут "поиск простых чисел" делается - вот буквально - на "решете" и ленивых последовательностях. И память не жрет, и работает быстро.
Интересно, вообще затык «жрёт в 100 раз больше CPU, чем планировалось» не выглядит как причина не выкатить проект в срок. Даже если реверсить код лень, то не храните архивные логи в проприетарном бинарном формате, возьмите какой-нибудь стриминговый компрессор. А после релиза можно и формат разобрать, и быструю разворачивалку запилить.
Вот главные фишки Erlang от его создателей в ролике 40-летней давности:
https://www.youtube.com/watch?v=xrIjfIjssLE&ab_channel=uncertainyesterday
Видно на чем делали упор и интересующие проблемы того времени.
Просто как дополнение к вашей статье.
Спасибо! Отговорили изучать Erlang.
Хочу познакомиться с разнообразием функциональных языков для общего развития, поэтому собираю копилку, что смотреть. Пока в планах остаются Хаскель, Агда, Рефал, Лисп, Пролог. Эрланг вычеркнул. Буду рад дополнительным советам. Цель — охватить разнообразие языковых механик для кое-каких исследований. Мой опыт — java/kotlin.
Наверное легче будет понять что Вам посоветовать если мы разберемся по какой причине исключили Эрланг.
Из Вашего списка Лисп и Пролог - не ФЯ, практически совсем. Там есть возможность более менее функционально писать - но в целом это не оно. Хаскель наверное вершина м.б. общепризнанная - но выносит мозг типизацией (вплоть до того что инт прочтённый с консоли никогда не сможет быть приведён к инту возникшему просто в коде).
Рефал как я понимаю довольно спецализированная вещь а Агда видимо в сравнении с Хаскелем большой разницы не сделает. Хотя это конечно очень поверхностные суждения.
На котлине любители ФП очень активно пишут, хотя для промышленных применений код где функция обработки фактически передаётся из контроллера в сервис а то и глубже - мне кажется это не айс и довольно трудно вообще обосновать зачем так делать (кроме абстрактных соображений с пеной у рта)
Я работаю над языком для экспликации любых теорий, формализации операций мета-теоретического синтеза и трансляции полученного на реализации. Итоговый язык должен быть ужасно эргономичен, но при этом не терять средства выразительности аксиоматических теорий с логикой какого-то там порядка (пока не знаю какого, практика покажет) и родов структур. Смотрю разные языки, т.к. для разного нужны разные аспекты. Например от рефала трансляция и суперкомпиляция, паттерн матчинг, от хаскеля изучаю теорию функций и функторов (оч прикольно), от лиспа и математики беру общие идеи тулинга для математиков (на математике я немного в универе писал, читал что оно сродни лиспу), от пролога слышал что его используют для логических выражений, от агды и им подобных идеи экспликации теорий так чтобы быть совместимым с автоматическим доказательством теорем. Я только начал, пока мало знаю. Потиху читаю "Клини Введение в метаматематику" и разбираюсь как устроен portal.acconcept.ru, где построена экспликация в родах структур и мета-синтез. Идеи Эрланга больше подходят для реализации, чем для экспликации предметных областей. Поэтому я его пока вычеркнул. Для реализации я как джавист предпочитаю генерить джаву. В целом на джаве можно построить любую архитектуру, если в ней разобраться. Ну и тулинга больше для отладки и сопровождения системы. Я не думаю что в области реализаций нам сильно нужны новые языки. Языки надо изобретать на мета-теоретическом уровне, на котором работает мышление. Здесь пока всё бедно. Собираю по крупицам.
ну, успехов, но боюсь что "смотрением" изучать языки - это далеко уйти не удастся.
от пролога слышал что его используют для логических выражений,
"я слышал, что мир прекрасен - сказал слепой. так говорят, - подтвердил зрячий"
это косвенное подтверждение моего предыдущего предложения - говорят о языках всякое, но если вы поищете какие-то реальные проекты где используется пролог, скорее всего убедитесь что жестоко обманывают.
Да, у меня норм опыта, чтобы это понимать. Начинать с чего-то надо. На этой неделе увлёкся Хаскелем. Это реально круто (несколько ночей не мог оторваться до 3-4 ночи). Пока не буду забегать вперёд, но ещё не дошёл до монад, а уже ряд прорывов в понимании. Вот начинаю главу по монадам.
Хороший учебник https://www.haskell.org/tutorial/index.html
Планирую также наследие Стивена Вольфрама поизучать поглубже вроде new kind of science и т.п. Потихоньку мозаика складывается, Хаскель очень помогает понять метаматематику.
Elixir
Шведский изучать надо обязательно - акторная модель ибо. Хаскелл и всё ML -семейство интересны, Lean4, Isabelle/HOL, Coq, Rust
Если бы это был ООП, можно было бы кусками старого кода загрузить файлы старого формата, потом серилизовать объекты из памяти в новый удобный вам формат, и получилась бы утилита, которую можно прогнать это по всем существующим логам, а потом написать с нуля код, который ищет в логах нового формата то, что нужно. Изменений в коде отцов-основателей не потребовалось бы.
Но с ФП такую утилиту сделать - задача несравненно более сложная.
Чем и иллюстрируется преимущество ООП по сравнению с ФП.
Это, разумеется, не означает, что ООП хороший, а ФП плохой, у обоих свои преимущества и свои недостатки. А из языков я больше всего люблю Питон, в котором оба этих подхода можно смешивать в любой пропорции.
Erlang — классный функциональный язык (или как мы сели в лужу)