После Ruby/Elixir в Go, часть 1
Когда я начал писать на Go после опыта с Ruby и Elixir, одной из самых непривычных вещей стало отсутствие консоли, в которой можно напрямую вызывать код приложения.
Для рубиста такая консоль почти универсальный пульт управления приложением(но пульт довольно опасный). Если нужно посмотреть, что происходит с конкретным пользователем, можно просто открыть консоль, найти его, вызвать нужный метод и понять, почему, например, не работает какая-то функция.
Набираешь:
bundle exec rails c
И через несколько секунд уже находишься внутри приложения и можешь работать с его кодом и данными. Только вместо кнопок у разработчика код. Надо помнить: «С большой силой приходит большая ответственность». © Дядя Бен.
Например, приходит вопрос:
Почему у этого пользователя не появился доступ к фиче?
В Rails можно открыть консоль, вызвать нужный код и довольно быстро проверить несколько гипотез. Когда я пришёл в Go, первое время постоянно хотелось сделать то же самое. Конечно, проверить код всё равно можно. Можно написать тест или небольшую программу, подключиться к базе, сделать отдельную CLI-команду под конкретный кейс, но это уже не то ощущение: «открыл приложение и начал быстро проверять гипотезы».
Ruby здесь не единственный пример. В Elixir есть интерактивная консоль IEx. Можно запустить прямо внутри неё:
iex -S mix
Благодаря возможностям Erlang VM можно даже подключаться консолью к другому запущенному узлу. И вот после Ruby и Elixir Go ощущается особенно необычно. В Ruby удобную консоль обычно даёт фреймворк. В Elixir сама платформа хорошо приспособлена к интерактивной работе с запущенной системой.
В Go это ощущается так:
Если хочешь что-то вызвать, сделай для этого нормальную точку входа.
Поначалу это раздражает. Кажется, что раньше на проверку гипотезы уходило 5–10 минут, а теперь приходится что-то дополнительно писать, но со временем я увидел в этом и другую сторону. Удобная консоль очень легко позволяет разработчику стать частью бизнес-процесса. Про эту боль я подробнее писал в статье. Также можно легко сломать продакшен.
Нет нужной кнопки в админке?
Попросим разработчика выполнить команду.
Нужно поправить состояние пользователя?
Разработчик сделает через консоль.
Для небольшого бизнеса это действительно может быть удобно. Но потом внезапно оказывается, что важная операция в продукте существует только потому, что рядом есть разработчик, который знает правильную команду. Я такой подход называю Developer as an admin panel.
В Go отсутствие такого универсального пульта начинает раздражать раньше. Если одна и та же операция повторяется, довольно быстро хочется сделать для неё CLI, скрипт, админку или нормальный API. Бизнес раньше начинает видеть ценность такого инструмента.
Я всё ещё считаю консоли в Ruby/Elixir невероятно удобными инструментами. Но теперь, когда хочется в очередной раз сделать что-то вручную, полезно задать себе вопрос:
Мне действительно не хватает консоли или не хватает нормального инструмента?
блоков, вы к ним добавляете еще 
блоков и получаете право потерять любые 
блоков из
, РС код позволит восстановить потерянное. РС код состоит из нескольких рутин с многочленами, реализация за 
-- уровень сложного практического задания на курсе по вычислительной алгебре. В теории еще с 80-х годов было подозрение, что эти рутины можно полностью сделать на основе FFT, получить вычислительную сложность хотя бы 
и быстрый алгоритм на его основе. На практике с этим было много проблем, первая и по большому счету единственная практическая реализация со сложностью 
появилась в 2016 году в Leopard-RS на основе работы 
, у XDRS параметры должны быть степенями двойки)