Comments 68
Толик, спасибо огромное за статью!
Надеюсь, что теории уже скоро будет достаточно для того, чтобы показать как именно Erlang работает на серверах Рисоваськи.
Надеюсь, что теории уже скоро будет достаточно для того, чтобы показать как именно Erlang работает на серверах Рисоваськи.
отличное начало. жду продолжения.
Программу не разу не видел, говорят не плохая, но название… меня оно жутко бесит:) Но это конечно мои проблемы.
Так держать, молодцы!
Так держать, молодцы!
аналогично… тяжело себе представляю, как сказать серьезному заказчику «давайте в рисоваське это обсудим»
Смотря какой заказчик. Если это дизайнерское бюро, то вполне можно порисовать с будущим работником в рисоваське при приеме на работу или посмотреть, как рисует фрилансер. Наши знакомые именно так и хотят ее использовать :)
Все же Рисоваська в данный момент не является заменой традиционных IM: ICQ, Jabber, Skype. Но мы планируем интеграцию, в первую очередь с Jabber.
Все же Рисоваська в данный момент не является заменой традиционных IM: ICQ, Jabber, Skype. Но мы планируем интеграцию, в первую очередь с Jabber.
Спасибо :) Ниже комментарий писал тоже тебе, но по неопытности написал не туда :)
Спасибо!
Замечательная статья! Чувствуется, что вы разбираетесь в Erlang. Очень простым языком объясняете. Заинтриговали вы меня Эрлангом :) интересный язык
Сам очень доволен языком, поэтому так и пишу :) А начал я его изучать всего-то в июле. Он действительно простой и быстро входишь в дело.
Если начали изучать в июле, то сколько писали Рисоваську по времени? o_O
Я немного ошибся, мы начали выбирать язык для сервера в июне и с середины июня уже начали изучать Эрланг. А сервер Рисоваськи в целом закончили за 4,5 месяца.
Шустро вы. А сколько человек работало, в каком темпе и каковы были познания остальных членов команды?
Работало двое. Мои познания в серверном программировании невелики. Дима же, является большим экспертом и архитектором серверных решений. Собственно он и выбрал Эрланг. Работали в обычном темпе, по 8-10 часов, то есть не по 12 часов каждые сутки :) В этом смысле сам Эрланг позволяет писать серверные решения действительно быстро.
Т.е. Дима erlang уже знал или просто знал интуитивно, что лучше начать писать сервернуя часть на erlang'е и вы оба с нуля начали изучать его?
>Пишите, плз, в комментариях к этой статье, о каких особенностях языка хотелось бы узнать более подробно.
OTP Design Principles ;)
OTP Design Principles ;)
Хорошо, я постараюсь написать более подробно про это в следующей статье. Пока можешь почитать по приведенной ссылке документацию Эрланга, там достаточно понятно все написано.
Ну я эрланг ещё давным давно изучил и успел забросить :) Тогда документация была только официальная и больше всего нехватало внятного описания OTP с реальными примерами. Приходилось копать мэйллисты итп, но когда наконец дошли до меня все прелести otp, остальное изучение пошло гораздо проще.
UFO just landed and posted this here
Насколько позволял размер статья более подробно про OTP Design Principles написал во второй статье:
habrahabr.ru/blogs/erlang/51796/
habrahabr.ru/blogs/erlang/51796/
Оч. уважаю erlang за его подход к процессам и параллельности. Кстати, помоему erlang использует не только лёгкие процессы но и системные трэды, не так ли? Иначе ОС не даст одному трэду два ядра сразу.
А, я как раз работаю над проектом (just for fun and aducation) по созданию Scheme VM, и я планирую перенять многие плюсы эрланга, так что у меня тоже будет свой OTP с блэкджэком и шлюхами :)
А, я как раз работаю над проектом (just for fun and aducation) по созданию Scheme VM, и я планирую перенять многие плюсы эрланга, так что у меня тоже будет свой OTP с блэкджэком и шлюхами :)
Если Erlang и использует системные трэды, то это происходит глубоко внутри виртуальной машины и самих программ на Эрланге не касается, то есть эрланговский код от этого никак не меняется сколько бы ядер не было в процессоре. К сожалению про внутреннее устройство виртуальной машины я имею только поверхностное представление.
Удачи вам в создании своей VM!
Удачи вам в создании своей VM!
OTP это не только ценный мех^W^W лёгкие процессы, но и 100-150 мегабайт библиотек, облегчающих разработку проектов.
эрланг запускает планировщик в отдельном ОС трэде на каждое ядро процессора(если конечно не задавать число планировщиков вручную)
Спасибо, интересно, тем более, что сам сейчас понемногу ковыряю его для небольшого серверного приложения.
Было бы интересно взглянуть на работу с сетью.
Было бы интересно взглянуть на работу с сетью.
Я бы еще упомянул про CEAN (по аналогии с перловым CPAN — Comprehensive Erlang Archive Network).
Там как раз и находятся те библиотеки, которых меньше чем в .NET и Си, но в принципе хватит для многих прикладных нужд. Также имеется одноименный модуль — аналог CPAN.pm, rubygems и подобных.
Там как раз и находятся те библиотеки, которых меньше чем в .NET и Си, но в принципе хватит для многих прикладных нужд. Также имеется одноименный модуль — аналог CPAN.pm, rubygems и подобных.
В следующих статьях хотелось бы увидеть портирование какого-нибудь, необязательно сложного, сетевого приложения с любого другого языка. Ну и больше про паттерны поведения OTP (gen_fsm, gen_server), примеры их использования и т.п.
Да, буду писать про OTP в следующей статье. А вот про пример портирования несложного приложения с другого языка, пока ничего написать не смогу, так как пока у меня такого опыта нет. Мы свою систему писали с нуля сразу на Эрланге.
А смысл портирования? Все равно если мы хотим какой-то алгоритм реализовать и на эрланге, то писать код приложения реализующего его придется все равно с нуля.
смысл в том, чтобы показать реализацию одного и тогоже алгоритма разными парадигмами программирования.
поскольку стиль эрланга, как я понимаю, шибко отличается от стиля алголо-подобных языков
поскольку стиль эрланга, как я понимаю, шибко отличается от стиля алголо-подобных языков
Ну почему же с нуля? Я предполагал портирование с эффективным использованием особенностей Эрланга (с применением OTP библиотек, например). Чтобы четко обозначить сравнительные преимущества/недостатки.
Насколько позволял размер статья более подробно про OTP Design Principles написал во второй статье:
habrahabr.ru/blogs/erlang/51796/
Буду еще писать дальше в следующих статьях пример сетевого приложения на Эрланге, но без примера портирования, так в этом не специалист.
habrahabr.ru/blogs/erlang/51796/
Буду еще писать дальше в следующих статьях пример сетевого приложения на Эрланге, но без примера портирования, так в этом не специалист.
Спасибо за наводку. Изучаю, что там есть интересного. Нашел там одну библиотеку для работы с JPEG и PNG. Прикольно, может пригодиться :)
Очень рад, что таки и на хабре появляется больше материалов по данному языку.
Пару соображений по статье. Мне кажется в пример spawn-а не стоило включать макрос. На сколько помню для приема сигналов что бы процесс жил долго нужно делать рекурсию, а из контекста примера это не очень очевидно. Разве нет?
По поводу будующих публикаций. Как я уже упоминал при ознакомлении с тем или иным ПО очень хочеться знать потребляемые ресурсы. Все плюсы могут убить дикие системные требования. Прожорливая система не нужна ни кому.
По амазону кроме чисто технических описаний стоим, имхо, так же и про организацинную сторону не забыть. Через какие системы готовы принять оплату, какие документы можно получить, может есть какие то неочевидные тонкости.
Ну и лично мне кроме материала по Mnesia хотелось бы почитать развернутый материал по сетевому взаимодействию по схеме клиент-сервер. На примере написания простейшего сервера как с обычной отдачей текстовых данных и закрытием соединения, так и стриминг.
P.S. По utf-у кстати в официальной рассылке проскальзыл пост в котором человек писал, что написал модуль работы с utf и Мамут даже испросил этот модуль, но чем все это в итоге закончилось не ясно. Кстати там же предлогали как вариант просто выдернуть кусок кода из функций работы с XML.
Пару соображений по статье. Мне кажется в пример spawn-а не стоило включать макрос. На сколько помню для приема сигналов что бы процесс жил долго нужно делать рекурсию, а из контекста примера это не очень очевидно. Разве нет?
По поводу будующих публикаций. Как я уже упоминал при ознакомлении с тем или иным ПО очень хочеться знать потребляемые ресурсы. Все плюсы могут убить дикие системные требования. Прожорливая система не нужна ни кому.
По амазону кроме чисто технических описаний стоим, имхо, так же и про организацинную сторону не забыть. Через какие системы готовы принять оплату, какие документы можно получить, может есть какие то неочевидные тонкости.
Ну и лично мне кроме материала по Mnesia хотелось бы почитать развернутый материал по сетевому взаимодействию по схеме клиент-сервер. На примере написания простейшего сервера как с обычной отдачей текстовых данных и закрытием соединения, так и стриминг.
P.S. По utf-у кстати в официальной рассылке проскальзыл пост в котором человек писал, что написал модуль работы с utf и Мамут даже испросил этот модуль, но чем все это в итоге закончилось не ясно. Кстати там же предлогали как вариант просто выдернуть кусок кода из функций работы с XML.
Спасибо!
Да, согласен пример со spawn можно было сделать попроще. Но чтобы процесс жил долго можно просто в нем написать receive something -> ok end. и он будет вечно ждать получения сообщения для него :) То есть рекурсия не обязательна.
В статье я как раз привожу конкретные цифры по объему занимаемой памяти и скорость работы процессов. По своему опыту могу точно сказать, что памяти эрланг потребляет мало, тут проблем с ним не будет, но по скорости работы конечно проигрывает и С и часто Java, особенно в интенсивных вычислениях. Но всегда можно написать такой кусок кода на C и просто вызывать его из Эрланга о чем я напишу в следующей статье.
Про Амазон замечания учту: напишу и организационную сторону. Про клиент серверное взаимодействие тоже планирую писать в следующих статьях. С примерами насколько позволит размер статьи.
А с UTF в Эрланге пока глухо, бибилиотеки для нормальной работы с ними написанной на самом же Эрланге я не нашел. Мы лично используем Starling — но он использует библиотеки на C. Нам нужно было преобразование в Upper Case. Конечно просто чтение UTF-строк в эрланге есть, но вот работы с полученными данными потом отсутствует.
Да, согласен пример со spawn можно было сделать попроще. Но чтобы процесс жил долго можно просто в нем написать receive something -> ok end. и он будет вечно ждать получения сообщения для него :) То есть рекурсия не обязательна.
В статье я как раз привожу конкретные цифры по объему занимаемой памяти и скорость работы процессов. По своему опыту могу точно сказать, что памяти эрланг потребляет мало, тут проблем с ним не будет, но по скорости работы конечно проигрывает и С и часто Java, особенно в интенсивных вычислениях. Но всегда можно написать такой кусок кода на C и просто вызывать его из Эрланга о чем я напишу в следующей статье.
Про Амазон замечания учту: напишу и организационную сторону. Про клиент серверное взаимодействие тоже планирую писать в следующих статьях. С примерами насколько позволит размер статьи.
А с UTF в Эрланге пока глухо, бибилиотеки для нормальной работы с ними написанной на самом же Эрланге я не нашел. Мы лично используем Starling — но он использует библиотеки на C. Нам нужно было преобразование в Upper Case. Конечно просто чтение UTF-строк в эрланге есть, но вот работы с полученными данными потом отсутствует.
Написал статью про Амазоновские сервисы, в том числи и про оплату:
habrahabr.ru/blogs/hosting/55058/
habrahabr.ru/blogs/hosting/55058/
спасибо.
очень интересно былобы узнать о новом языке именно на живом примере.
изучать по мануалам одного любопытства не хватает :)
переменные отсутствуют также и в достаточно популярном питоне.
там используется связывание имён с объектами (сами объекты, правда, вполне модифицируемые.)
обычно называется передача аргументов по ссылке. только тут присваивание по ссылке.
но вот пока я не увидел именно формулировку «связывание имён с объектами», оставались недопонятыми и scheme, и xslt :)
при объяснении этой особенности стоит как-то пояснить смысл происходящего.
потомучто для алгол-ориентированных программистов (на которых нас всех учили в школе) переменная — это и есть объект, и если он не изменяем, то вообще ничего не изменяемо.
и, возможно, забегая вперёд.
вот таки эрланг — это строго-функциональный язык?
насколько я понимаю, в строго функциональных языках переменные как таковые не нужны, а достаточно передачи параметров функциям, использующим эти значения.
отсутствие присваивания гарантирует отсутствие побочного эффекта функции, что и позволяет распараллелить всё вообще.
если же все функции без побочных эффектов, то лишено смысла также и скрытое goto в виде последовательного выполнения действий (поскольку результат предыдущего действия не используется). это тоже может немного поломать мозг привыкшим мыслить progn-конструкциями.
очень интересно былобы узнать о новом языке именно на живом примере.
изучать по мануалам одного любопытства не хватает :)
переменные отсутствуют также и в достаточно популярном питоне.
там используется связывание имён с объектами (сами объекты, правда, вполне модифицируемые.)
обычно называется передача аргументов по ссылке. только тут присваивание по ссылке.
но вот пока я не увидел именно формулировку «связывание имён с объектами», оставались недопонятыми и scheme, и xslt :)
при объяснении этой особенности стоит как-то пояснить смысл происходящего.
потомучто для алгол-ориентированных программистов (на которых нас всех учили в школе) переменная — это и есть объект, и если он не изменяем, то вообще ничего не изменяемо.
и, возможно, забегая вперёд.
вот таки эрланг — это строго-функциональный язык?
насколько я понимаю, в строго функциональных языках переменные как таковые не нужны, а достаточно передачи параметров функциям, использующим эти значения.
отсутствие присваивания гарантирует отсутствие побочного эффекта функции, что и позволяет распараллелить всё вообще.
если же все функции без побочных эффектов, то лишено смысла также и скрытое goto в виде последовательного выполнения действий (поскольку результат предыдущего действия не используется). это тоже может немного поломать мозг привыкшим мыслить progn-конструкциями.
эрланг — строго функциональный язык. переменных там нет, там есть лишь промежуточные именованные данные.
присваивания в эрланге нет — есть лишь совпадение по шаблону и если в шаблон входит несвязанная переменная, то она привяжется к кусочку данных соответственно шаблону, например
> A = 1. % переменной А не было, теперь она будет «равна» 1
> B = [1, 2, 3]. % переменная В будет равна списку из трех элементов
> [A, C, D] = B. % шаблон слева совпадает с списком из трех элементов, первым из которых есть А. В C и D соответственно запишутся 2 и 3
> [A, C, C] = B. % ошибка, процесс умрет, так как B не совпадает по шаблону со списком [1, 2, 2]
присваивания в эрланге нет — есть лишь совпадение по шаблону и если в шаблон входит несвязанная переменная, то она привяжется к кусочку данных соответственно шаблону, например
> A = 1. % переменной А не было, теперь она будет «равна» 1
> B = [1, 2, 3]. % переменная В будет равна списку из трех элементов
> [A, C, D] = B. % шаблон слева совпадает с списком из трех элементов, первым из которых есть А. В C и D соответственно запишутся 2 и 3
> [A, C, C] = B. % ошибка, процесс умрет, так как B не совпадает по шаблону со списком [1, 2, 2]
Все же в документации Эрланга и в книге Армстронга они называются переменными, которые могут находится в двух состояниях: связанным и не связанным. Да ходя бы в самом шеле эрланга напиши «A.» и нажми Enter, сообщение об ошибке будет такое: «1: variable 'A' is unbound».
Но с другой стороны по моему спор чисто о терминологии, называть их переменными или промежуточными именованными данными. Я предпочитаю все же называть их переменными :)
P.S. Примеры в твоем комментарии все конечно правильные.
Но с другой стороны по моему спор чисто о терминологии, называть их переменными или промежуточными именованными данными. Я предпочитаю все же называть их переменными :)
P.S. Примеры в твоем комментарии все конечно правильные.
Эрланг — это функциональный язык, но насколько уж строго функциональный не скажу. Я больше практик, чем теоретик. Насколько я знаю, Эрланг писали для практического применения, поэтому синтаксис языка сильно упрощен по сравнению с тем же Lisp и в нем допускаются отклонения от чистой функциональной парадигмы для упрощения написания программ.
Что качается переменных, они все же называются в Эрланге переменными. Можно объявлять новые в функции. Но ничто не мешает в общем-то писать все на вызовах функций и передаче им параметров. Мне больше нравиться использовать переменные, там где это удобно, так как я все же пришел из мира традиционных языков программирования и не использую строго-функциональную стиль программирования :)
Заметьте, использование неизменяемых переменных внутри функции нисколько не мешает распараллеливанию и так же отсутствуют побочные эффекты у функции.
Что качается переменных, они все же называются в Эрланге переменными. Можно объявлять новые в функции. Но ничто не мешает в общем-то писать все на вызовах функций и передаче им параметров. Мне больше нравиться использовать переменные, там где это удобно, так как я все же пришел из мира традиционных языков программирования и не использую строго-функциональную стиль программирования :)
Заметьте, использование неизменяемых переменных внутри функции нисколько не мешает распараллеливанию и так же отсутствуют побочные эффекты у функции.
А может стоит узел называть узлом, а не нодой?
Придерживаюсь терминологии Эрланга: там они называются нодами. К тому же в эрланге есть ряд комад, например: nodes(). — выдать список нод, с которыми связана данная нода. В общем, чтобы не запутаться самому, лучше называть их нодами. Я уже к этому вполне привык :)
Придерживаюсь терминологии Эрланга: там они называются нодами.
Вот прямо так по-русски и называются нодами? ;)
Слово «node» вообще-то именно как «узел» и переводится.
Вы про перевод этого термина на русский! Не сразу понял :) Вообще на русском по моему книг про Эрланг еще нет, поэтому все читал на английском. А так вы правы: «узел» — по русски более правильное понятие.
Я думаю у данного варианта перевода ноги произрастают из XML с его узлами ))
Собственно я когда читал тоже подумал, отчего же не «узел». Но потом подумалось, что узел это в XML-ях, а тут буквальное «нода» вполне подходит, ведь это очень близко к «хосту» для варианта распределенной системы по нескольким компам.
А русскоязычный перевод, видимо, будет таковым, каким его устаканит большая часть русскоязычных разрабов.
Собственно я когда читал тоже подумал, отчего же не «узел». Но потом подумалось, что узел это в XML-ях, а тут буквальное «нода» вполне подходит, ведь это очень близко к «хосту» для варианта распределенной системы по нескольким компам.
А русскоязычный перевод, видимо, будет таковым, каким его устаканит большая часть русскоязычных разрабов.
В терминологии Эрланга происходит обмен между узлами сети
Не знаю, легко ли оценить выигрыш в скорости разработки, но попробуйте. И насколько легко вносит изменения в существующий код?
Я бы сказал очень легко. Я сравниваю со скоростью разработки клиента на C++ и Qt и сервера. Так вот в сервер я вношу изменения раза в 3-5 быстрее, чем в клиента. Я сам сначала удивлялся. Одна из причин: код на Эрланге получается очень компактным по сравнению с C++ изменения обычно вносятся в одном месте, а не в двух-трех местах, как в C++ (я имею ввиду небольшие изменения). Плюс отсутствие строгой типизации переменных часто приводит к тому, что код сервера даже менять не надо, при небольших изменениях на клиенте или в данных обмена между клиентом и сервером.
Сейчас добавление новой функциональности на сервере, например новой команды в API сервера обычно занимает не больше одного дня.
Сейчас добавление новой функциональности на сервере, например новой команды в API сервера обычно занимает не больше одного дня.
В Эрланге можно вносить изменения в работающй код, hot code replace типа :)
А горячее обновление версий вы у себя делали? Чтобы по всем правилам OTP :)
все таки про основы надо больше, как запустить и побавлоаться
Ок, следующую статью целиком посвящу ответам на вопросы в комментариях. Как раз накопилось :) И про это тоже напишу.
Написал про установку Эрланга и первые шаги в своей следующей статье:
habrahabr.ru/blogs/erlang/51796/
Спасибо за вопрос!
habrahabr.ru/blogs/erlang/51796/
Спасибо за вопрос!
Sign up to leave a comment.
Erlang в Рисоваське, часть 1 — обзор языка