Сегодня прочитал замечательный текст про стариковское ворчание[1][4], и, по забавному совпадению, доклад Andy Pavlo про волну NewSQL баз данных[2]. Первое, вкратце: молодежь решает все те же проблемы заново с помощью все более высокоуровневой и дорогой технологии. Второе, вкратце: десятилетняя волна NewSQL стартапов сошла, ничего не прилипло, продолжаем использовать MySQL, PostgreSQL и все что на их основе.
Лично я отчетливо осознал этот эффект довольно давно, когда столкнулся с обидным фактом, что многие вещи на node.js делаются сложней, чем на C и bash (и сделал про это доклад на fronttalks [3]).

Теперь введем формальное определение, чтобы придать дискуссии строгость. Пердунотехнологией будем называть то, что прекрасно работало в 2000 году. Что входит в эту категорию? MySQL, PostgreSQL, SQLite и прочие Oracle. Из языков C, C++, Java, Erlang, Python. JavaScript номинально тоже уже был, но использовался для анимации менюшек; первое нашумевшее Ajax приложение это GMail в 2004. А хорошая VM появится в 2008 (v8). Так что js исключаем. HTTP, HTML, CSS - безусловно были.

И тут мы приходим не к самому приятному выводу: пердунотехнология продолжает прекрасно работать. Без докеров и кубернетисов. Не переписанная на Rust. Все Хромы и v8 написаны на пердуническом C++. Сеть продолжает работать с пердуническим HTTP поверх архипердунического TCP.

Волны хайпа перекатывают через этот утес и еще миллион лет будут перекатывать.

Когда я выбирал, на чем писать RON, разные были варианты, но C и C++ - единственные рабочие; да и преимуществ при работе с байтовыми потоками высокоуровневые языки не давали. А если подняться хотя бы до golang, то embedded library уже не сделать никак. Так что выбрал C++ и потом частенько подумывал, что C мог бы быть более подходящим вариантом.

P.S. в дальнейших дискуссиях предлагаю использовать термин "перунотехнология"

[1]: https://news.1rj.ru/str/reinforced_sc/53
[2]: https://assets.ctfassets.net/oxjq45e8ilak/5rdaQwruVOjycswCUhLORk/56f89872e742d28644472e1f3695b922/newsql2021.pdf
[3]: https://www.youtube.com/watch?v=jeg-RpXjdZ4
[4]: https://news.1rj.ru/str/nikitonsky_pub/171

# Оффтоп - про технику

Я приобрёл тут Legion 5 Pro с восьмиядерным AMD и очень результатом доволен. Первым делом разобрал, конечно. В детстве я тоже так часто делал, но с годами мастерство росло, так что в результате всё хорошо работает. Система теплоотвода - примерно как у грузовика, много металла. Три трубки и теплорассеивающие щитки на всех деталях. Вообще, устройство габаритное и по современным меркам тяжелое. Но мощное. Экран шикарный. Клавиатура на уровне ThinkPad!

Хочу сказать, что в номинации мощных ноутбуков это для меня огромный шаг вперёд, по сравнению с прежним ThinkPad P1, например. У того чуть что - процессор перегревался и уходил в троттл. Работа в CLion была тем ещё развлечением. И шаманства для настройки Linux нужно было невероятно много. Тут Ubuntu встал сразу, как родной (с Fedora пока всё сложно).

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

# Тяжелый этап

В разработке я вижу четыре основных этапа - проектирование, кодирование, отладка, фаззинг. Проектирование - это этап радуг и единорогов, он эйфоричен и беспроблемен, если только вы нормальный человек. Именно поэтому, хороший проектировщик - зануда и даунер, ненормальный человек. Далее кодирование, где вылазят все нестыковки проектирования. Это тяжелый этап, но там есть свои депрессии и эйфории, такие крутые горки, так что несмотря на тяжесть, это может сильно затягивать. Потом самый тяжелый для меня этап - отладка. Все крутые идеи придуманы на проектировании, потом все интересные головоломки решены на кодировании, а теперь нужно, не выпуская всей картины из головы (неприятно), пройтись по всему коду и исправить все ляпы и нестыковки (тяжело). Работа настолько увлекательная, что для увиливания от нее я готов заняться готовкой, приборкой, мытьем унитазов и написанием постов в социальных медиа. Потом фаззинг, но фаззинг это как охота или игра, это круто и увлекательно.
Но что делать с отладкой?

