SD>Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, SkyDance, Вы писали:
SD>>
SD>>Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
С другой стороны, я тут с ним не согласен хотя бы потому, что при неустранимой динамической типизации Erlang и очень слабой JIT компиляции (где она вообще есть) Erlang не может быть быстрым.
Из ближайших — Go его побивает на слегка похожем подходе уже в разы даже с учётом его откровенно тухлого кодогенератора.
Ну и единственная входная очередь + head-of-line blocking вносят непредсказуемые задержки, из-за чего я от него везде отказался.
Но если кому эти проблемы не существенны, переполнений входа нет и можно отдавать данные крупными порциями — получается действительно шустро и надёжно, как пример — erlyvideo.
Здравствуйте, Bill Baklushi, Вы писали:
BB>Есть же UDP, RTP, групповые адреса и пр. страшные слова, чтобы не хранить дофига миллионов состояний каждого соединения...
UDP — далеко не всякую схему взаимодействия можно представить в connectionless-модели (а если и можно, то путём переноса этой части сложности с транспортного уровня на прикладной)
RTP — прикладной протокол на основе UDP
групповые адреса — тоже не существуют в вакууме, а требуют исполнения определённых протоколов, плюс нет гарантии на преодоление границ подсетей
Более того, первая виртуальная машина Эрланга была Вирдингом написана на Лиспе. И он же в одно лицо поддерживает (до сих пор!) LFE, Lisp-Flavoured Erlang.
Могучий человечище, очень с ним приятно пообщаться. Не так давно я как раз организовал встречу с ним, отлично прошло.
N>С другой стороны, я тут с ним не согласен хотя бы потому, что при неустранимой динамической типизации Erlang и очень слабой JIT компиляции (где она вообще есть) Erlang не может быть быстрым.
Довольно много сильных заявлений, но все из них верны лишь отчасти (и про типизацию, и про JIT, и про "быстрым").
Эрланг предназначен для concurrency at scale. Он не должен быть быстрым с точки зрения "перекодировки видео". Его задача в другом — дирижировать всеми этими перекодировщиками.
Здравствуйте, SkyDance, Вы писали:
N>>С другой стороны, я тут с ним не согласен хотя бы потому, что при неустранимой динамической типизации Erlang и очень слабой JIT компиляции (где она вообще есть) Erlang не может быть быстрым.
SD>Довольно много сильных заявлений, но все из них верны лишь отчасти (и про типизацию, и про JIT, и про "быстрым"). SD>Эрланг предназначен для concurrency at scale. Он не должен быть быстрым с точки зрения "перекодировки видео". Его задача в другом — дирижировать всеми этими перекодировщиками.
Про перекодировку я ни слова вообще-то не сказал, это уже ваши... мнээээ... догадки я говорил про посылку.
Но при наличии рядом уже заметного количества достойных конкурентов, которые способны обеспечить то же самое по результату, при этом минимально требуя бутербродизации — чем тут Erlang будет сильно лучше?
Ну да, вместо OTP с супервизорами и рестартами — будет какой-то закат солнца вручную, пригодный для местных условий. И обмен сообщениями будет перенесен на какой-то свой движок, который может работать даже поверх мьютексов и условных переменных. А где-то его и не будут использовать, если удобнее без него.
И обратите внимание, что с массовым переходом на rebar/mad (а кто сейчас пакует без них?) успешно похерена самая главная вкусность — обновление на ходу, и всем пофиг — задача перенесена выше, на уровень контейнеров, докеры-шмокеры-куберы.
SD>Рекомендую все того же Роберта Вирдинга (австрал, кстати — из Мельбурна) и его "Pilgrims progress to the promised land", слайды — https://www.slideshare.net/nashjain/pilgrims-progress-to-the-promised-land-by-robert-virding — но еще лучше найти видео.
Когда я работал в Massive Solutions, мы и с ESL общались плотно, и с Вирдингом я лично разговаривал. Не думаю, что он меня помнит, но ESL должны помнить про попытки старта совместных проектов.
Основной наш проект был роскошным, но в результате я не хочу на Erlang больше ничего делать.
N>Про перекодировку я ни слова вообще-то не сказал, это уже ваши... мнээээ... догадки я говорил про посылку.
Вы прямо заявили: "при неустранимой динамической типизации Erlang и очень слабой JIT компиляции (где она вообще есть) Erlang не может быть быстрым."
Для типичных коммуникационных задач Эрланг более чем быстр. В отличие от number crunching и подобных задач, включая ту самую перекодировку.
N>Но при наличии рядом уже заметного количества достойных конкурентов, которые способны обеспечить то же самое по результату, при этом минимально требуя бутербродизации — чем тут Erlang будет сильно лучше?
А вот тем самым, что вы и описали ниже:
N>Ну да, вместо OTP с супервизорами и рестартами — будет какой-то закат солнца вручную, пригодный для местных условий. И обмен сообщениями будет перенесен на какой-то свой движок, который может работать даже поверх мьютексов и условных переменных. А где-то его и не будут использовать, если удобнее без него.
^^^ иными словами, "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang."
Вот ровно так и есть. До того как я начал пользоваться Эрлангом, у меня тоже были закаты солнца вручную, "свои движки" и подобное. Да, оно работало побыстрее, чем аналогичный софт на Эрланге (просто в силу близости к железу), но багов, увы, там было немало.
Короче говоря, можно переизобрести этот велосипед (эрланг) еще 10 раз. Например, akka streams есть не что иное как. И Orleans тоже. И go, и вообще практически весь современный concurrency-oriented софт.
Просто чтобы это понять, нужно потратить очень много времени на изучение сложившейся ситуации. На то, чтобы научиться пользоваться всеми этими инструментами, и иметь возможность их сравнить. У меня такая возможность была. Надо понимать, что Erlang — очень, очень-очень взрослый язык. Даже, пожалуй, старый — поэтому мы и обновляем его (не только виртуальную машину, но и язык тоже). И вот эта самая взрослость — maturity — и позволяет увидеть простую истину: ничто не ново под луной. Новомодним технологиями еще только предстоит тот путь, который Эрланг уже прошел.
N>И обратите внимание, что с массовым переходом на rebar/mad (а кто сейчас пакует без них?) успешно похерена самая главная вкусность — обновление на ходу, и всем пофиг — задача перенесена выше, на уровень контейнеров, докеры-шмокеры-куберы.
Смешались в кучу кони, люди... чем rebar-то помешал? Как раз он-то прекрасно подходит для генерации релизов, и relup-ов. Я как-то даже урок для своих делал, показывающий, как оно работает.
Докеры-шмокеры, это, конечно, прекрасно, но не потому, что у Эрланга что-то не так, а потому, что программистов, которые умеют разрабатывать софт, очень-очень мало, а обезьян много. И обезьянам проще дать контейнеры, чем пытаться из научить понимать фундаментальные принципы.
N>Когда я работал в Massive Solutions, мы и с ESL общались плотно, и с Вирдингом я лично разговаривал. Не думаю, что он меня помнит, но ESL должны помнить про попытки старта совместных проектов. N>Основной наш проект был роскошным, но в результате я не хочу на Erlang больше ничего делать.
Что ж это вы такое начали, что не смогли закончить? Впрочем, ладно, я лучше у Франческо спрошу, раз уж такое дело у него может быть другой взгляд на совместные проекты.
Реальная проблема у Эрланга только одна. Он не для обезьян. Надо понимать, что делаешь, если хочешь написать что-то серьезное. Или, если говорить в терминах менеджмента, "there are staffing issues". Как пример, десяток инженеров могут сделать WhatsApp — потому что это сильные инженеры. Но если брать среднестатистическое, то... даже у сотни не получится. Проще на PHP.
Здравствуйте, SkyDance, Вы писали:
SD>Реальная проблема у Эрланга только одна. Он не для обезьян. Надо понимать, что делаешь, если хочешь написать что-то серьезное. Или, если говорить в терминах менеджмента, "there are staffing issues". Как пример, десяток инженеров могут сделать WhatsApp — потому что это сильные инженеры. Но если брать среднестатистическое, то... даже у сотни не получится. Проще на PHP.
Ну ну, сам себя не похвалишь... но на деле Erlang как раз позволяет понизить требования к разработчикам и при этом получить стабильное но тормознутое сетевое приложение. И таки реальная проблема в динамической сути языка и большой нерасторопности, хотя надо признать, что стабильность решения в купе с понижением требований к инженерам того стоит в 99% случаев.
KP>Ну ну, сам себя не похвалишь... но на деле Erlang как раз позволяет понизить требования к разработчикам и при этом получить стабильное но тормознутое сетевое приложение. И таки реальная проблема в динамической сути языка и большой нерасторопности, хотя надо признать, что стабильность решения в купе с понижением требований к инженерам того стоит в 99% случаев.
Думаю, на этом стоит остановить дискуссию, ибо мы явно подходим к проблеме с разных сторон. У меня статистика на большом количестве разработчиков, которые по среднемировым стандартам весьма сильны. А также очень хорошая видимость во множество других компаний. Иными словами, я хорошо знаю ситуацию, и те проблемы, с которыми сталкиваются реальные проекты.
Поэтому я отлично вижу, что процитированные выше заявления далеки от реальности. И про тормознутость, и про стабильность, и про динамическую типизацию, и про нерасторопность. Но чтобы обсудить это предметно, следует рассмотреть конкретные применения, а не общие высказывания про "сетевые приложения".
Здравствуйте, SkyDance, Вы писали:
SD>Думаю, на этом стоит остановить дискуссию, ибо мы явно подходим к проблеме с разных сторон. У меня статистика на большом количестве разработчиков, которые по среднемировым стандартам весьма сильны. А также очень хорошая видимость во множество других компаний. Иными словами, я хорошо знаю ситуацию, и те проблемы, с которыми сталкиваются реальные проекты.
Очень спорное утверждение, так как принципы отбора в компании типа FB давно известны, там не самые сильные, а самые упорные. Ну а если говорить про видимость использования в других компаниях то видишь ты исключительно BEAM-решения и явно у тех, у кого они хорошо взлетели, т.к. остальные просто отказались в пользу чего-то еще и ты с ними даже не пересекался.
SD>Поэтому я отлично вижу, что процитированные выше заявления далеки от реальности. И про тормознутость, и про стабильность, и про динамическую типизацию, и про нерасторопность. Но чтобы обсудить это предметно, следует рассмотреть конкретные применения, а не общие высказывания про "сетевые приложения".
Складывается ощущение, что ты видишь исключительно то, что хочешь видеть. При этом я вроде выше сказал, что BEAM — это круто очень для подавляющего большинства сетевых серверных приложений.
Здравствуйте, SkyDance, Вы писали:
N>>Про перекодировку я ни слова вообще-то не сказал, это уже ваши... мнээээ... догадки я говорил про посылку. SD>Вы прямо заявили: "при неустранимой динамической типизации Erlang и очень слабой JIT компиляции (где она вообще есть) Erlang не может быть быстрым."
Да.
SD>Для типичных коммуникационных задач Эрланг более чем быстр. В отличие от number crunching и подобных задач, включая ту самую перекодировку.
Ну то есть вы хотите сказать, что при I/O bound задачах его тормоза обычно незаметны. OK, в такой постановке — согласен. С уточнением для этого "обычно", что банально впасть (как было у нас) именно в тот вариант использования, когда они из незаметных превращаются в фатальные.
N>>Ну да, вместо OTP с супервизорами и рестартами — будет какой-то закат солнца вручную, пригодный для местных условий. И обмен сообщениями будет перенесен на какой-то свой движок, который может работать даже поверх мьютексов и условных переменных. А где-то его и не будут использовать, если удобнее без него.
SD>^^^ иными словами, "Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang." SD>Вот ровно так и есть. До того как я начал пользоваться Эрлангом, у меня тоже были закаты солнца вручную, "свои движки" и подобное. Да, оно работало побыстрее, чем аналогичный софт на Эрланге (просто в силу близости к железу), но багов, увы, там было немало.
Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее.
Или таки скоро завезут сильный JIT (а не убогий HiPE)?
SD>Короче говоря, можно переизобрести этот велосипед (эрланг) еще 10 раз. Например, akka streams есть не что иное как. И Orleans тоже. И go, и вообще практически весь современный concurrency-oriented софт.
Да. Только надо перестать смотреть на это как на "переизобретение эрланга". Даже если Erlang был одно время образцом, то все эти реализации уже давно ушли дальше.
SD>Просто чтобы это понять, нужно потратить очень много времени на изучение сложившейся ситуации. На то, чтобы научиться пользоваться всеми этими инструментами, и иметь возможность их сравнить. У меня такая возможность была. Надо понимать, что Erlang — очень, очень-очень взрослый язык. Даже, пожалуй, старый — поэтому мы и обновляем его (не только виртуальную машину, но и язык тоже).
OK, когда будут множественные входные очереди на процесс?
SD> И вот эта самая взрослость — maturity — и позволяет увидеть простую истину: ничто не ново под луной. Новомодним технологиями еще только предстоит тот путь, который Эрланг уже прошел.
А им просто не надо его проходить. У них другая специфика, и повторять ошибки Эрланга им не с руки.
SD>Смешались в кучу кони, люди... чем rebar-то помешал? Как раз он-то прекрасно подходит для генерации релизов, и relup-ов. Я как-то даже урок для своих делал, показывающий, как оно работает.
С какой версии это стало нормально работать? Я после 2015 не смотрел, до этого коллеги пробовали — не работало.
N>>Основной наш проект был роскошным, но в результате я не хочу на Erlang больше ничего делать. SD>Что ж это вы такое начали, что не смогли закончить? Впрочем, ладно, я лучше у Франческо спрошу, раз уж такое дело у него может быть другой взгляд на совместные проекты.
Основное было системой мониторинга кластера "Ломоносов". Её у нас забрали прямо в процессе затыкания этих проблем, так что я после 2013 там не участвую аж никак. Франческо вряд ли в курсе, с ESL мы не подружились независимо от того проекта.
SD>Реальная проблема у Эрланга только одна. Он не для обезьян. Надо понимать, что делаешь, если хочешь написать что-то серьезное.
Это роскошная отмазка для любого... мнэээ... некачественного продукта, но проблема в том, что она настолько заезжена, что сейчас одно её упоминание обычно сразу снижает восприятие качества обсуждаемой вещи
А тут она ещё и грубо неверна. Когда проект начинался, мы взяли в контору группу военных админов(!) и они успешно за срок менее месяца переключились на проектирование и написание (при том, что часть ещё и не имела опыта программирования кроме одноэкранных скриптов баша) — и всё шло замечательно до тех пор, пока под реальной нагрузкой не начались уже характерно эрланговые проблемы, как минимум:
1) Переполнение входных очередей без возможности адекватного взаимодействия с пострадавшими процессами; лечилось грубыми хаками типа просовывания управляющих команд через ETS с соседним процессом;
2) Страшно тормозной global, с синхронизацией, страдающей при перегрузке (попросту кластер рассыпался — и это при несчастных ~30 узлах); сейчас, по слухам, есть настройка "межкластерные данные идут по другим каналам, чем heartbeats", я не успел это сделать — выдернули на живую.
Были и другие, поменьше, но облом вспоминать (попросишь — подниму архивы).
Эти проблемы я обсуждал с Валкиным, Лапшиным, Димандтом, с теми ребятами, которые делали Erlang как Xen guest (не помню фамилий) — узок наш круг и все согласны с их наличием, но они просто обошли те задачи, на которых эти проблемы давали максимальный эффект, а наша фирма встретилась с ними по полной.
Понимаешь, почему мне теперь твои рассказы про "надо уметь готовить" вызывают просто ржач? Меня не надо учить его готовить, я его пять лет готовил, и командой рулил. И именно поэтому я знаю, что есть проблемы, которые элементарно бы решились (расширив его области применения в разы), но из-за дуболомства разработчиков языка они тупо отвергнуты. Множественные входные очереди — для меня сейчас ключевой критерий, лакмусовая бумажка. И главное, сделать-то их банально (с их силами) — надо только признать реальность. Поэтому: сделают их — начну смотреть и всерьёз предполагать применение хотя бы в тех областях, где мне что-то подобное нужно. Не сделают — к чёрту старперов, есть много других современных альтернатив без таких диверсий, а Erlang будет продолжать уверенно терять позиции.
(Ну а по современному состоянию ситуация ещё хуже: линейный рост мощности процессоров почти остановился, паралельность у программистов до сих пор зачаточная, RAM не дешевеет с 2012, аппетиты растут... средство, которое не умеет эффективно компилироваться, скоро пойдёт на обочину даже в тех областях, где Erlang был силён. Сейчас я для проекта из его типовой ниши скорее выберу Go, если пересилю тошноту. Ну или ещё альтернатив регулярно подвозят.)
SD> Или, если говорить в терминах менеджмента, "there are staffing issues". Как пример, десяток инженеров могут сделать WhatsApp — потому что это сильные инженеры. Но если брать среднестатистическое, то... даже у сотни не получится. Проще на PHP.
Ну вот пока вы так будете думать — у вас и будет 1-2 потребителя из тех, кто смог набрать "сильных инженеров", которые к тому почему-то согласились работать с намеренно самосостарившимся средством. Хотите развития — делайте, чтобы написать и запустить мог простой школьник. Даже если 1 из 1000 потом заинтересуется — уже приток сил. Впрочем, как хотите, мне уже пофиг
N>Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее.
Я так понимаю, "принципиальная тормознутость" рассматривается ниже (с конкретными проблемами). Или есть еще что-то еще? Кроме заявлений про "тормознутость", чтобы было нечто осмысленное. А то я вижу, что "тормознутость" — это 50.000 юзеров на машину в кластере (средней руки мессенджер на жаве) и 500.000 на такую же машину (на Эрланге).
N>Да. Только надо перестать смотреть на это как на "переизобретение эрланга". Даже если Erlang был одно время образцом, то все эти реализации уже давно ушли дальше.
Это и есть переизобретение эрланга. "Эти реализации" ушли не дальше, а в болото. Как туда уходит любой мейнстрим, см. Жава, С++.
N>OK, когда будут множественные входные очереди на процесс?
Сначала нужно объяснить, зачем. Один из патчей, который я сделал, как раз подобная поддержка (в слегка упрощенном виде, т.н. prepend send, послать сообщение в голову очереди). Но чем больше я занимаюсь архитектурой и более серьезным пониманием происходящих процессов, тем больше я понимаю, как был неправ. Просто на тот момент, когда я это сделал, у меня не было достаточно знаний. Сейчас эти знания есть, и я понимаю, что и prepend send, и "множественные очереди", и priority queues — это ошибочные направления. Но, повторюсь, чтобы это понять, нужно действительно провести много времени за изучением этих проблем.
N>А им просто не надо его проходить. У них другая специфика, и повторять ошибки Эрланга им не с руки.
Ошибка эрланга в том, что он очень долго был внутренним продуктом эрикссон. Его следовало опен-сорснуть лет на 15 раньше.
N>С какой версии это стало нормально работать? Я после 2015 не смотрел, до этого коллеги пробовали — не работало.
В следующий раз посоветуй коллегам разобраться. Оно работало всегда. Могло не хватать каких-то инструментов для удобства. Но systools были еще с 90х годов.
N>Основное было системой мониторинга кластера "Ломоносов". Её у нас забрали прямо в процессе затыкания этих проблем
Вот в это я могу поверить — что в силу политических причин ("забрали проект") у кого-то образовалось неприятие к инструментам, которыми попросту не научились пользоваться.
N>А тут она ещё и грубо неверна. Когда проект начинался, мы взяли в контору группу военных админов(!) и они успешно за срок менее месяца переключились на проектирование и написание (при том, что часть ещё и не имела опыта программирования кроме одноэкранных скриптов баша) — и всё шло замечательно до тех пор, пока под реальной нагрузкой не начались уже характерно эрланговые проблемы, как минимум:
Прям-таки классика жанра! Когда я написал "нельзя набрать обезьян" — я ровно это и имел в виду. Дело в том, что синтаксис и "первые шаги" на Эрланге до одури просты. И потому возникает ощущение "мы все поняли и все умеем". Но когда дело доходит до написания реального софта, оказывается, что кроме синтаксиса нужно еще... понять, что такое OTP, и как на самом деле надо пользоваться языком. Вы, однако, так и не поняли. Посему и проблемы, перечисленые ниже. Как раз отражение непонимания, как должна работать система.
N>1) Переполнение входных очередей без возможности адекватного взаимодействия с пострадавшими процессами; лечилось грубыми хаками типа просовывания управляющих команд через ETS с соседним процессом;
Иными словами, не смогли правильно реализовать backpressure. Справедливости ради, это действительно holy grail асинхронного программирования, и по сути нормально нигде и не реализовано. Да, есть теоретические измышления (SEDA та же) и кое-какие реализации (а ля GenStage), но чтоб серьезно к этому делу подойти, — пока руки не дошли. На данный момент все в стадии написания whitepaper.
N>2) Страшно тормозной global, с синхронизацией, страдающей при перегрузке (попросту кластер рассыпался — и это при несчастных ~30 узлах); сейчас, по слухам, есть настройка "межкластерные данные идут по другим каналам, чем heartbeats", я не успел это сделать — выдернули на живую.
Сейчас global попросту не нужен (как он не был нужен и раньше). Если нужны process groups, они уже есть (и нет, не pg2, которые работали поверх global). В общем, то, что вы не смогли кластер из 30+ машин поднять, так я про то и пишу — надо было разработчиков высокой квалификации брать. Тогда и 20.000 машин в кластере не были бы проблемой, и даже 30.000 (больше просто пока не требовалось).
N>Были и другие, поменьше, но облом вспоминать (попросишь — подниму архивы).
Нет смысла. Я уже понимаю, что не тот уровень знаний.
N>Эти проблемы я обсуждал с Валкиным, Лапшиным, Димандтом
А надо было обсуждать с Lukas Larsson, Kenneth Lundin, Rickard Green, Sverker Eriksson, Kjell Winnblad. Круг, действительно, узок, и он не включает ни одной из указанных выше фамилий.
N>Понимаешь, почему мне теперь твои рассказы про "надо уметь готовить" вызывают просто ржач? Меня не надо учить его готовить, я его пять лет готовил, и командой рулил.
Понимаешь теперь, что его действительно нужно просто уметь готовить? И тогда получается WhatsApp. Где я как раз его и готовлю. И рулю не одной командой.
Здравствуйте, SkyDance, Вы писали:
SD>Прям-таки классика жанра! Когда я написал "нельзя набрать обезьян" — я ровно это и имел в виду. Дело в том, что синтаксис и "первые шаги" на Эрланге до одури просты. И потому возникает ощущение "мы все поняли и все умеем". Но когда дело доходит до написания реального софта, оказывается, что кроме синтаксиса нужно еще... понять, что такое OTP, и как на самом деле надо пользоваться языком. Вы, однако, так и не поняли. Посему и проблемы, перечисленые ниже. Как раз отражение непонимания, как должна работать система.
Это просто потрясающе, насколько вы сделали выводы безо всякой на то причины. Начнём просто с факта, что именно эти коллеги, которых вы тут походя назвали обезьянами, делали много полезных вещей, но именно к описанным проблемам они имеют минимальное отношение.
А сейчас я настаиваю, чтобы вы извинились за оскорбление в их адрес. Только после этого будет возможна какая-то дискуссия по сути, а пока этого нет — я буду считать, что и все ваши (якобы) технические аргументы — не стоят рассмотрения по причине вашего верхоглядства.
SD>И тогда получается WhatsApp
хм.. как-будто вацап это что-то хорошее, а не кусок говна, который даже нельзя на нескольких машинах использовать ¯\_(ツ)_/¯
Здравствуйте, netch80, Вы писали:
N>Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее. N>Или таки скоро завезут сильный JIT (а не убогий HiPE)?
Имхо, нормальный JIT нигде не завезли и никуда не завезут. Все успешные рантаймы идут на дикие компромисы, при чем стратегию "долго запрягаем — быстро едем" — они не только не способны обеспечить, но и часто искусственно отвергают.
Add: Прошу прощения, за то что ворвался. Ну просто такое вот наблюдение по жизни. В добавок из того очень малого, что я воочию видел в erlang — это то,что он мог очень хорошо распарралелить задачу (под это написанную), но выхлоп... эх. Мой наивный код сделал его раза так в 4, на весьма скромном железе. Да, я понимаю,что лумать так не правильно, но я с тех пор считаю вот его ущербцем. Для клеевых целей возможно он и годиться, но античеловечный язык, имхо, — это двести камней против и никакие JIT нп помогут. Именно, что называется — нишевой. Это не плохо, но... нишевые GP решениянравятся как-то больше тупо синидиотически.
Здравствуйте, SkyDance, Вы писали:
KP>>BEAM реально творит чудеса в вопросах разработки сетевых приложений.
SD>никаких чудес, просто грамотное использование kqueue/epoll. Но да, читать этот код ох непросто, и вот сейчас как раз epoll-related баг выносит мне мозг капитально.
N>Это просто потрясающе, насколько вы сделали выводы безо всякой на то причины. Начнём просто с факта, что именно эти коллеги, которых вы тут походя назвали обезьянами, делали много полезных вещей, но именно к описанным проблемам они имеют минимальное отношение.
Признаю, что потерял навыки обращения с языком, и сформулировал утверждение в очень кривой форме. Ни в коем разе не хотел назвать ваших коллег обезьянами.
Однако продолжаю утверждать, что из-за очень простого синтаксиса начальная стадия изучения Эрланга ведет к совершенно неверному понимаю сути языка и проблем, которые он решает. Иными словами, кажется, что "уже вот все понял и освоил". Многие начинают после этого писать очередной "worker pool" или что-то еще подобное на эрланге, и, конечно, встречаются с озвученными вами выше проблемами. Но происходит все это лишь оттого, что реального понимания языка и его предметной области нет совсем. Кривая обучения очень нелинейна: понять синтаксис легко, но дальше кажется что "все неправильно". Потому что очень непривычно, нужно ломать стереотипы и представления о том, как и что должно работать. Вот через вторую стадию большинство, по моему опыту, пройти не могут. И они пытаются продолжать переизобретать С++ на эрланге. После чего, естественно, у них и язык виноват, и медленный он, и вообще все не так.
MA> Мой наивный код сделал его раза так в 4, на весьма скромном железе.
Ровно что я и написал. Мой наивный код на С всегда был быстрее аналогичного на эрланге.
Просто потому, что код... наивный. И попросту не делает все то, что еще за него делает OTP (не сам эрланг, а платформа).
Здравствуйте, SkyDance, Вы писали:
SD>Ровно что я и написал. Мой наивный код на С всегда был быстрее аналогичного на эрланге. SD>Просто потому, что код... наивный. И попросту не делает все то, что еще за него делает OTP (не сам эрланг, а платформа).
Нет, я описал ровно свой около нулевой опыт в эрланг, а так же приблизительно говорю свои свои чувства, почему я не буду на него смотреть в принципе.
netch80 пишет несколько иное, и я как бы склоняюсь на его сторону, не сколько потому что ему сверх сильно доверяю (хотя этот человек, в отличии от меня херни не пишет) — просто, для себя не вижу в нем смысла (в эрланге, в netch80 смысл то как раз есть, кто еще разъяснит такие вещи о которых и не подумаешь?).
Тут же на этом форуме, были и весьма смешанные отзывы об этом всем, хотя и не плохие. Я б позвал человека, вы все его знаете, но он вроде вышел из форума не так давно.
От души могу добавить только то,что любому человеку который скажет что в каждой ... программе есть часть лиспа — готов не только плюнуть в рожу, но и больно ударить в нос. Потому что это бредятина сивой кобыли и слезные мечтания.
Я ваш лисп наблюдал в ныне процветающих CAD системах и ничего кроме как сказать, что это полное уебище — просто невозможно.
Но конечно, всегда найдутся альтернатмвно мыслящие которые найдут в этом хоть каплю хорошего. А что долдно быть им не ведомо.
А я вот знаю точно — ни лиспу ни эрлангу в современном мире места нет. Доживают, не иначе.
Add: А если ты не GP язык — то заявить как бы и нечего. И дело даже не в обезьянах... Просто, каждый язык и область требует своего погружения. Где-то рядом в темах мне наверное не верят, что люди выжимают из выровненных указателей. На кой оно надо? Где это вообще возможно? Зачем? Но, я вот нашел ответы для себя на эти вопросы. Зачем ерланг, раст, го или еще какая люси — мне неведомо. Да, список просто наугад взят. Вся популярность раста растет не из за его ебанутой прости господи модели, а то что серво+мозилла. Так то он язычок был и есть так себе. Тоже самое с го без гугла — никто б и не взглянул. Так и ты с эрлангом, но это просто нишевое решение. За пределами своей ниши обитают только обезьяны, и хотя это видимо должно многим людям быть обидно, просвященный человек в 2020 году знает что теория эволюции Дарвина относительно человека весьма туманна, а большинство находок начала прошлого столетия — подделки. Шило в мешке не утоишь.
— из Мельбурна) и его "Pilgrims progress to the promised land", слайды — https://www.slideshare.net/nashjain/pilgrims-progress-to-the-promised-land-by-robert-virding — но еще лучше найти видео.
