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

val a = func1() ?: return err;
val b = func2() ?: return err;

Ok(a + b)

Ты что-то странное тут написал с ?:. Мой код выше делал примерно то, что этот твой псевдокод. Но ведь есть нюанс, err из первой функции и err из второй функции имеют разные типы. А значит нам нужен общий тип, в который эти ошибки и будут конвертироваться.

столько, за сколько договоритесь
это рынок, есть баланс спроса и предложения

нет. ты не понял смысла. если выпала ошибка после func1, то func2 даже не должен вызываться. ибо какой смысл в этом?

Надо тащить не по всему стеку. Но та-же пропажа сети может всплыть где-то где мы делаем запрос, а обрабатывать надо её наверху. Вот там и приходится тащить.

Хотя наверно можно запаниковать. Паники вроде можно отлавливать.

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

Они и не будет вызываться в моем коде.

Именно. А расте нужно будет тащить ошибку.

Писать фп код? На котлине это вроде не то, чтобы особо практикуют, если я ничего не путаю.

писать его чтобы что?

Чтобы решать задачи.

в котлине нуллабл типы, вместо Optional. корутины, вместо фьючей. ты так же можешь юзать эксепшены/лупы и при этом дебаггер работает. есть кооперативность. с фп все будет хуже

с фп все будет по другому

Ну и futures в современной фп скале не используют.

в смысле?

К основным проблемам фьючи я бы отнёс
- Комбинация только с помощью имплиситного экзекьютора. Можно сломать фор-компрехеншен случайным импортом
- Почти каждая операция требует запуска как минимум одного Runnable. Т.е. синхронизация стейта пулов на каждый шаг. Это действительно сильно аффектит производительность реальных конкурентных приложений
- eager by default. Ничего не мешает воспользовать тем же трейт, чтобы реализовать запуск by need, но это сломает большую часть утилит,  они часто исходят из предположения о немедленном запуске
- Стандартные реализации фьючи мутабельные. Сильно. Утилитарный код может порождать множество гейзенбагов, если не учёл все особенности комплита и линка и не перепроверил что-то дважды\не синхронизировался.
- Ручное управление конкаренси. Отличие параллельного от последовательного запуска обычно - это отличие в def vs val. Маленькая ошибка может превратить асинхронный стрим в мемори лик.
- Отсутствие cancelation во встроенной реализации. И не самый простой способ использовать в twitter. Случайно не выполненный вызов сайдэффектящего метода в твиттер приводит к неотменяемости.
- Предыдущее также сильно затруднаяет финализацию ресурсов в конкуретном коде
- Стандартный способ интеграции - промис. И отсутствие встроенного набора конкурентных данных как в  cats-effect\zio принуждает пользоваться им довольно часто. Намеренно незавершённый промис - это не отмена, а утечки памяти и нефинализированных ресурсов.
- При написании АПИ, если нужно принять асинхронный процесс в качестве параметра, каждый способ сделать это чем-то плох. Приём by name (=> Future[A]) кажется самым прямым аналогом получения IO[A], однако постоянно ломается при доработках, в особенности новичками. Где-то лишний вал - и фьюча запустилась

Результат - код на фьючах нельзя доверять кому-то меньше мидла

И всё равно опасно

от того что ты назовешь фьючу промисом или IO[A] суть не поменяется так то