Я все долго хотел написать пост про раст, и, наверное, когда-то его напишу, но недавно нашел это прекрасное видео, которое рассказывает про тот самый safety, что дает Rust, сравнивая куски кода с C++. Если вы все задавались вопросом "да кто такая безопасность в этом вашем расте", то видео очень хорошее
https://www.youtube.com/watch?v=IPmRDS0OSxM

Где-то год назад я полностью осознал казалось бы очень простую мысль: "все программирование, все, с чем мы работаем, это все код. Код, который зачастую опенсорсный, куда ты можешь зайти, почитать его, и если вдруг нужно - поменять"
"Well, duh", скажете вы, но главная суть этой идеи в том, что менять опенсорсный код - это нормально и не так уж и сложно. Например, если вы выбираете какую-то библиотеку или инструмент для работы, и он вот чуть чуть не делает того, что вам надо, то у вас есть возможность просто сесть и доделать это. Не надо ныть, что "уу хорошая библиотека, но вот фичу не умеет", не надо искать другие менее популярные (и более багованые) аналоги, просто сядь и пофикси (лол)

Вчера вот я вышел на новый уровень какой-то: в Go есть хорошая ORM библиотека для БД gorm, и есть хороший инструмент для миграций goose, написанный на го, и в котором можно в том числе писать миграции на го. Но вторая штука не умеет работать из коробки с gorm, и в итоге по сути надо делать два соединения с бд и работать с gorm через глобальную переменную, что не является проблемой, но блин некрасиво!
Я пошел в репу и нашел PR, который за 10 строчек добавляет возможность удобно подрубить gorm. Но чел этот пр видимо не запускал, и когда я запустил его у себя локально, то у меня все ушло в вечный цикл и ничего не работало.
Три часа дебаггинга спустя, я нашел забытый return nil, форкнул форк, пофиксил в нем багу, и теперь все хорошо работает
Но почему я решил этим поделиться: для меня лично это был новый уровень, когда я фиксил даже не саму либу, а чей то пр этой либы. Т.е. мало того, что я решил не искать аналог и пофиксить уже хороший инструмент, так я не стал в очередной раз городить велосипед, а нашел уже чей-то другой велосипед и починил пару костылей в нем.

Вторая причина, почему я хотел этим поделиться, это попытаться завлечь вас делать так же. Я часто обсуждаю всякую прогу с друзьями и коллегами, и часто слышу как люди сталкиваются с похожими проблемами "вот есть штука, но она делает почти все, что надо", на что я отвечаю "ну просто пофикси лол))", и люди думают, что я шучу, мол "да зачем", "ой лезть еще туда", "я не смогу" и т.д., но при этом ни разу не пробовали так делать. За последние два года у меня уже накопилось несколько контрибьюшенов в опенсорс софт, и все эти контрибьюшены (не считая опенсорсных репозиториев с работы) были ровно такими же: есть хороший инструмент, но нужна какая-то мелочь, сел, разобрался, добавил эту мелочь, получил свои фичи и плюс в карму за помощь в разработке опенсорса. И скажу честно: в первые разы было очень тяжело, я действительно тратил много времени (несколько дней), чтобы просто разобраться в чужом коде, но это просто скилл, причем очень полезный, и я крайне рекомендую в следующий раз, когда от хорошего инструмента будет нужна еще какая-то мелочь, просто сесть и добавить ее

Как выражать логику через систему типов, или пишем код, который не дает багать
https://leviska.notion.site/33f6445acb704440b57faae727123572

Я долго хотел написать этот пост, но все не мог найти хороший пример и не скатиться в "объяснение что такое Rust и почему он крута" на 30 страниц. И вроде бы получилось.
Если вы программируете на C++ и не понимаете вот этого хайпа вокруг Rust насчет "компилируется - значит работает" - пост для вас, с примерами на C++ и сравнением двух реализаций

Еще когда я даже не учил Rust, но спрашивал у знающих знакомых "как работает XXX", меня часто не удовлетворял ответ: казалось, что для того, чтобы писать такой же эффективный код на Rust, как и на C++, мне бы пришлось постоянно использовать unsafe.
Возьмем Option/optional:
Плюсы говорят "вот тип, вы можете проверять, лежит ли в нем что-то, а можете не проверять, так как уже проверяли когда-то до этого, нам пофиг. Но если не проверите, то будет бобо"
Раст говорит "вот тип, вы или должны проверить, или должны явно указать, что вы умнее через unsafe"
И во времена, когда я был ярым C++сером, мне казалось, что это будет как в плюсах, только неудобнее, потому что я даже не подозревал, что можно лучше.

