Comments 16
Но почему они туда ломанулись?
Could you tell us more about it? How did this happen?
It is a long story, but I will try to make it short and sweet. Back in 2010, I was working on improving Rails performance when working with multi-core systems, as our machines and production systems are shipping with more and more cores. However, the whole experience was quite frustrating as Ruby does not provide the proper tool for solving concurrency problems. That’s when I started to look at other technologies and I eventually fell in love with the Erlang Virtual Machine.
I started using Erlang more and more and, with experience, I noticed that I was missing some constructs available in many other languages, including functional ones. That’s when I decided to create Elixir, as an attempt to bring different constructs and excellent tooling on top of the Erlang VM.
нет миграций и их нужно как-то отдельно запускать, например, из дев.окружения через проброс порта к БД (или через eDeliver, который сделает примерно то же самое).
Можно и без проброса портов и прочих хаков с помощью Distillery. И рантайм на сервер ставить не придется. habr.com/post/331598 – тут и про миграции и про webpack.
Про миграции интересно, спасибо. А про рантайм не нашёл. Можете подробнее рассказать? Я всегда мыслил, что при сборке пакета на ОС, отличной от продакшена, рантайм нужен либо cross compile, либо без рантайма и на прод его отдельно ставить… или я ошибаюсь?
А про Distillery… честно говоря, не пользуюсь им особо. Баш скрипт на 10 строк для деплоя и всё.
В эликсире нет колбэков.
Это не совсем верно. В эликсире есть колбэки, например, Enum.map/2. В эликсире нет блоков в том же смысле, в каком они есть в рубях. Зато есть макросы, через которые можно организовать похожее поведение при помощи quote/unquote.
Так как состояние не хранится в куче разных объектов, его приходится таскать за собой в одном объекте
И в этом есть определённый смысл, в отличие от всяких там JS, куда функциональщину тянут просто потому, что так модно. Elixir — это конруррентро-ориентированный язык, каждый вызов функции может отрабатывать не только в разных потоках или процессах, но даже на разных машинах. Для связывания всего этого существуют специальные инструменты, которые, собственно, и составляют основную мощь BEAM/OTP.
Он вообще другой, по сравнению с рельсой.
Самое интересное начинается тогда, когда пытаешься развернуть в кластере т.н. umbrella application. Это что-то вроде мета-проекта, который является обёрткой над кучей мелких сервисов.
В Elixir есть Pry и работает аналогично рубям.
А ещё есть классический дебаггер Erlang, который ко всему прочему показывает деревья процессов.
До максосов руки ещё не дошли, но уже предчувствую веселье. А вот про амбрелу ни разу ничего хорошего не слышал и даже связываться не охото. Можете что-нибудь более предметное из практики про неё рассказать?
Пример: прокси-граббер. Одна часть собирает ссылки и ставит их в очередь на обработку парсеру списков, парсер ставит адреса в очередь чеккера, который уже перенаправляет проверенные прокси в базу. В дополнение сбоку присобачивается сетевой сканнер и брутфорсер. Это всё отдельные части одного проекта, которые, очевидно, есть смысл размещать на машинах разной конфигурации.
Про импорт модулей в iex. Добавьте в корень проекта файлик .iex.exs и в него что-то типа вот этого:
import Ecto.Query
alias Opm.Repo
alias Opm.Origin
alias Opm.FormFieldСильно облегчит жизнь в консоли :)
У такого файлика есть один маленький недостаток — попытка запустить iex вместо iex -S mix из корня проекта заканчивается CompileError'ом.
Если вдруг кого-то это так же раздражает как меня, и если такой файлик используется только в корне mix-проектов, то вот баш-скрипт который решает эту проблему небольшим костылем:
iex() {
iex_executable=$(which iex)
if [ -f .iex.exs ] && [ "$1" == "-S" ] && [ "$2" == "mix" ]
then
$iex_executable "$@"
else
$iex_executable --dot-iex "" "$@"
fi
}
Справедливости ради, Context не спасает от бизнес-логики в контроллере, он её умеренно локализует. В крайнем варианте можно не проникнуться и начать использовать один контекст внутри другого. Вот тут веселье начинается… Но в общем случае да — отличная штука.
И тут же мне любопытно, кто у кого идею контекстов спёр? Фаулера не предлагать, с ним и так всё понятно. Просто в начале был MVC, потом на него начали накидывать разные сервисные классы, а потом начали появляться trailblazer'ы с аналогами контекста. Они до одной и той же идеи параллельно с эликсиром дошли или одни у других утащили? Или там есть кто-то третий, откуда все вдохновение черпают?
www.youtube.com/watch?v=l3VgbSgo71E
Плюс классная книжка:
pragprog.com/book/swdddf/domain-modeling-made-functional
Различия Phoenix и Rails глазами новообращённого