Но нахуя так делать, если пишешь тест на контекст, потом mix test.watch и до зелёной точки

Короче эликсир сильнее форсит тебя в tdd

Надо просто не писать как на рельсе

Кстати, если на рельсе зайти чуть дальше в лес чем 1 bound context, то получается такая же ебала

Delivery::Core::VehicleRoute.find(route_id) только вчера писал

А сегодня - шаббат шалом, и с 1 декабря я пишу на Эрланге ;)

Есть книги по тестированию в Эликсире на совет?

Не встречал таких

Можно попробовать накидать, но я же видеокурс ща делаю

видел только конкретно по pbt книгу

Вопрос-то понятно почему актуален - появляются новые стартапы и прототипы. Но предложенное решение через горизонтальное масштабирование... не универсально.
1) Горизонтально масштабируется не всё, а только то, что изначально спроектировано с расчётом на concurrency. Иначе стоимость переделки приложения может быть сопоставима с написанием нового приложения.
2) Иногда важна скорость выполнения задачи в одном потоке, время ответа сервера на хттп запрос например. Добавлением серверов это не решается - решается либо оптимизацией кода либо сменой процессора на более быстрый. Также скорость важна для стейджингов, тестингов, дев-машин - это всё время разработчиков, тестеров и сисадминов.
3) Увеличить расходы на парк серверов легко, а уменьшить - трудно. Тут не только деньги, а ещё время и общая сложность экосистемы.

- Горизонтально масштабируется не всё - поэтому и предлагается сразу начинать с этого
- Иногда важна скорость выполнения задачи в одном потоке - согласен, в этом случае влияет выбор инструмента и возможны ситуации когда решением будет чуть ли не свой web-сервер писать, но у автора не этот случай
- Увеличить расходы ... легко, а уменьшить - трудно - 100%, особенно про поддержку всего этого добра. но всё же лучше когда есть вариант докупить пару серверов для увеличения мощности, а не единственный вариант это докупить более мощный проц

Лучше сразу на c++ писать

Криптобиржа - это набор служб: биллинг, матчинг-енджин, админка и обертка для постановки ордеров. Не надо придумать “колесо” - возьмите готовый матчинг на С/С++ благо они есть в открытом коде, и матчат 2 ляма ордеров в секунду. Биллинг - это штука которая зачисляет/списывает, не надо тут тоже придумывать что-то: вы берете все-равно готовые ноды крипты и уже с ними работаете, самая проблемная часть тут - ротация кошельков и хранение секретных ключей (а это основная проблема крипто-бирж). Хотите только основные валюты - смело можете ставить на BitGo и вообще не заморачитваться с этим. Так вот все кроме матч-движка я бы писал спокойно на элексире, а его бы взял вообще в опенсорс. Ну и не заморачивался со своими нодами а взял BitGo как готовое апи над криптой.

1. Горизонтально не маштабируется только то, что изначально было хреново спроектировано
2. Скорость выполнения HTTP запросов вы вполне можете поднять добавив сервер при вагоне и маленькой тележке случаев (если у вас есть гор. масштабирование)
3. Уменьшить очень просто - я вам как человек который уже 6 лет занимается антикризисным менеджментов это могу сказать. Никто просто этого не хочет делать

> поэтому и предлагается сразу начинать с этого

Я к этому и подвожу - нужно сразу брать инструмент с поддержкой конкурентности. Эликсир как раз такой - относительно быстрый и масштабируемый из коробки.
А вы как предлагаете "сразу начать с этого", учитывая, что вы предложили взять язык для быстрого прототипирования?

1. Я так и сказал: хреново написал - хрен масштабируешь. Интереснее вопрос как написать не хреново.
2. Дано: продакшн, ксеон 20 логических ядер, 2.2ГГц, загружен на 10%, http-запросы параллелятся средствами nginx, при этом время среднее отклика 1с. Профилируем, смотрим. Оказывается 0.3с - это CPU time, оставшиеся - 0.7с - общение по API с другими микросервисами и базой (на других физ.хостах). Вопрос: сколько нужно добавить серверов и куда, чтобы уменьшить время с 1с до хотя бы 0.8с? Это иллюстративная ситуация, можно не тратить время на ответ.
3. "Не хочет" - это понятие из кухонной психологии. В бизнесе есть "не рентабельно"/"не приоритетно" или "непосильно" (не осуществимо по техническим причинам). Вот тут хотелось бы подробнее узнать, какие на самом деле были причины не сокращать расходы на парк серверов.

Mazel tov

Нашел в Израиле Эрланг?