Простой пример, как в C++ проверить, что что-то лежит внутри optional и получить значение:

if (optional_value != nullopt) {
  auto value = *optional_value; // используем "небезопасную" штуку без проверки, но мы же молодцы, мы проверили
  std::cout << value << std::endl;
}

Если это в лоб переписать на Rust, получим:

if optional_value.is_some() {
  let value = unsafe { optional_value.unwrap_unchecked() };
  println!("{}", value);
}

И когда я получал ответ на свой вопрос, мне казалось что как-то так оно и работает и люди реально пишут такой код

Но госпади спасибо разрабам раста конечно же никто так не пишет. Вместо этого, в Rust вы пытаетесь показать свою идею через систему типов. В данном случае вы хотите показать, что "вот тут я проверил Option, и 100% у меня лежит там значение" <=> вы бы хотели вместо Option<T> иметь тип T. И вместо того, чтобы держать это все в голове/комментариях (как в случае C++), мы выражаем это в типах, и перекладываем ответственность следить за типами на компилятор:

if let Some(value) = optional_value {
  // typeof(value) == T
  println!("{}", value);
}

В первую очередь мне нравится то, что это тупо короче и читаемее (имхо). Мы буквально написали "если в Option лежит что-то, то дай значение, иначе пропусти ветку" в одну строчку.
Но помимо этого, как я говорил, мы переложили ответственность следить за типами на компилятор. Поэтому, например, если кто-то удалит строчки с if (или переместит/скопирует тело if), то первые два варианта нормально скомпилируются, но последний - нет (т.к. у вас просто нет переменной value)

Лично я называю это "писать код в стиле Rust". С одной стороны - по сути это просто синтаксический сахар, реальной разницы после компиляции (вроде бы) нет. Но с другой стороны, последний вариант читаемее и безопаснее. Иногда у меня возникает ощущение, что некоторые люди очень поверхностно изучают Rust и пытаются писать "как на плюсах", расстраиваются, и возвращаются обратно. Но если бы они приложили больше усилий, то вполне возможно, их мнение было бы совсем другим.

Когда выложил этот пост, скинули статью, которая довольно хорошо объясняет подход "писать код в стиле Rust"/"type driven design"
В статье все примеры кода на хаскеле, но параллельно с этим объясняется, что он делает, поэтому я не зная хаскеля в целом все смог понять
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/
Не знаю, насколько много людей отсюда ее прочитают, но все таки решил поделиться

