В принципе, одного только факта зависимости от Electron достаточно для того, чтобы отбить всякое желание с ним связываться. Ну любим мы native look & feel, и не любим хипстерские «аппы».
Серьезно, это реальная ситуация из жизни. Хостер изначально, как это в подобных случаях водится, занял позицию «не знаю я ни про какой malloc, это Ваш софт кривой», но после некоторых препирательств что-то сделал, после чего это проблема на некоторое время перестала воспроизводиться. Когда через некоторое время это случилось опять, то мы плюнули на все и переехали на dedicated.
Отсюда вывод — для высоконагруженных и/или business-critical проектов необходимо использовать dedicated-сервера. Тогда и никаких «в htop-е все по нулям, но почему-то все равно все равно тормозит, а в техподдержке хостера сказали, что во всем виноват Ваш софт» или «у нас куча свободной оперативки, но почему-то malloc всегда выдает NULL».
Правда, как-то раз мне попался хостер, который майнил Monero на серверах клиентов (от чего опять же все тормозило), но здесь это скорее исключение, чем правило :)
Правильнее было бы сказать, что flatMap — это определение операции bind для монады List. Для, скажем, IO bind это выполнение этой самой IO-операции. Для Maybe — функция, всегда возвращающая Nothing, если результат вычисления выражения 1-го аргумента bind тоже Nothing, и результат вычисления фунции, переданной в качестве 2-го аргумента bind в противоположном случае. И т. д., и т. п.
Да там одни runtime-ошибки из-за пропусков при pattern matching чего стоят :) Про OOM из-за неотработавшей оптимизации хвостовой рекурсии я, пожалуй, промолчу — нельзя считать инструмент, провоцирующий подобные ошибки надежным и/или безопасным даже в первом приближении.
Основная сложность функционального программирования главным образом заключается в стремлении своих адептов рассказывать максимально сложно даже про весьма простые вещи. Почему и за счет каких поведенческих механизмов так происходит — отличная пища для размышления.
Спасибо за увлекательную статью. Никогда не играл в XBox, но всегда приятно читать о победах над (так сказать) не сильно хорошими людьми, которые считают, что пользователь не имеет права контролировать свое собственное железо.
В то же время Linux — это чуть ли ни единственная относительно мейнстримная платформа, позволяющая в случае необходимости редактировать, менять и собирать обратно свои части без особого ущерба для психики. Да и полноценный терминал с удобными и мощными UNIX-утилитами, без которых я как без рук здесь есть нативная сущность, а не нечто прикрученное сбоку.
Каких-то критичных проблем за последние 10 лет я не припомню. Впрочем, я и не знаю, что там у сферических домохозяек в вакууме.
Люди давно придумали законы. Их количество растёт вместе со сложностью устройства экономики и социальной сферы. Но принятие законов имеет определённую процедуру, общество выдаёт мандат на право менять законы для себя.
В данном случае было бы достаточно в зачатке задавить демпингистов на уровне ФАС в рамках существующих законов. Почему этого не произошло — повод для отдельного размышления.
В данном случае эта аналогия малоуместна. Относительно консервативная медицинская область вполне себе неплохо ложится на парадигму высшего образования — что куда сложнее сказать про информационные технологии.
Ну конкретно по моему опыту так очень хорошо себя зарекомендовал такой подход, как:
1. Получаем бизнес требования
2. Проводим первичную разработку занимая технический долг при необходимости, попутно собирая требования к будущей архитектуре
3. Проводим рефакторинг
Как показывает практика, при хоть сколь-либо грамотном управлении техническим долгом убыток от его обслуживания на шаге 3 во много раз меньше, чем ущерб от формирования архитектуры с пока еще малопонятными требованиями и её дальнейшей поддержки. Хотя пацанам, конечно, такое и действительно не покажешь.
Сталкивался с похожей ситуацией в Томске в 2010-м. Но в итоге те же люди заселили нас в значительно более просторную квартиру по цене явно ниже рыночной (хоть и немного выше, чем та, где были «проблемы с водой»), в которой мы спокойно и прожили всей компанией с 21-го по 23-е августа :)
Все верно — просто пользователи-неайтишники и не знают, почему это их любимый IM стал жрать оперативную память аки браузер и тормозить. А это вендор-смузихлеб решил на них сэкономить.
Надеюсь, что и на тех платформах, с которыми приходится сталкиваться лично мне это недоразумение тоже как можно скорее закопают. Как же все-таки приятно пользоваться обычным приложением с нативной производительностью и look & feel, а не хипстерским аппом «от лесорубов для лесорубов» :)
Правда, как-то раз мне попался хостер, который майнил Monero на серверах клиентов (от чего опять же все тормозило), но здесь это скорее исключение, чем правило :)
Каких-то критичных проблем за последние 10 лет я не припомню. Впрочем, я и не знаю, что там у сферических домохозяек в вакууме.
В данном случае было бы достаточно в зачатке задавить демпингистов на уровне ФАС в рамках существующих законов. Почему этого не произошло — повод для отдельного размышления.
1. Получаем бизнес требования
2. Проводим первичную разработку занимая технический долг при необходимости, попутно собирая требования к будущей архитектуре
3. Проводим рефакторинг
Как показывает практика, при хоть сколь-либо грамотном управлении техническим долгом убыток от его обслуживания на шаге 3 во много раз меньше, чем ущерб от формирования архитектуры с пока еще малопонятными требованиями и её дальнейшей поддержки. Хотя пацанам, конечно, такое и действительно не покажешь.
Но при неблагоприятном исходе дела его использование может стать чревато «письмами счастья» от этих патентных троллей.
/hater mode