ну потому что несекьюрно. если у вас будет два приложения крутиться на одном сервере, то при взломе одного из них с вашим решением второй тоже будет сразу дескредитирован. отдельный пользователь со своей БД под каждое приложение считается более правильной практикой.
а что с воркерами не так? для delayed_job ничего лишнего устанавливать не надо, а для sidekiq нужен только redis, и я его не хочу в дефолтную поставку добавлять. наверху предлагали добавить возможность выбора через параметры, может позже добавлю --redis
о проекте uwsgi я слышал только краем уха, и о том, что он поддерживает rack, я не знал (как и не знает большая часть rails сообщества).
я из интереса посмотрю потом, погоняю бенчмарки, но для типовых rails-проектов выбирать такую редкую птицу было бы непредусмотрительно.
nginx устанавливается из репозитория. сервер приложения берётся из rubygems через Gemfile самого приложения, как и в любом приложении на Rails. ещё вопросы?
Нормализация от 0 до 1 в графике — крайне неудачное решение при визуализации. Человеку надо объективно оценивать разброс и отношение минимального значения к максимальному.
> А с каких пор миксины, метапрограммирование и рефлексия являются фичами динамически типизированных ЯП
ЯП со статической типизацией не умеют миксины практически все.
метапрограммирование и рефлексию не умеет большинство. Те, кто умеет, делают это неудобно, и с проблемами в безопасности.
> с каких пор рефлексия является свойством компилятора
а с каких пор ЯП характеризуется только компилятором?
> с каких пор она сложно реализуется
а с каких пор просто?
олсо, переполнение стека в ЯП с динамической типизацией возможно только в бесконечной рекурсии и приводит к «Exception: stack overflow». и именно в ЯП со статической типизацией оно может случиться от любого неаккуратного обращения с памятью, и приводит к чему угодно, вплоть до выполнения случайного кода.
моё время не настолько дешёвое, чтобы я начал рыться на гитхабе в С++ — проектах, чтобы выдать списком issues, где появляются внезапные утечки памяти и переполнения стека от простой смены компилятора.
олсо, как минимум в одном ошибка выпадает из-за биндинга БД, написанного на ЯП со статической типизацией.
в вашем фундаменте есть одна большая прореха. вы считаете, что ошибки языков со статической типизацией не доходят до пользователя. это заведомо неверно. они гораздо труднее отлавливаются, и приносят не меньше проблем. могу для начала привести пример с переполнением стека.
ну и да, в нормальном процессе code review и тесты — это часть программирования, а не мера после нахождения ошибки в продакшене.
я подозреваю, что вы — просто один из тех людей, которых скорость разработки на ЯП с динамической типизацией извратила до патчей без тестирования в продакшн. отсюда и столько негатива. ну или вы просто часто сталкиваетесь с такими людьми в работе.
вы начали перекидываться «фичами» языка, которые «трудно реализовать» — я вам ответил такими же, свойственными для динамической типизации.
серьёзно, вы смотрите с одной колокольни, и судите только по той точке зрения, что по вашему опыту тяжело было реализовывать в статической типизации. а вот с динамической, у вас, судя по всему, серьёзного опыта просто не было.
перед тем как возмущаться про concurrency, перечитайте мой коммент выше, особенно его часть про производительность
p.s.: про «ниасилили» систему типов — поржал. миксины, метапрограммирование и рефлексия.
Как странно, что никто в комментариях не упомянул Бритву Хэнлона, которая полностью противоречит смыслу статьи.
не dictionary, а hash.
либо
hash.reduce({}) { ... }
/hash.each_with_object({}) { ... }
либо рельсовые
transform_keys
иtransform_values
я из интереса посмотрю потом, погоняю бенчмарки, но для типовых rails-проектов выбирать такую редкую птицу было бы непредусмотрительно.
кроме скалы и джавы, ещё существуют ЯП, кстати.
ЯП со статической типизацией не умеют миксины практически все.
метапрограммирование и рефлексию не умеет большинство. Те, кто умеет, делают это неудобно, и с проблемами в безопасности.
> с каких пор рефлексия является свойством компилятора
а с каких пор ЯП характеризуется только компилятором?
> с каких пор она сложно реализуется
а с каких пор просто?
олсо, как минимум в одном ошибка выпадает из-за биндинга БД, написанного на ЯП со статической типизацией.
ну и да, в нормальном процессе code review и тесты — это часть программирования, а не мера после нахождения ошибки в продакшене.
я подозреваю, что вы — просто один из тех людей, которых скорость разработки на ЯП с динамической типизацией извратила до патчей без тестирования в продакшн. отсюда и столько негатива. ну или вы просто часто сталкиваетесь с такими людьми в работе.
серьёзно, вы смотрите с одной колокольни, и судите только по той точке зрения, что по вашему опыту тяжело было реализовывать в статической типизации. а вот с динамической, у вас, судя по всему, серьёзного опыта просто не было.
p.s.: про «ниасилили» систему типов — поржал. миксины, метапрограммирование и рефлексия.