А поделиться я ей решил, потому что ее суть напомнила мне об одной мысли из какого-то древнего доклада, который я не могу откопать теперь(
Если верить моей памяти, то суть его была в том, что чуваку досталась какая-то легаси кодовая база с кучей багосов, и он решил поанализировать, какого рода баги там есть
И пришел к тому, что бОльшая часть самых неприятных ошибок, это... условия. Конкретно одинаковые по смыслу условия, разбросанные по коду
Ну например, вы проверяете, что строка начинается с какого-то префикса при обработке запроса, и в какой-то внутренней функции
Основная проблема в том, что код постоянно меняется, и вы, например, поменяете префикс в одном месте, но не в другом, хоп и получили баг

По сути, есть разные категории ошибок: проезды по памяти, гонки, логические ошибки и прочее. И многие ошибки мы умеем довольно быстро находить: (safe) Rust не даст вам скомпилировать код с проездом по памяти или гонкой, всякие санитайзеры помогут найти в C++
Но вот логические ошибки, это не поймать инструментами особо. Самый лучший инструмент - это написание тестов, что как мы все знаем, довольно часто игнорируется.

Еще после просмотра того доклада, я как-то начал относиться к любым "логическим" ifам с осторожностью: по сути, каждый из них может быть причиной бага.
И вот как раз этот подход из статьи выше, как мне кажется, помогает минимизировать количество таких ошибок: нужно пытаться выносить валидацию ("логические" проверки) в одно место, и после этого в системе типов как бы помечать этот объект "провалидированым", а в функциях и прочем уже использовать этот провалидированный тип

В статье в целом есть хорошие примеры, но я все равно приведу еще один: допустим, мы пишем какую-то библиотеку с математическими функциями, и многие функции могут принимать только положительные числа.
Если это целочисленные типы, то у нас уже(!) есть встроенное решение: unsized int и его вариации:
fn sqrt(val: u32) -> u32
Все, нам не нужны никакие проверки внутри функции, система типов гарантирует это. И я думаю, что вы согласитесь, что да, это разумное решение и у него нет особо минусов.
Что делать, если мы получаем число от пользователя (из json реквеста, ввод с клавиатуры, не важно)? Провалидировать его как можно раньше и засунуть в unsigned int тип, а дальше работать только с ним.
Забавно то, что если вы начнете писать библиотеку в такой идеологии, то все функции такого рода будут принимать uint, а следовательно они как бы будут заставлять вас провалидировать значение как можно раньше:
fn sqrt(val: u32) -> u32 // базовая функция


fn round_sqrt(val: u32) -> u32 // какая-то функция, которая использует первую
fn handle(val: String) { // наш обработчик
  let res = round_sqrt(val???); // хотим вызвать "сложную" функцию, но она сразу требует провалидированный тип
}

Но что если мы хотим еще и работать с числами с плавающей точкой? В большинстве языков нет встроенного типа для этого. Дак давайте сделаем свой!

pub struct uf32 {
 val: f32, // приватное
}
fn new(val: f32) -> uf32 {
  if val < 0.0 { 
    panic!("expected positive value"); // или, еще лучше, можно возвращать ошибку
  }
  return uf32{ val };
}
unsafe fn new_unchecked(val: f32) -> uf32 { // явно помечаем, что это небезопасно
  return uf32{ val };
}
// арифм операции и прочее

По сути, это тоже самое, что и uint: чтобы его получить, (по хорошему) нужно проверить, что значение действительно соответсвует типу. И после этого, можно его использовать уже без всяких проверок
fn sqrt(val: uf32) -> uf32; // без проверок

По началу это может показаться странным. "Да никто так не делает", "это какой-то оверинжиниринг". Но по факту - это тот же uint, но ufloat, а первый используют повсеместно, чем этот тип хуже?
И на самом деле, нет, это используют, но больше в функциональных языках: вспомнить NonEmptyList из статьи из хаскеля.
"Но мой набор легаси библиотек не умеет с этим работать!" - возможно. Но это не мешает писать новые библиотеки в таком стиле.
И тут как раз хочется вернуться к Rust: в стандартной библиотеке с давних времен есть "стандартные" решения подобных проблем: Option; Result; Box (unique_ptr), который не может быть null - ровно по этой причине. И из-за того, что это было все (долгое?) время с языком, все библиотеки активно это используют

Есть ли перформанс оверхед от этого? It depends
Например, в случае uf32, вы наоборот можете выиграть в перформансе, не проверяя на отрицательные числа в каждой функции.
"Но я могу просто не проверять, и перенести это на плечи разработчика": да, но либо вам итак нужно будет проверять это (если это ввод от пользователя), и тогда разницы нет, будете вы проверять это в конструкторе, или внутри обработчика; либо вы на 100% уверены, что все ок, и тогда можно воспользоваться unsafe (который буквально показывает, что это небезопасно)
В случае NonEmptyList (NonEmptyVec) перформанс действительно может(!) быть хуже, потому что последовательная память, кеши и все такое.
Но это довольно простые примеры.
В реальности, зачастую это намного более сложные типы, которые показывают какие-то сложные инварианты. Самый банальный пример: парсить json в структуру, и использовать ее везде, вместо использования абстрактного json::Value, который бы пришлось валидировать в каждом месте (да да я смотрю на тебя python)

Но в итоге, использовать библиотеки, написанные в type driver design намного намного приятнее и проще. Одни флешбеки с numpy функций после курса МО, в которых нужно заглянуть в документацию, чтобы увидеть value: int/float/array/list/object/ndarray, передать туда какой-нибудь pandas.Series и получить ошибкой в рантайме спустя 10 минут вычислений, потому что "а этого нет в списке извините", заставляют вздрогнуть.
Вместо этого вам часто даже не нужна документация! Вы пишете foo(bar), и либо оно скомпилировалось и скорее всего работает, либо нет. Помните слова "компилируется - значит работает" про Rust, да? :)

P. S. хотел кратко написать мысли по статье, проиграл
P. P. S. статью то все равно прочитайте!

