Если кто-то может скомпроментировать доверенную отдающую сторону - он сможет rm rf / и так

В рельсах была эпичная бага, когда какому-то балбесу пришла в голову шикарная идея десериализовывать юзерский инпут с соответствующим запуском произвольного кода.

Это то понятно. В php тоже десять лет не экранировали sql.

Вопрос в том, где в рельсе нужно сделать reduce по функции, потому что косяк именно в этом

Проблема не в редьюсе, а в использовании interop протокола для внешней передачи и обратно.

Это так же нелепо, как расшарить дропбокс по drbd протоколу и потом потратить 15 лет жизни на то, чтобы сделать это безопасным

это backdoor

Не будет развития эрланга - хана этому эликсиру

Думаю, оба два будут развиваться успешно. Эрланг - это не только OTP, но и BEAM. А Эликсир - это всё-таки штука поверх BEAM (и частично - OTP). Они хорошо друг друга дополняют.
Да и они слишком разные по возможностям. Субъективно, в коде на Эрланге внести ошибку сложнее, чем на Эликсире, т.к. там сильно меньше неявных вещей. А Эликсир позволяет писать меньше кода на единицу функциональности, что по-своему тоже хороший плюс.

Ненене, в этом то эрланг и эликсир не отличается.

Я же и в ковбое могу в куку запихнуть etf термы а потом их читать.

Тут проблема в том, что функция может вызваться там, где ты ее руками не вызываешь

т.е. проблема не конкретно здесь, а скорее в возможной склейке двух удобных решений?

с кукой конечно да.  Я помню, сколько нужно было потратить сил, чтобы в рельсах поменять с дебильного маршалинга на json куки

Я бы не назвал хранение etf в куке удобным решением, а имплементация протокола Enumerable на функции я вообще не понимаю зачем, но да - если их склеить вместе получается дыра

помоему есть разница между читать и запустить, прочитал не значит запустил

Вот я про это и говорю. Интероп есть и там и там, а вот reduce на функции - только в эликсире

Наконец-то могу с радостью сообщить о мажорном релизе https://github.com/halturin/ergo. Теперь можно не только расширить Erlang кластер нативной нодой, написанной на Golang, но и писать такое решение в привычном стиле с шаблонами Application, Supervisor, GenServer. А вишенкой на торте в этом релизе - экспериментальная поддержка Observer, т.е. интроспекция такой ноды доступна через привычный интерфейс. Полный список фич с деталями и примерами по ссылке.

Буду благодарен обратной связи

круто

Судя по всему, с этим говном в Эликсире все было так:

1. Сперва не было Enumerable, а был Iterator. Итератор был опеределен на лямбде чтобы ее можно было использовать в качестве генератора
https://github.com/elixir-lang/elixir/commit/efd161d145eed26b9bf52f09d48254dbd121cbb8

2. Совместили итератор и энумератор, добавили приколы в виде reduce
https://github.com/elixir-lang/elixir/commit/9318f747f46fa86eaf36d85eedc5f3e7748a4321
Причем придумали какой то dumb reduce на функцию

3. Потом поменяли Iterator на Enumerable, который для функции нвообще не имеет ссмысла
https://github.com/elixir-lang/elixir/commit/94f9d4e3f686ef800be9ee1dcdf03ba465ac0b20

4. Побоялись выкинуть 7 лет назад, что делать сейчас - никто не знает, потому что любое количество кода может быть на этом завязано.

5 ???

6 Пизда рулю

Спасибо. До крутости ещё далековато, но работаю в этом направлении ). Если будут вопросы, с удовольствием помогу. Мне важна любая обратная связь.

Не похоже, чтобы это было из рельс - протоколы же идут из Clojure. И вот в clojure тоже есть lazy вычисления.

Для lazy вычислений: посмотри h Stream.cycle для примера и прочие функции в модуле Stream.

В Erlang-е нет lazy вычислений встроенных, которые вообще очень функциональная вещь и идёт из haskell-я. У нас препод в университете рассказывал на функциональных языках лекции про Erlang, Haskell, так вот lazy вычисления в Erlang-е он делал со специальной библиотекой, потому что упустили такую чисто функциональную вещь, а в Elixir-е она встроенная.