Здесь мы разбираем реализации основных возможностей расширений Кана и некоторые частные случаи. Большое внимание уделено устройству свободной монады, как монады коплотности различных забывающих функторов.
Привет, Хабр! Мы Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные материалы и собственные комментарии. Мотивацию черпаем из желания развиваться и делиться полученными знаниями.
Поздравляем читателей с первым днем лета, желаем кайфовой разработки, интересных материалов и комфортных перерывов под летним солнцем!
Приветствуем любую обратную связь! (づ ◕‿◕ )づ
Project Loom меняет привычную модель конкурентности в Java: virtual threads делают потоки дешевле, Scoped Values дают аккуратную передачу контекста, а Structured Concurrency помогает управлять жизненным циклом связанных задач. Разбираем актуальное состояние Loom в JDK 25-27 и что из этого уже можно использовать.
В последней части про модели конкурентности JVM языков мы сравним разные подходы друг с другом. И ответим на вопрос “А зачем теперь тред пулы, если есть столько модных концепций: корутины, файберы, виртуальные потоки ?”
Coroutine, Fiber, Virtual thread - это всё одно и то же?
Или нет ?
Или нет.
А если под капотом всё равно JVM, почему нельзя просто везде включить virtual threads и успокоиться? Разберемся!
Вы пробовали что-нибудь кроме new Thread() ?
Конечно пробовали: Future !
И всё ?!
Разберемся с разными моделями конкурентности в Java, Kotlin, Scala/ZIO и Clojure: у всех JVM под капотом, но подходы разные. Начнём с разбора тредов, пулов, virtual threads из Project Loom и Structured Concurrency. Дальше: корутины, fibers, ZIO runtime и Clojure.
HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.
Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.
Моки — достаточно крутой инструмент, если использовать его правильно.
И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента.
И я не буду здесь спорить о терминологии — в этой статье я буду называть все тестовые дублёры «моками». Примеры будут на Scala, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.
Привет, Хабр! Мир! Труд! Май! Мы — Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Поздравляем всех с майскими праздниками! Желаем всем хорошенько отдохнуть и, конечно, найти время и инвестировать его в нашу любимую Scala.
Приветствуем любую обратную связь! (づ ◕‿◕ )づ
В этот раз мы разберём, как пересвёртка рекурсивных структур данных помогает в решении задач динамического программирования.
Привет, Хабр! Меня зовут Артём Корсаков. Я пишу на Scala и руковожу группой разработчиков в компании «Криптонит», а также веду Scalabook — русскоязычную базу знаний по Scala и функциональному программированию. В этой статье расскажу про обработку ошибок в библиотеке http4s на Scala 3. Мы разберём, как настроить декодирование запросов так, чтобы клиент получал не просто код “500” или “422” с общим сообщением, а сразу видел развёрнутый список всех проблем в запросе. Например, что логин уже занят, пароль содержит недопустимые символы, а капча не введена.
Пожалуй, самая раздражающая ошибка — это получение кода “500” в ответ на запрос, который ты десять раз перепроверил, сверился с документацией и уверен на все 100%, что запрос рабочий. Даже на 110%!
В такие моменты раздражённо думаешь: “Что же этому серверу надо? Я же чётко сформулировал запрос!
Ответить на этот вопрос порой сложно. Например, я хочу зарегистрироваться на сайте, ввожу логин/пароль и получаю сообщение "Internal Server Error". Первое желание – тут же покинуть сайт и поискать более дружелюбный.
Давайте подумаем, как можно сделать сообщение об ошибке более информативным. Для этого будем использовать Scala 3, уточняющие типы и http4s.
Представим, что мы создаём API сервиса авторизации, который (помимо прочего) должен регистрировать новых пользователей.
Для начала определим структуру данных для создания нового пользователя.
Мотивацией для написания этого поста стали два года собеседований JS/TS-инженеров. Я интересуюсь языками и функциональным программированием, поэтому всегда «разбавлял» технические вопросы разговором о парадигмах. И заметил любопытную асимметрию.
Об ООП кандидаты рассуждали уверенно — но в основном на концептуальном уровне, не вдаваясь в то, как именно ООП реализовано в JavaScript. С FP картина была другой: уверенности меньше, зато критика — конкретная и повторяющаяся: «иммутабельность дорогая по памяти», «рекурсия небезопасна из-за стека». Что характерно — эти аргументы почти всегда были сформулированы через опыт работы с JS, а не с Haskell, Clojure или Scala.
Это важная деталь. Любая парадигма существует на двух уровнях: концептуальном (идеальная модель) и имплементационном (как конкретный язык эту модель выражает). Судить о FP по JS — примерно то же самое, что судить об ООП по bash-скриптам с глобальными переменными.
Параллельно я регулярно слышал, что JS — функциональный язык. Аргументы варьировались от «там есть .map()» до рассуждений о чистых функциях и каррировании. Именно это и стало поводом для поста: я хочу объяснить, что я считаю функциональным языком — и почему JS таковым не является. Не перечислить отсутствующие фичи, а показать, почему их нет и что это значит в реальном рантайме.
В поиске способов построения монад мы уже рассматривали сопряжения и расширения функторов. Свойства обеих абстракций выражаются естественными преобразованиями, но ещё не был представлен универсальный метод их получения. В этот раз мы познакомимся с техникой, позволяющей решать такие задачи.
В предыдущих частях мы видели, что все манипуляции в категориях происходят между морфизмами и совокупностями морфизмов. Для теории типов это вообще очевидный факт — любые конструкции (типы) являются функциями, преимущественно высокого порядка. В контексте вычислений обе теории представляют собой различные точки зрения на этот процесс, и между ними есть немало общего. В частности, функторы являются в первую очередь функциями на морфизмах, из которого следует (нефункциональное в общем случае) сопоставление объектов. Поэтому ожидается, что должен существовать конструктивный вывод возможностей описанных ранее абстракций.
Давайте рассмотрим технику исчисления концов через призму теории типов с использованием языка программирования Scala.
Эту печальную историю стоит прочесть всем, кто еще не понял разницы между «создать» и «владеть» применительно к программному обеспечению.
Заодно узнаете, чем на самом деле занимаются большинство разработчиков на крупных проектах.
Строгая типизация не всегда спасает от глупых ошибок. Если userId, orderId и productId — это один и тот же Int или Long, компилятор не увидит разницы и спокойно пропустит неверный аргумент. В Scala 3 для таких случаев есть opaque types: они позволяют сделать доменные типы различимыми на этапе компиляции, но без лишних обёрток и накладных расходов в рантайме. Разберём, как это работает и чем этот подход лучше type alias, case class и AnyVal.
Рефакторинг — это не уборка, это хирургия на живом коде. Большинство провалов здесь не технические: смешали рефакторинг с улучшениями, сделали один огромный коммит, затянули релиз — и три недели работы ушли в мусор. Собрал 10 ошибок из реальных проектов: с примерами кода, разбором механики и способами не наступить на те же грабли.
Как перевести продакшен-проект на рельсы agent-driven development - когда LLM-агенты становятся полноценными участниками разработки, а не просто подсказчиками в автокомплите ? Реальный опыт на реальном проекте !
Продолжаем улучшать Feedback Loop. В предыдущей статье я ускорил прогон тестов в 6 раз. Теперь — следующий шаг: LLM-агент генерирует тесты. Два подхода (sprint-driven и coverage-driven), шестиуровневый pipeline верификации, двух-агентная архитектура, оптимизация feedback loop — и 68 тестовых файлов на выходе с acceptance rate 86.8% при ревью живыми разработчиками.
В статье — конкретика: как анализировал покрытие и свежесть документации, как ускорял компиляцию для агента, на чём экономил токены, и что сказала команда на code review.
В этот раз мы проанализируем различные способы факторизации монады на сопряжённые функторы. Прежде всего рассмотрим два полярных варианта, раскрывающих наиболее важные аспекты факторизации. Это даст более глубокое понимание самого понятия монады и послужит мотивацией для построения операции факторизации произвольного функтора.
Всем привет! Меня зовут Сергей и последнее время я занимаюсь backend-разработкой на Scala. Вообще, мой опыт асинхронного программирования на Scala и C# составляет более десяти лет, и за это время сложилось вполне достаточное понимание этой темы. Во всяком случае, тогда мне так казалось…
Но недавно в беседе с коллегами обнаружились большие проблемы в моём «понимании», что мотивировало детально разобраться в этом вопросе.