Я не могу этим не поделиться
Недавно я делал внутреннюю тулзу, для которой хотелось запускать питон код
Я решил попробовать сделать это не с помощью процессов, а запускать питон прям в этом же процессе (язык для скриптов же все дела) (плюс можно было шерить память за очень быстро)
Для раста есть прекрасная либа под названием pyo3 (а еще там же есть биндинги numpy)

И мне надо было сделать datetime numpy array (массив дат)
Ну я и пишу какой-то код аля

PyArray1::<PyDateTime>::from_iter(dates...);

И что бы вы думали

1. Компилятор(!) знал и понял, что PyDateTime нельзя пихать в numpy array
2. Но он не только сказал, что нельзя, но написал мне ошибку со скрина

А именно, он мне сказал:
"PyDateTime" нельзя сувать в numpy array, но есть несколько других типов, которые можно, например numpy::DateTime

Оказывается, что у нампая свой тип дат (что логично, вместо всей структуры с полями типа year, month, day и т.д., там просто хранится timestamp)
И если я хочу быстро, то мне нужно использовать его.

И УЗНАЛ Я ОБ ЭТОМ НЕ ИЗ РАНТАЙМ ОШИБКИ, НЕ ИЗ ГУГЛА, А ОТ КОМПИЛЯТОРА
АААААААА

К слову, часто раст рекламируют как "memory safety", но на самом деле его система типов позволяет делать намного больше, как, например, тут, правильно описывать апи вообще другого языка.
Помимо этого, мой экспириенс с питоном в расте был мега приятный. Я не знал, можно ли в структурах, которые будут экспортироваться в питон, использовать обычные типы из раста (условно, нужно ли использовать PyString, или можно String), и вместо того, чтобы гуглить, безопасно ли это, можно ли так, я просто писал такой код, и он компилировался, и я был уверен, что так можно (и да, все ок)
И такого рода вещей было очень много. Я глядел совсем чутка на то, как это делается в плюсах, и понял, что там просто UB на UB (C api все таки), и был в шоке, наскольно приятно это делается тут.

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

Очень хороший пост-статья про то, как работает regex изнутри, и какие проблемы встречаются при реализации
Крайне интересное чтиво
https://blog.burntsushi.net/regex-internals/
#статья

https://world.hey.com/dhh/the-price-of-managed-cloud-services-4f33d67e
Хороший маленький пример сравнения cloud и bare metal с ценами (bare metal победил).
Одна из существенных проблем - очень тяжело оптимизировать стоимость клауда

Чем больше читаешь про hardware, тем меньше доверяешь компьютерам (с)
https://xuanwo.io/2023/04-rust-std-fs-slower-than-python/

https://beza1e1.tuxen.de/lore/index.html?s=35
Детективные истории про баги в софте и хардвейре
Вкуснятина

А вы знаете, как работает звук в линухе?

Наверное, не такой вопрос я ожидал себе задавать, когда взял гитару в руки за пару часов до этого. Я просто хотел спокойно поиграть на ней... Возможно записать себя пару раз, чтобы послушать "со стороны".
Ага, зараза подкралась незаметно.

Записывать звук? Любая микроволновка же так умеет
Профессиональная (чуть сложнее голосовухи в телеграме) запись звука вообще-то, блин, сложная (если ты хочешь слышать, что записывается), потому что твой звук должен пройти путь
звуковая карта (вход) -> ось -> DAW (приложение для редактирования звука) -> спецэффекты и прибамбасы -> ось -> звуковая карта (выход)
И сделать это все с минимальной задержкой (<=1-10мс), иначе будет ощущение, что играешь в церкви (натуральный reverb так сказатб)
И не все стрелочки выше хотят/могут быть супер быстрыми:
Казалось бы, хуе мое, стримы данных, забудем даже про DAW и эффекты, просто сделаем пайп байтиков из инпута в аутпут, мы молодцы, готово.
Ан нет, основная проблема в том, что выход не может "подождать" данных. Если их сейчас нет, то ему нечего играть, он играет ничего, а мы слышим всякие щелчки-кряхтение (звуки дедов в общем). И это уже физика, кодом ее не решить. Отсюда идет требование, что на выход всегда должны быть данные. А что делать, если вход тупит, операционка или даже звуковая карта затупила и отдала данные чуть позже? Вот мы и попались.

