Про эрланг vs XXX: интроспекция для отладки
Каждый раз, когда я вижу увлеченные рассказы о технологии N для разработки долгоживущих серверных программ, много работающих с сетью, у меня сразу возникает вопрос: какие механизмы отладки предлагает эта технология
( Read more... )
Ты написал про Cloud Haskell, причем в таком ключе, что «всё, выбрасываем всё остальное». Такие слова очень характерны для гей- хаскель-пропаганды, только вот пишущих про хаскель гораздо больше, чем пишущих на хаскеле =) Веб-запросы сервить - это понятно, там другие проблемы возникают, но уж никак не необходимость отлаживаться без остановки.
Задачи действительно бывают разные. Например, для биржевой системы надо иметь возможность уж если не чиниться на ходу, не отключая людей, то уж хотя бы иметь возможность добавить нового клиента не дожидаясь планового отключения всей системы. Поверь, очень неприятно слышать «подождите до следующей субботы». Статическая типизация тут делу никак не поможет, а вот возможность влезть на ходу в работающую систему и поправить что-то уже работающее там, очень не помешает. Причем, тут JVM или руби тоже позволят подшаманить с данными, а вот скомпилированный код - всё, финита ля комедия.
Так что в следующий раз, рассказывая взахлеб про новую веселую штуку было бы очень неплохо хоть немного обсудить, где она будет к месту.
Reply
Ну все как обычно. TL;DR, всю серию из пяти частей не читал, но осуждаю.
О том, кто и куда вам не смог добавить клиента я ничего не знаю. Но подозреваю, что в любой серьезной системе при возникновении проблемы а) в случае с блокером ее тут же откатывают к стабильной версии б) в случае с не блокером ее чинят в следующем билде. Независимо от того, на Erlang вы пишите или не на Erlang. Разрабатывают на живом, без полного цикла тестирования и тп только наркоманы.
Reply
На самом деле, если Вам из Вашей башни слоновой кости не видно -- весь (это не преувеличение, а факт) бизнес живёт решениями "на живую нитку, а тут щас подпороть и обметать".
Reply
Reply
Reply
Leave a comment