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

Двусвязный список на Rust. Это вообще возможно? Ну… да. С некоторыми оговорками. Что за оговорки, узнаем из четвёртой главы.

Списки, которые мы реализовывали до сих пор нельзя назвать настоящими функциональными списками потому что настоящий функциональный список должен быть устойчивым.

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

Можно ли написать на Rust устойчивый список? Думаю, вы уже догадались, что да. А как — узнаете из третьей части перевода Too Many Linked Lists.

Продолжаем знакомство со списками в Rust. Перепишем код, избавившись от типа Link и заменив его на Option. Сделаем наш список обобщённым. И добавим в него несколько полезных методов.

По дороге разберёмся с временем жизни и типажом Copy.

Продолжаем знакомство с ссылочной магией в Rust. Вместе с автором создаём первый работающий список, наступая на все возможные грабли.

В конце взъерошенные, но счастливые наслаждаемся результатом.

Здесь я (переводчик) собрал ссылки на все части цикла, написанного Скоттом Влащиным. И заодно перевёл предисловие, буквально, три абзаца.

Если вы захотите поделиться переводом, сбрасывайте ссылку именно на этот пост, потому что в нём есть все остальные ссылки.

Что ж, завершается цикл статей о проектировании, основанном на типах. Скотт показывает изначальный код (короткий) и сравнивает его с финальным кодом (длинным). И объясняет, почему размер — это хорошо.

Есть повод для размышлений!

Начал перевод, видимо, базового руководства по сложным темам в Rust (не считая Растономикона, который вообще про чёрную магию) — Learning Rust With Entirely Too Many Linked Lists.

Надеюсь закончить всё с течение мая. Сегодня — введение. Первая глава — после выходных.

Можно ли использовать размеченные объединения с одним вариантом (SCDU, Single Case Descriminated Unions) не только со строками, но и с другими типами? Можно ли накладывать бизнес-ограничения на такие штука, как количество позиций в заказе или дата рождения?

Скотт Влащин делится секретами разработки бизнес-логики на языке с алгебраическими типами. Подробности внутри.

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

Разберёмся, как это выглядит в языках с алгебраическими типами.

Пятый пост Скотта Влащина посвящён конечным автоматам (они же машины состояний или даже стейт-машины). Функциональные языки хорошо подходят для реализации конечных автоматов, а конечные автоматы хорошо подходят для реализации бизнес-логики.

Попробуем?

Четвёртый пост из серии Скотта Влащина посвящена предметной области. Как с помощью типов описывать бизнес-правила? Как типы позволяют углубить понимание предметной области?

Узнаем прямо сейчас.

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

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

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

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

Завершён перевод книги Люка Бруно «Nix в пилюлях».
Для удобства читателей, собрал ссылки на все двадцать глав в одной публикации — здесь.

Финальная глава! Люка Бруно рассказывает о секретном оружии Nix — хуках. Их используют, когда больше ничего не помогает, в частности, для кросс-компиляции.

Эта глава посвящена деривации stdenv, благодаря которой собирается большинство пакетов из репозитория nixpkgs. Она поддерживает инструментарий GCC, GNU make, autotools и другие распространённые системы сборки.

Для того, чтобы различать пакеты разных версий, Nix хранит их в каталогах с именами, которые содержат хеш. В главе 18 мы разберёмся, как вычисляется этот хеш для файлов, каталогов и tar-архивов.

Знакомимся с интересным трюком, который позволяет функциональному языку Nix делать то, то, что в императивных пакетных менеджерах делается с пол-пинка.
У них там, правда, dependency hell, а в Nix всё чинно и благородно.