выбор языков

Go.

/thread

что вы так цепляетесь к слову производительность и скорость работы, будно вы пишете прогу для шатла или калайдера, где 0,25с ой как большая задержка. можно говнокодить и на асме, что тупить еще хлеще будет

0,25с ой как большая задержка.

Чтоб у тебя видеоплеер выдавал задержки по 250 миллисекунд.

При загрузке или воспроизведении? :)

Личный опыт.

Расскажу один случай (связанный как раз с Erlang-ом). Вдруг, ни с того, ни с сего, некий сервис X начинает падать. Просто так. Код сервиса X не менялся уже полгода. Расстановка отладочной печати даёт странную картину: сервис падает в разных местах. Причём ладно бы там были какие-то ветвления; падает в одной ветке — но в произвольном месте.

Что оказалось. Был некий сервис Y, написанный при помощи behaviour-а gen_server и отвечавший на запросы, посылаемые через gen_server:cast. Причём состояния у этого сервиса по сути не было: он просто передавал запросы другим, а сам служил разве что для синхронизации. Но был этот сервис написан чуть-чуть криво: вместо {noreply, []} возвращал {ok, []}.

Что происходит, если handle_cast возвращает значение неподходящего типа? Правильно, код gen_server не может его обработать — и падает. Но этот сервис сидит под супервизором, и супервизор его рестартует. Конечно, рестартует он его в исходное состояние — но штука в том, что никакого другого состояния и не было. Поэтому сервис снова поднимается — до следующего запроса. Запросы шли не слишком часто, и, если не считать строчки в логах (а логов ОЧЕНЬ много, и читать всё подряд невозможно, особенно если система работает) эффект такой, как если бы сервис работал правильно.

В определённый момент код, к которому обращался Y, немножко пооптимизировали. Сервис стал работать быстрее. И падать, соответственно, тоже быстрее. Точнее, чаще. У супервизоров в OTP есть лимит — насколько часто его «ребёнок» может падать. Когда запросы к Y пришли пачкой, этот лимит оказался перейдён. Супервизор послал всех на хрен, убил всех своих детей и самоубился сам.

Ну и, одним из этих детей оказался X. Который, соответственно, был грубо убит.

Если бы код был статически типизирован — Y просто не скомпилировался бы. Если бы не идеология let it fail — мы узнали бы о происходящем при первом падении Y. А так мы узнали, когда эта хрень застопорила весь продакшен.

Лет через пять будет приблизительно тоже самое что и было лет пять назад, тоесть то что есть сейчас.

А вы с какой целью интерисуетесь ? Чисто как хобби, или в академическом плане, ну или просто в плане зарабатывания денег?

Rust, фронтэнд на честном JS, чтобы не возникало желания переносить на него бизнес-логику.

Стратегия супервизора настраивается, перезапуск gen_server это почти всегда ненормальная ситуация.

Кстати, там обычно (вроде - не помню точно) 2-3 перезапуска и потом привет, а это достижимо быстро. Соответственно как оно вообще работало :)

Let it crash - хорошая отдушина для недоработок, можно понадеяться на супервизор и он честно отработает.

Эта фича в первую очередь нужна при разработке, отладке и наконец перезапуске каких-то второстепенных процессов. Если падает драйвер мускула (что довольно типично) и перезапускается, это в итоге скажется на невозможности выполнить задачу, повлекшую данный эксцесс, но остальные будут думать «all good», если конечно там нет постоянных коннектов.

Если происходит перезапуск, то такие состояния как правило нужно обрабатывать либо как-то уведомлять ибо нештатная ситуация.

По поводу статический типизации, всё хорошо сказано тут:

http://s9.postimg.org/4iyjxhevz/explict.png

По поводу статический типизации, всё хорошо сказано тут:
http://s9.postimg.org/4iyjxhevz/explict.png

Здесь сказано только про устаревшую версию C++, где до недавнего времени приходилось везде указывать типы.

Если бы код был статически типизирован — Y просто не скомпилировался бы. Если бы не идеология let it fail — мы узнали бы о происходящем при первом падении Y. А так мы узнали, когда эта хрень застопорила весь продакшен.

Т.е. у вас не было функционального и регрессионного тестирования, поэтому ошибка прошла незамеченной? Без покрытия тестами в продукте багов будет много вне зависимости от языка.

между выводом половинок кадра - при тринге

т.е. если в статически типизированном языке надо покрывать 100%, то в динамических языках никак меньше 146% нельзя?

Не вижу логики.

ну какже надо покрывать тестами еще и те случаи которые бы проверил компилятор при компиляции

ну какже надо покрывать тестами еще и те случаи которые бы проверил компилятор при компиляции

Что он проверил?

Итак дети, начинаем нашу лекцию про систему типов...

но так как вы нихрена мне не заплатили то я буду лишь задавать вопросы, итак:

- что вы знаете о систем типов в языках с классическим ООП (Class-based)

- если вы все это знаете зачем спрашиваете у меня?

Чтобы глупости слушать, ещё и платить надо?

Да нет же, ты мне их вот бесплатно рассказываешь.

Вот смотрю на сайт Ирины, а там какой-то веб 1.0.

Дык пацаны делом заняты, вместо того, чтобы марафеты наводить. Оно языку программирования и не нужно.