ALSA, или первый круг ада
ALSA вообще это ваш бро. Это по сути самый низкий уровень "звука" в ядре линукса. Вот девайс, вот отсюда звук, сюда звук, все. Бро он, потому что простой (а значит работает!!): фигачим окно в 1мс на затупы (покупаем нормальную звуковую карту между делом), соединяем инпут с аутпутом, и живем. Ну и подсасываем инпут для записи, но это уже дело десятое.
Ну все, взяли ALSA, дело сделано, пошли гулять? Эээ, стой, а че хром с backing track перестал работать? Куда звук делся? А еще системная громкость не работает (но мы это мастером на -10дб пофиксим если что).
Ага, для всего остального нам нужен Audio Server, который будет микшировать звуки из разных приложений, управлять уровнями (громкостями) (не только системными, но и по приложениям), при этом отдавать эти стримы разным нуждающимся (напр. использование микрофона в двух приложениях одновременно)

PulseAudio, или швейцарский нож
Вот это имя скорее всего будет знакомо всем линуксоидам, которые когда-либо сидели в наушниках без звука на 5й странице гугла. Потому что с ALSA все просто: либо ваше устройство есть, либо его нет, и тогда обновляем кернел, а если не помогло, идем плакать на форум что дрова не завезли. А с PulseAudio тяжело, мда.
PulseAudio это такой мультитул, который пытается у всех программ звук забрать, замикшировать его в одну кучу, настроить громкость там все дела, и протолкнуть итоговый к.. результат в вывод вашей звуковой карты. И на самом деле делает это не совсем убого.
Основная его идея, это сделать все буферы ну капец большими, так что даже если вы запустили вс код, и вкладке со спотифай внезапно не хватает ядер процессора, у пульса будет немного буфера, чтобы это все замазать. Это хорошо работает, когда вы воспроизводите звук. Ютюбчик там, музяка, голосовухи в телеграмме. Это нормально работает, когда вы записываете звук без прослушивания: голосовухи там, дискорды и гугл миты.
Но это отвратительно работает, когда вы хотите записывать звук с мониторингом того, что вы вообще играете. Я не шучу, пока я услышу свою ноту на гитаре, я могу сходить себе чай заварить (ладно ладно, но задержка реально несколько СЕКУНД. UN-ACC-EPT-AB-LEEEEE)
Кстати, так (огромным буфером) работают аналогичные слои в других ОСях по умолчанию (никогда не пробовали на винде в системе включить "прослушивание микрофона" и офигеть от задержки? Даже с нормальной звуковой картой там все еще дофига)

JACK/PipeWire, или "а что если дать юзеру страдать с конфигами?"
Я, если честно, не уверен, что линукс где-то прям используется энтерпрайзом массивно для звука, но вообще не удивился бы. Потому что челы реально посмотрели этот видос и сказали "блин вот это тема, в которой никто никогда не разберется, но теоретически можно хоть ракету в космос запустить. А давайте так же сделаем?" И сделали.
Вообще идея прикольная, ну знаете так, чтобы услышать и никогда не трогать. Вместо того, чтобы полить все маслом под названием "задержка до луны и обратно", здесь решили дать возможность конфигурировать все и вся. Вот у тебя вход, можешь руками показать куда ему идти, вот тут в конфигах лично для него написать sample rate, bit depth, формат данных, длину окна периода, headroom и использовать ли mmap или нет (jokes on you но я в какой-то момент реально подумал, что для меня фикс был в этом).
Короче классический линукс, ничего удивительного.
А, нет, нет же! Удивительно то, что даже из коробки оно работает, работает намного лучше PulseAudio (по задержке), и одной строчкой в конфиге делается еще лучше! Жаль, что до задержки сырого ALSA так и не дошел.
(Нет, я не сделал это все за 5 минут, потому что выбрал не тот, сцука, тип инпута со звуковухи, он ТРЕЩАЛ, но просто сменой типа он ПЕРЕСТАВАЛ)

А в других системах то что?
А я и не знаю. Про мак вообще ничего не знаю, но на винде есть тоже свой "протокол" ASIO, который по сути ближе просто к сырому ALSA: вот устройство, у меня все; но при этом ASIO имеет какое-то микширование где-то, так что видимо ближе к JACK. Но вот что я знаю точно, что на ASIO нельзя записывать с одного устройства, и выводить звук на другой, даже с небольшой задержкой. Либо стандартные протоколы и секунды задержки, либо только 1 устройство. А на линуксе я могу спокойно записывать гитару со звуковой карты, а выводить на колонки ноутбука!

И зачем мне это все?
А я шо, я тоже не знаю. Я тоже знать этого не хотел 5 часов назад, я просто хотел записать гитару. А теперь вот тут сижу пост дописываю.
Как говорил мой дед, the more you know, the more you know.