Кстати, идея со скриптовым языком получила продолжение. Что-то между bash и Erlang, называется Ronish. Бюджет времени очень ограничен и во многом это способ прокрастринировать одну большую отладку. Я аргументировал, что если систему можно скриптовать и мучать в REPL, то и отладка заспорится. Единственная проблема - Ronish тоже надо отлаживать...

Кажется, к докладу придется готовиться

Выступление на ConsensusDays получилось довольно хулиганским.
Не успевал сделать слайды - позаимствовал два у выступавшего следом Клеппмана; зачем второй раз рисовать? Плюс, один организатор стал топить, что BitCoin - очень хорошая технология. Тут уж меня было не остановить, чуть не пол-доклада ушло на чморение BitCoin и блокчейна. Компетенцию доказывал текстом 2011, где все имеющиеся проблемы блокчейна и PoW мной были перечислены.
А так-то про RON собирался петь.
Тезисы:
- Blockchain это просто связный список, только вместо поинтеров хэши; (одно)связный список - не самая эффективная структура данных; то же live Merkle tree (RFC7574) куда как лучше по Big-O.
- Cryptographic sediment - проблема, когда разнообразные криптографические примитивы становятся частью данных (record) и остаются с нами навечно (в блокчейне это ярко выражено)
- В BitCoin и всех подобных проектах, доверие (trust) фактически присутствует, что бы ни говорили фанаты ("биток-биток, фиат-фиат"). Поскольку нет атомарности между отправкой койнов и получением товара, некоторое доверие очевидно необходимо. Поэтому если строить консенсус на Web of Trust, может даже лучше получиться.
- В правильной архитектуре, при принятии монетки мы должны смотреть максимум на историю этой самой монетки. Блокчейн и хранение истории мира - это уродливое заимствование из классических одноузловых БД. Еще в 1990х, в бум доткомов, было установлено, что это не масштабируется. (Для больших IT компаний, масштабируется через Kafka и подобные шины - но это не наш случай очевидно)
- RON умеет красивое крипто и каузальные партиции (попросту, бранчи), поэтому потенциально решает перечисленные проблемы блокчейна.
- Вопрос в консенсусе. Тут ведется работа.

И маленькое соображение вдогонку. Как известно, во всем известном Диффи-Хеллмане был мааааленький ньюансик, который подавляющее большинство криптографов не отражали. Это позволило NSA прослушивать TLS, SSH и IPSec, массово. Внимание вопрос. Учитывая количество экзотической криптографии в среднестатистическом крипто-стартапе, какая вероятность того, что там нигде не напортачено?

Забавный факт. В 2013 наш CRDT проект для Яндекса спустили на тормозах и, как мне передали, политическое обоснование было, что лучше купить технологию у Microsoft (Office 365), а то разрабатывать дорого.
А теперь вот Office 365 все более активно применяет CRDT, забавно https://fluidframework.com/
Интересно, сколько Яндекс им заплатит в результате, в сумме.

P.S. Если бы я пошел работать в MS на это направление - ещё бы смешней получилось. Возможность была.
P.S. А история-то развивается https://habr.com/ru/news/t/554510/. Ну, привет Нижнему! https://r7-office.ru/tekstovyj-redaktor
P.P.S. А, говорят, это просто опенсорсный OnlyOffice с поменянными логотипами. Тогда, получается, Риге привет :). https://github.com/ONLYOFFICE/
P.P.P.S. А для не-российских IP по-прежнему MS. Интересненько.

Китайские майнеры ринулись в Казахстан. За прошедшие пол-года было все: веерные отключения, попытки перепиарить черное в белое, решения правительства и межправительственные тёрки (Казахстан стал много электричества брать у РФ)
И вот вишенка на торте:
https://club.dns-shop.ru/digest/58901-v-seti-pokazali-samuu-krupnuu-maining-fermu-v-kazahstane-i-sng/

Та история с Яндексом играет всё новыми красками. Ink&Switch выдали на гора текст по CRDT для rich text editing. Человек, который делает CRDT для Microsoft, очень восхищается их результатами. Я обнаружил, что они отстают от меня лет примерно на 10. Поделился архивным кодом
https://twitter.com/gritzko/status/1463404022212304898

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

В продолжение темы хэш-таблиц, на HN сегодня эпическое обсуждение поста https://news.ycombinator.com/item?id=29319151#29319535
Добавлю, что у open addressing есть колоссальное преимущество в C++ (и только в C++) -- такие таблицы можно mmap'ить на диск, получая маленькую базу данных. Но тут конечно есть тонкости, так что в какую-либо стандартную библиотеку такую возможность никогда не включат - там всё должно быть foolproof.

