Свершилось

В котах наконец-то исправили тайпкласс для параллельных вычислений. История забавная, даже если вы не знаете, что такое F[_].

Изначально тайпкласс был написан как Parallel[F[_], G[_]], и второй тайп-параметр самым отвратительным образом мешал программировать. Задача на его удаление висела больше года, но не бралась в разработку, потому что все думали, что это нельзя сделать, не сломав бинарную совместимость со старыми версиями библиотеки.

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

А сегодня Travis Brown взял и всё починил. Не сломав бинарную совместимость. Потому что это было возможно всё это время.

По поводу критических изменений на уровне исходников забавно высказался Rob Norris:

the current API is so awkward to use that this is unlikely to break much code

Сегодня в маршрутке дувчушка лет 4-х спросила маму: «А если всем попросить Одерски, он закроет PR с отступами?»
С мамой плакала половина скалистов…
Одерски, выключи отступы!!!

Я/МЫ
JOHN
A. DE GOES

На днях в комментариях на реддите опубликовали подборку видео о работе компиляторов Scala и Dotty вкупе с книгами о компиляторах вообще. Решил немного дополнить список обзорными видео, поскольку слушать полтора часа про построение деревьев в Dotty может показаться утомительным.

Scalac:
1. Scalac Survival Guide (1 час)
2. A deep dive into Scalac (47 минут)
3. Scala compiler plugins 101 (32 минуты)
4. Scalac micro-optimisation (7 минут)

Dotty:
1. Dotty Internals 1: Trees & Symbols (1.5 часа)
2. Dotty Internals 2: Types (2.3 часа)
3. Dotty Internals 3: Denotations (2.5 часа)
4. Hands-on Dotty — Dmitry Petrashko (1.6 часа)
5. What's Different In Dotty by Martin Odersky (1 час)
6. Integrating IDEs with Dotty (30 минут)

Отдельным пунктом хочу выделить презентацию How an Optimizing Compiler Works (47 минут) под авторством Li Haoyi, в которой затрагиваются основные аспекты работы оптимизирующего компилятора.

Вот что раздражает в скале — так это ловля фатальных ошибок по умолчанию. Нет, я не хочу обрабатывать OutOfMemory или StackOverflow. Да, я всегда хочу чтобы они вылетели на самый верх.

Почему я должен постоянно писать

import scala.util.control.NonFatal

try { … }
catch {
  case e if NonFatal(e) => …
}

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

try { … }
catchFatals {
  case e => …
}

?

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

Оказывается, британская налоговая держит исходники своего софта открытыми, и пишет на скале. На гитхабе можно почитать сорцы их 500+ микросервисов и принципы разработки.

В продолжение темы открытых проектов. Софт для обсерватории Gemini пишется на скале и хостится на гитхабе. Над проектом работает Rob Norris — автор библиотеки doobie, которой его огромный вклад в сообщество, конечно, не ограничивается. Код написан в функциональным стиле c F[_].

У обсерватории два телескопа: в Чили и на Гавайях. На ютубе можно посмотреть коротенькое видео про неё.

В некотором роде, это лестница в небо

Я прям не удивлен результатом. Мяу
https://impurepics.com/quiz/

Одерски не только затащил отступы в дотти, но и теперь в релиз-ноутах новой версии все примеры кода уже только с ними 😫

Держу в курсе: джависты и скалисты второй день не могут нормально выложить релизы своих библиотек в Sonatype (хранилище артефактов, из которого пользователи могут подключиить зависимости в свой проект). Он попеременно возвращает рандомные ошибки и отваливается с таймаутами.

Вспоминается старый твит Li Haoyi

Есть очень крутой сайт astexplorer.net, на котором можно посмотреть синтаксическое дерево для любого куска кода на одном из поддерживаемых языков. Очень удобно выделять фрагмент кода и получать выделение соответствущих ему элементов AST (и наоборот). За парсинг скалы отвечает библиотека scalameta.