They've literally called this "wireplumber" and say "linux audio is fine"

Люди из гугла сделали "фронтэнд" вокруг гита, который по первым впечатлениям выглядит очень хорошо
https://github.com/martinvonz/jj
Я сам давно смотрел на https://pijul.org/, но меня отторгало то, что для него нужна полностью своя экосистема (система PRов, CI/CD, сайтик, где можно смотреть репу в браузере и т.д.)
А тут с одной стороны вдохновлялись лучшими дизайнами других VCS, а с другой в результате у тебя все та же гит репа, которую ты можешь пушнуть на гитхаб

Главная разница:
вместо того, чтобы работать "на текущем коммите, который находится внутри ветки", и добавлять "новый коммит на основе старого коммита, который находится в доме который построил Джек внутри ветки",
вы работаете с "изменениями", которые не привязаны к чему-то. Просто какой-то дифф. Эти изменения можно потом чейнить/мерджить между собой, и "тегать" в ветки

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

Ну и в добавок нормальный UI (The user interface is not only reasonable but actually really good: an idea borrowed from… literally every VCS other than Git) и quality of life фичи (тот же working copy автоматически коммитится, то есть никаких больше git stash && git checkout XXX && git pop)

Если хотите начать, есть довольно подробный гайд: https://v5.chriskrycho.com/essays/jj-init/

disclaimer: я пока только почитал про jj, и попробовать не успел, поэтому могу где-то врать

Blazingly 🔥 fast 🚀 memory vulnerabilities, written in 100% safe Rust. 🦀
https://github.com/Speykious/cve-rs

Нашли багу Красиво оформили старую багу в проверке лайфтаймов в компиляторе раста

TL;DR: в этом месте вся магия
https://github.com/Speykious/cve-rs/blob/main/src/lifetime_expansion.rs

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

И происходит там что-то такое:
Пусть есть два лайфтайма 'a, 'b. Если в функцию передавать двойную ссылку &'a &'b, то из этого следует, что 'b: 'a, т.е. 'b должен жить дольше, чем 'a (иначе, существует момент, в котором верхняя ссылка жива, а внутренняя - нет). Это похоже на множественные операции: 'a является подмножеством 'b.
Из этого следует, что в таком контексте конвертация &'b -> &'a является безопасной: как на множествах, 'a' является частью множества 'b`, и в расте (очевидно) можно конвертировать лайфтаймы в их "подмножества".
Это делает первая функция:

// val_a тут только для создания ограничений на лайфтаймы
pub const fn lifetime_translator<'a, 'b, T>(_val_a: &'a &'b (), val_b: &'b T) -> &'a T {
  val_b
}

И, как написано в комментариях, сама по себе она ничего не нарушает.

А дальше мы просто засовываем вместо val_a переменную с &'static &'static лайфтаймами ('static по сути значит, что переменная живет все время выполнения программы, например, такой лайфтайм у констант). И тут компилятор ломается, и почему-то не проверяет, что вызов функции lifetime_translator невалидный. Это довольно важное замечение: сама функция валидна, но этот конкретный вызов - нет. У функции есть ограничения на лайфтаймы, и мы их по факту не прошли, но компилятор при этом не поругался.

Компилятор должен сделать две вещи:
Подставить вместо 'b минимальный лайфтайм из val_a и val_b, а потом проверить, что 'b: 'a. Но из-за того, что ограничение на лайфтаймы написано не явно, а через двойную ссылку, то компилятор делает эти две вещи отдельно: сначала проверяет, что двойная ссылка валидна (условие 'b: 'a), а потом подставляет лайфтайм, и на этом как раз и ломается

Все, раст сломали, возвращаемся в плюсы?
Конечно же нет, с точки зрения математической модели тут очевидно есть ошибка, и по сути тут просто обычный баг в компиляторе, что он что-то не проверил/проверил неправильно.
Думаю, скоро пофиксят. UPD: Проблема эта старая и давно известная. К сожалению, комплиятор внутри довольно сложно устроен, и просто "закостылять" такую ошибку довольно сложно. Поэтому коммьюнити ждет, когда некоторые большие изменения во внутренней работе компилятора будут вмержены (основная - новый trait solver), и либо эти изменения сразу пофиксят эту проблему, либо на основе них будет намного проще

P.S. а еще там очень забавная лицензия