Коммьюнити, общающееся в почтовых рассылках.

Прекрасная форма общения (+ IRC ещё). NetBSD так живёт и прекрасно себя чувствует. Да как и почти любой другой устоявшийся проект. А как ещё-то? В паблике на фейсбуке? В твиттере?

Т.е. у вас не было функционального и регрессионного тестирования, поэтому ошибка прошла незамеченной?

Как ты докажешь, что код не падает для любых входных данных?

Формальная верификация?

Т.е. у вас не было функционального и регрессионного тестирования, поэтому ошибка прошла незамеченной? Без покрытия тестами в продукте багов будет много вне зависимости от языка.

Тесты, разумеется, были. Ошибка прошла сквозь них. Ибо пока не прибавили скорости — всё ДЕЙСТВИТЕЛЬНО работало как надо.

Формальная верификация?

В рамках динамически типизированного языка?

Как ты докажешь, что код не падает для любых входных данных?

У большого продукта накапливается очень много тестов, через которые тривиальному багу пройти сложно. Обычно пробирается что-то, связанное с продолжительным аптаймом, для чего обычного двухнедельного цикла тестирования мало.

Тесты, разумеется, были. Ошибка прошла сквозь них. Ибо пока не прибавили скорости — всё ДЕЙСТВИТЕЛЬНО работало как надо.

Т.е. нагрузочного тестирования не было? :)

Я не отрицаю, что ошибки могут быть, просто по своему опыту их столько даже близко не было, сколько статически типизированные оракулы предрекают. Подавляющая масса косяков была тупо в реализации логики или даже в качестве модели.

Просто сейчас вот как получается, на словах-то мы все инноваторы, а на работе пишем на Java, C++ и JS.

Я на работе последнее время пишу в основном на clojure и clojurescript =)

Ну и, конечно, приходится работать иногда с java, scala, python и js)

Если нравится Ocaml, то я бы еще посмотрел на F#. В свете последних инициатив микрософта, F# может быть интересен и на юниксах. Замечу, что как язык F# лично мне нравится больше.

Все очень просто. Erlang используй для написания сетевых сервисов. Для всего другого хорошо подходит C. Scala, Clojure, Java и тд, бяка, потому что под Jvm

Было, конечно. Но продакшен-сервера побыстрее. Это их и сгубило.

И ты, похоже, почему-то считаешь, что ошибки упомянутых тобой классов ну никак не могут быть ошибками типизации. Это неверно.

Erlang хорош одним — remsh. Это, конечно, круто.

Для сетевых сервисов Haskell даже лучше. Хотя бы потому, что Haskell компилится в натив, а Erlang — в BEAM.

Дык пацаны делом заняты, вместо того, чтобы марафеты наводить. Оно языку программирования и не нужно.

поэтому вот у успешных мейнстрим языков нормальные сайты с нормальными документациями, а у таких вот эзотерических языков с охватом 0.01% сайты говно из 90х?

Для сетевых сервисов Haskell даже лучше. Хотя бы потому, что Haskell компилится в натив, а Erlang — в BEAM.

а что мешает использовать в erlang'e native там, где это нужно? Вот например, для unix domain sockets я так и сделал - драйвер + beam с scheduler friendly polling. в итоге при стресс-тестировании erlang-версия всего на 100-150 мс медленнее написанной на С (~2500мс против ~2600). теперь смотрим на хаскелл и понимаем что для сетевых сервисов он не нужен ибо BEAM + немного C «рвут» его по производительности и масштабируемости.

Erlang хорош одним — remsh. Это, конечно, круто.

Осталось выяснить, что в нём не круто.

Вот смотрю на сайт Ирины, а там какой-то веб 1.0. То есть люди не позаботились даже чтобы потратить день работы дизайнера. Коммьюнити, общающееся в почтовых рассылках. Не то чтобы фейл, но звоночек - встречают по одежке. И как логичный результат — в массах его никто не знает, совсем. Короче, в народ эти люди не стремятся, на «язык будущего» он не годится.

А по мне, лёгкий сайт а-ля веб 1.0 и почтовые рассылки — это просто прекрасно!

поэтому вот у успешных мейнстрим языков нормальные сайты с нормальными документациями, а у таких вот эзотерических языков с охватом 0.01% сайты говно из 90х?

чего тебе не хватает в документации по OCaml'у?

ему надо чтобы при чтении доков все вокруг свистело и пердело. как же читать API по Async'у если тебе на js'e не вылазит банер «мокрые письки смотреть онлайн»?

Им нужно в силу ЦА. И, да, «успешный мейнстримный» не значит «хороший»

Java

а по мне так значит, мейнстримовый значит успешный, а какой бы ты хороший не был это не делает тебя нужным, так развлечение для маргиналов.

а по мне так значит, мейнстримовый значит успешный, а какой бы ты хороший не был это не делает тебя нужным, так развлечение для маргиналов.

Но зачем себя мучить и писать на чем-то плохом, когда можно писать на хорошем?

Scala.

Сайтик посвежее https://ocaml.org/

да, знаю. Кстати, оцени чисто лоровский юмор: секция Install OCaml начинается словами: «use a package manager supported by your platform (Windows, Linux, Mac OS X, ...)»