и тейк но присонерс

а еще контру 1.3

ну что повесить поверх фтп

типа на тот же диск

на уровне протокола пока сейчас

решается

фтп медленно, медленнее хттп

оч странный выбор

1. tagless final не принуждает писать код в другом стиле, большая часть кода остаётся такой же ,как была и имеет тот же смысл
2. tagless final не обязывает переписывать сразу весь продукт, можно добавлять кусочки, реализованные в TF стиле в готовое приложение
3. tagless final улучшает тестируемость, т.к. форсит IoC подход
4. tagless final делает психологически некомфортным плохо модуляризированный код, выставляя наружу все зависимости, что двигает разработчиков в сторону разделения кода на ортогональные концепты, это положительно влияет на способность локализовывать баги, разрабатывать не мешая друг другу и т.п.
5. tagless final улучшает переиспользуемость компонент, многие части требуют 0 усилий,  чтобы стать частью внутренней библиотеки компании, это сокращает расходы на разработку в мультикомандной компании
6. tagless final добавляет новые операции над компонентами, добавляя новые способы преобразовывать и композировать их, что позволяет разделить реализации на ещё более атомарные аспекты, выделить логирование, метрики, пост-обработки, верификации в отдельные части, не вводя новых абстракций, что снова улучшает модуляризацию, см. пункт 4
7. tagless final позволяет добавлять новые автоматизированные решения, анализируя форму трейта, что позволяет ещё сильнее улучшить продуктивность

это легаси которое никуда не уйдет

тебе надо было вставить фразу типа - "хуй коня" куданить

а то Антон прям так и скопипастит

я думаю нет, Антон вродь вдумывается в то что творит

Поэтому сам по себе таглесс файнал никаких позитивных качеств не несёт для продукта. Можно и на акке всё то же самое написать, можно и на чистой жаве с rx всё то же самое написать.
Но процесс разработки плавно улучшает продуктивность и сокращает риски по сравнению с конкретным ио

нормально

functional typed programming

функция тупящего программирования

1. хуй коня не принуждает писать код в другом стиле, большая часть кода остаётся такой же ,как была и имеет тот же смысл
2. хуй коня не обязывает переписывать сразу весь продукт, можно добавлять кусочки, реализованные в TF стиле в готовое приложение
3. хуй коня улучшает тестируемость, т.к. форсит IoC подход
4. хуй коня делает психологически некомфортным плохо модуляризированный код, выставляя наружу все зависимости, что двигает разработчиков в сторону разделения кода на ортогональные концепты, это положительно влияет на способность локализовывать баги, разрабатывать не мешая друг другу и т.п.
5. хуй коня улучшает переиспользуемость компонент, многие части требуют 0 усилий,  чтобы стать частью внутренней библиотеки компании, это сокращает расходы на разработку в мультикомандной компании
6. хуй коня добавляет новые операции над компонентами, добавляя новые способы преобразовывать и композировать их, что позволяет разделить реализации на ещё более атомарные аспекты, выделить логирование, метрики, пост-обработки, верификации в отдельные части, не вводя новых абстракций, что снова улучшает модуляризацию, см. пункт 4
7. хуй коня позволяет добавлять новые автоматизированные решения, анализируя форму трейта, что позволяет ещё сильнее улучшить продуктивность