А кульминация этого тренда - это отделение машины разработчика от среды выполнения программы. При таком подходе, разработчик окончательно потеряет возможность самостоятельно запускать собственный код. Только на серверах компании, только по проприетарному протоколу, только как часть огромной системы. Такой огромной, что нет человека, который понимал бы 10% её устройства.
С одной стороны, это ещё более укрепляет позиции бигтеха. Такое явление, как "стартап от экс-гуглеров", станет историей. С другой стороны, безусловно, это приближает нас к пост-апокалиптическому миру, так как при коллапсе системы нам останется только сдохнуть. А сложные системы порой коллапсируют по причинам, которые даже ретроспективно не очень понятны. Римская Империя, например. Или, на моей памяти, Советский Союз.

Если подумать, Microsoft же строили похожую систему. На момент появления Веба, Microsoft сожрали всех. То есть, каждый продукт Офиса (Word итд) был когда-то отдельным продуктом, который делал отдельный стартап. MS их либо купили либо (чаще) скопировали. Платформа жрёт всех.
Что привело к взрывному росту Веба. Ведь это была единственная полянка для зайчиков, где их не скушает серый волк. Открытая платформа, где можно быстро написать сервис на коленке. Туда сбежались все Амазоны, Яху, Вебваны и Пэйпалы, разные другие сайты, магазины и прочие блоггеры, и стали там кормиться и резвиться. Хорошая, как оказалось, была полянка, многие выросли очень большими. Но постепенно Гугл, опять же, сожрал всю мелочь, так что в Вебе уже мало чего происходит. В целом, Веб становится такой же тихой заводью, как и MS Windows.

Что ведёт нас к следующему шагу этой истории: может ли крипто вырасти в новую платформу, где начнёт резвиться новое поколение зайчиков? Писать на коленке маленькие программки, зарабатывать бабосики, кормиться и расти?
В сегодняшнем виде - вряд ли. Тот же Ethereum уже трещит по швам, хотя его толком-то ещё не начали использовать массы. Тем не менее, игра в экосистемах Веба, Микрософта или мобильных приложений - это игра, в которой выигрывает казино.
Поэтому, полагаю, крипта будет дальше эволюционировать. 99% сдохнут, но придут новые и более хитрые, потому что всё равно резвиться больше негде.

# Побитная точность

Большой вызов в разработке формата или протокола - добиться идентичной обработки разными имплементациями (и разными версиями одной имплементации). Здесь, два моих любимых примера - JSON и Markdown. Оба формата очень просты; у Markdown нет формальной грамматики, но он интуитивно понятен; JSON же имеет формальную грамматику, которая умещается на визитке. Тем не менее, с совместимостью есть очень неожиданные проблемки.
Первый пример: Parsing JSON is a minefield, где автор не нашёл двух реализаций JSON, которые вели бы себя идентично https://seriot.ch/projects/parsing_json.html
Второй пример: CommonMark, попытка стандартизации Markdown, которая длится уже >7 лет, но новые нюансики всё находятся и находятся https://spec.commonmark.org
У обоих случаев есть простое комбинаторное объяснение.
С JSON фокус в том, что в разных его спецификациях есть маленькие разночтения и неточности. Допустим, у вас есть 10 разночтений - пусть самых простых, бинарных, true или false. Например, допустима ли trailing comma? Yes/No. В таком случае, у вас есть уже 2^10 = 1024 вариантов, как себя может вести парсер, оставаясь при этом совместимым со спецификацией. Из 1000 парсеров, может не найтись двух одинаковых!
С Markdown же другая заминка: там у каждого элемента свой синтаксис (а точнее, несколько синтаксисов). Та же звёздочка может быть частью списка, жирного текста, наклонного текста и вроде бы ещё чего-то, точно не помню, нужно проверить спеку. Поэтому, все эти синтаксические правила начинают взаимодействовать комбинаторно - в зависимости от других символов, пробелов, другой разметки. Поэтому, формальную грамматику для Markdown даже не получилось написать. Насколько совместимы реализации? Ну, насколько получилось, настолько и совместимы.
Как RON решает эти проблемки - в следующем тексте...