Только сегодня узнал, что в IDEA есть уберполезная фича: ставим курсор на нужную строчку, нажимаем ПКМ, и открываем этот файл в браузере на гитхабе! При этом будет выделена строчка, на которой стоит курсор. В этот момент у меня перед глазами пролетели все моменты, когда я искал нужный файл на гитхабе руками.

Daniel Spiewak опубликовал пост со своим видением трейсинга в котоэффектах. Планируется накапливать информацию о структуре цепочек вычислений и при вылете исключения распечатывать не только его стектрейс, но и информацию о графе выполнения асинхронного кода. Аналогичную фичу обсуждают и в мониксе.

А всё началось с того, что асинхронный трейсинг сделали в ZIO. Радует, как под влиянием ZIO сообщество шевелится и улучшает свой инструментарий.

Бесконечно можно делать три вещи:

1. Смотреть, как горит огонь
2. Смотреть, как течёт вода
3. Обновлять проект на скалу 2.13

Я, конечно, всё понимаю, но это календарь в виме

Устанавливается как обычный плагин, и через него можно смотреть и создавать задачи в гугл-календаре🙃

https://github.com/itchyny/calendar.vim

В блоге Фигмы (это гугл-документы от мира графического дизайна) вышла отличная статья (https://clck.ru/JsUmz) о том, как они делали многопользовательский редактор макетов.

Там почти нет программистских подробностей, интересно скорее то, как они максимально упрощали решение очень сложной на первой взгляд задачи. Заявленный принцип «no more complex than necessary to get the job done» применялся и к технической реализации, и к продуктовым требованиям.

Ещё в статье есть про то, почему они не стали применять Operational Transformation и честный CRDT, как они реализовали многопользовательский undo-redo и совместное редактирование древовидных документов. Всё написано простым языком и с наглядной анимацией.

А вот ещё одна статья (https://clck.ru/JsUnC) из их блога про то, как они решали проблему совместного редактирования упорядоченных последовательностей.

Тут один хороший человек сделал плагин для IDEA с набором инспекций кода на ZIO: github.com/hmemcpy/zio-intellij/

Настоятельно рекомендую установить его, если уже используете bleeding-edge технологии от Дегуза. Один подбор лучшего тайпалиаса для всех ваших дырок чего стоит!

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

Например, переименовали поле в классе, не зафиксировали старое название в коде с сериализацией, и отправили такой документ в сторонний сервис. В лучшем случае он вернёт ошибку, в худшем — будет молча проставлять дефолтное значение в старое поле. Или добавили в модель поле с конфиденциальной информацией, забыли подчистить его в кодеках, и слили наружу что-то лишнее.

А тут умные люди придумали golden testing — простенький паттерн, с которым тестировать сериализацию сильно проще.

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

1. Перед запуском теста проверяем, есть ли файл. Если нет, создаём новый с текущим выхлопом сериализации. Ответственность программиста — проверить этот выхлоп глазами.
2. При незапланированном изменении выхлопа тест покраснеет.
3. При осознанном изменении удаляем из ресурсов старый эталонный файлик. При запуске тестов автоматически будет создан новый, а мы провалидируем корректность изменений при помощи git diff

Оригинальная статья про golden testing: https://ro-che.info/articles/2017-12-04-golden-tests
Либа для скалы: https://github.com/circe/circe-golden
И для хаскеля: https://github.com/feuerbach/tasty-golden

Подъехал очередной билд-тул для скалы: https://github.com/tindzk/seed

Вдохновлялись cargo, внутри используют ZIO. Для сборки проектов подключаются к bloop (это инструмент для инкрементальной компиляции скала-проектов с кешированием компиляции и прочими плюшками), зависимости выгружают с помощью coursier.

В итоге получилась очень тонкая надстройка для управления зависимостями и разбиением проекта на модули: остальную работу делают уже готовые кирпичики. Этот проект показателен тем, насколько просто сейчас сделать свой собственный билд-тул на скале (но зачем?).

Пожно поглазеть и продолжить сидеть на sbt