Тут меня спросили, используется ли RON в новой IDE от JetBrains.
Нет, совсем не используется, но поскольку спрашивают не в первый раз, почему бы не рассказать подробней. Итак, я действительно работал некоторое время в JB (в 2018), и более того, на внутренней конфе делал доклад как раз на эту тему - что IDE должно стать распределённым; и что если у нас есть распределённое CRDT хранилище, которое синхронизируется в реальном времени, то разные части системы могут работать на разных хостах. С упором на контроль версий в реальном времени. (Если кто-то знает, как найти видео доклада, подскажите.) Сразу скажу, что у JetBrains на тот момент было примерно три проекта так или иначе распределённого IDE, в одном из которых я и работал (datalore Костика). Еще были @jetzajac и Жемеров. Но это всё не так важно.
Я столкнулся с рядом проблем при разработке CRDT движка синхронизации и это на мне сказывалось. Но тут произошёл неожиданный сюрприз. Годом ранее я подавал заявку на исследовательский грант, и к сентябрю 2018 все колёса провернулись, я получил бабло. В довольно неплохом количестве. Но из JB меня попросили уйти. (1/4)

Короче, движок я доковырял весной 2019. Но обнаружился нежданчик, как всегда бывает. Я писал поверх LSMT базы данных RocksDB (C++). В таких БД есть операция merge, которую можно переопределять; определяем её в RON CRDT merge и радуемся жизни. В теории всё зашибок, можно тот же фокус проделать с LSMT Cassandra (Java) и будет распределённое хранилище. Очень красиво. Однако же, RocksDB оказалась очень сложным зверем и для нормального функционирования механизма, как оказалось, нужно ещё много её любить. Нарисовалось полгодика работы с кишками продуктовой БД facebook. С точки зрения будущего трудоустройства, конечно, неплохой вариант. Но всё равно, конструкция получалась неприлично сложной. У CRDT есть ряд свойств, который позволял сократить ряд слагаемых, и делать всё проще и надёжней. Одна проблемка - нужно писать этот движок с нуля. Что выберет упоротый? Конечно писать! Удивительно, но с 28 августа 2019 до 28 сентября я написал его в общих чертах и оно заработало. LSMT отправлялся в дупу. 2/4

В общем, за 2020 год я сделал Chronofold (статья и код), пару раз переписал движок, и поправил своё здоровье. В марте 2021 уже демку повесил на сервер, в наличии были RON store (тот движок без ненужных слагаемых) и игрушечная система контроля версий DaRWiN (на основе CRDT). Правда, разговор с JetBrains не получился, и я засел за третий перепис движка и одну статью, про которую я расскажу позже. DaRWiN получил пониженный приоритет, но я к нему вернусь. Чем же RON и DaRWiN так хороши? 3/4

RON позволяет распределённо работать со структурами данных (массивы, тексты, списки, словари) при ненадёжном интернете; local-first CRDT, всё мёржится. Это очень заманчивый субстрат для написания распределённых приложений. При этом, над RON определена криптография. Тот же git криптографию определяет по блобам; RON по операциям. Короче, это как паровоз и шинканшен. Про каждую операцию (в тексте - букву) известно, когда и откуда она пришла, кто подписал. Соответственно, апдейты могут литься в реальном времени, можно произвольно мержить и размерживать бранчи, итд. А поскольку оно realtime, его можно использовать прямо в редакторе для undo/redo, для совместной работы, итд. При этом оверхэды крайне небольшие, в докладе на HighLoad я рассказывал про некоторые фокусы. Блокчейн выглядит как каменный век по сравнению.
Сам RON довольно впрочем низкоуровневый. Примерно как WebAssembly для данных; так же есть текстовая и двоичная версии. При этом крипто считается от RONc - канонической двоичной версии, которая определена побитно (не мной, как правило). На этом уровне абстракции это нормально - two's complement INT, IEEE 754 FLOAT, UUID, UTF-8 STRING). Разработчик работает со структурой данных - допустим, текстом. Под ним chronofold, под ним RON, под ним просто поток бит. 4/4

Соответственно, побитная идентичность нетривиальных форматов - текстового RONt и сжатых двоичных RONv RONp - достигается через сюръективное отображение на канонический двоичный формат RONc, f(RONx)->RONc, и обратное инъективное g(RONc)->RONx. Причём, g(RONc)=RONx' и f(RONx')<->RONc это биекция. Так мы контролируем вольности форматов - компрессию двоичного, whitespace и пунктуацию текстового, итд. Короче, фактически это всё проверяется на корректность фаззингом (кольцевое преобразование). Так решаются проблемки типа JSON и Markdown - канонический формат лишен вольностей и побитно точен, остальные представления эквивалентны ему. Хэши считаем по каноническому формату, и дальше плетём любые криптографические сети. Текстовый формат определяем через формальную грамматику (спасибо, ragel) 5/4