Rust и Я

У меня, как наверное и у многих других C++ разработчиков какие-то сложные отношения с Rust. Этот язык вроде как и очень сильно нравится и в то же время всё сложно. На сей раз моя попытка заняться Rust в серьез зашла куда дальше чем обычно (обычно я после нескольких небольших тестиков удовлетворенно забрасывал изучение) – я нашел компанию которой нужны Rust разработчики, связался с ними и взял тестовое задание. Тестовое задание просто восхитительное, не сложное, но помогает понять главное – хочешь ли ты связываться с языком или нет?

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

Box::new(tcp.map(move |stream| {
    let (sink, stream) = stream.framed(Bytes).split();
    pool.execute(stdin.forward(sink).then(|result| {
        if let Err(e) = result {
            panic!("failed to write to socket: {}", e)
        }
        Ok(())
    })).unwrap();
    stream
}).flatten_stream())

Несколькими месяцами раньше я баловался с биндингами к libClang, где было всё читабельно и очевидно, что наводит на мысли, что написать на Rust можно писать как в адекватном и легко поддерживаемом стиле, так и городить write-only код в духе приведенного выше. И надо отметить что в примере выше чувствуется и стиль и задумка. Если в него какое-то время повтыкать (желательно в IDE с навигацией, очень рекомендую IntelliJ Rust), то становится понятно что хотел сказать автор и почему. Только вот “НУ ЗАЧЕМ?!?!” не покидает.

В итоге мне в очередной раз стало казаться, что за пределами небольших сообществ гиков Rust взлететь не может, так как поддерживать столь неочевидные решения должно быть даже дороже чем решения на C++ с ручным управлением памятью (в конце концов, санитайзерами можно отловить практически всё). Не знаю чем это вызвано, скорей всего тем, что Rust развивает комьюнити гиков, а C++ комитет старперов. В результате в Rust тянут все, что круто выглядит, а в C++ только то, что “мегамозги” одобрили. Побочным эффектом этого выступает то, что в Rust многие удобные вещи доступны сразу или почти сразу, а в C++ это “наверное будет реализовано после C++20” (да-да, это я про Meta).

Наверное, меня всё равно не отпустит и баловаться с Rust я не перестану. Но вот подаваться на позицию “Rust разработчик” я довольно долгое время точно не буду, сообщество должно наиграться в “zero cost abstractions” для начала

FFI и Rust

Продолжаю бороться с типами. Есть надежда, что FFI (Foreign Function Interface) – это самая сложная и последняя часть, где система типов в Rust будет доставлять серьезные неудобства. Пока что, главное выстраданное правило гласит: если тебе Rust не дает написать какую-то конструкцию, то эта конструкция зло. То есть не надо пытаться обмануть систему типов и писать “как привык в C++”. Довольно простой, если верить документации на сайте Rust, интерфейс FFI оказался с заковырками. Даже пришлось создать маленькую песочницу для игр именно с FFI.

Наверное самая поразившая меня фича в этой области Rust-а – преобразование типов, особенно при работе с массивами. Простейший пример (type_of из предыдущего поста):

let array: &[u8] = unsafe { mem::transmute("Rust") };       // (1)
println!("type: {}, ptr: 0x{:x}, len {}",
    type_of(&array), array.as_ptr() as u64, array.len());

let new_array: &[u32] = unsafe { mem::transmute(array) };   // (2)
println!("type: {}, ptr: 0x{:x}, len {}",
    type_of(&new_array), new_array.as_ptr() as u64, new_array.len());

Классический вопрос из разряда “а что оно напечатает?”. Кажется что всё невероятно просто, создаем массив 1 из uchar, размер которого будет 4. Конвертируем 2 массив uchar в массив uint32 с размером 1. В итоге лично я ожидал чего-то такого:

type: &'static [u8], ptr: 0x1037a1414, len 4
type: &'static [u32], ptr: 0x1037a1414, len 4

Но был сильно удивлен. Дело в том, что по мнению компилятора Rust второй массив хоть и является массивом uint32, но по прежнему содержит 4 элемента, т.е. конверсия делается в лоб и только для типа, но не размера и физический размер “вырос” в 4 раза без перераспределения памяти.

При этом вроде как правильное решение будет выглядеть следующим образом:

let new_array_2 = unsafe {
    slice::from_raw_parts_mut(array.as_ptr() as *mut u32,
        array.len() / mem::size_of::<u32>())
};
println!("type: {}, ptr: 0x{:x}, len {}",
    type_of(new_array_2), new_array_2.as_ptr() as u64, new_array_2.len());

Хотя меня гложут сомнения на тему того, что я правильно всё делаю, так как вывести новый размер массива вроде очень просто из чего следует что я вызвал какую-то неправильную функцию, или правильную, но криво…

Мелкие пакости: время жизни переменной в Rust

Допустим, хочется получить текстовое представление типа переменной в Rust. При этом в язык входит такая замечательная функция как type_name() -> &’static str принимающая тип выдающая его тектовое обозначение. Само собой, хочет применить его не только для типа (название типа не так уж и полезно в диагностических целях), а к переменной. Логичным для C++ разработчика выглядит приблизительно следующее решение:

fn type_of<'a, T>(_: T) -> &'a str {
    unsafe { std::intrinsics::type_name::<T>() }
}

Но тут возникнет довольно занятная проблема, так как переменная становится недоступной после (с некоторыми ньюансами в зависимости от типа) получения её имени:

error: use of moved value: `*variable_name` [E0382]

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

fn type_of<'a, T>(_: &T) -> &'a str {
    unsafe { std::intrinsics::type_name::<T>() }
}

Вообще, все эти мелкие пакости модели памяти постоянно преследуют при программировании на Rust. Никак не могу понять, это реально зло или я просто еще не привык и просто мыслю моделью памяти C++?

Как бороться с динамической типизацией?

Я довольно часто писал на Python какие-то вспомогательные вещи, иногда сравнительно крупные, но почти всегда не знание типа объекта с которым работаешь было не критичным. Плюс возможность разрабатывать в IPython сильно облегчала жизнь. И так было до тех пор, пока я не решил плотно использовать Twisted. И оказалось что в IPython не попишешь нормально, а занание типов параметров в функциях обратного вызова и классов из обширного становится необходимостью.

И вот тут то я оказался в неком тупичке. Есть большое количество разнообразных классов со сложными интерфейсами. Перепробованные IDE (Eclipse, PyCharm и даже Emacs) не позволяют воспользоваться автодополнением в незнакомых им классах, что логично. В результате, весь код начинает выглядеть как пример ниже.

def _call_later(self, request):
"""
тут какое-то описание функции
@param request: тут какое-то описание параметра
@type request: Request (1)
"""

Да, безусловно, указывать 1 для каждой из создаваемых функций типы передаваемых параметров это решение, только оно выглядит как откровенный костыль. В итоге, у меня создается ощущение, что я как-то не верно использую этот замечательный язык… Что не так? Как с этим жить? Наиболее подходящим вариантом выглядит то, что все помнят параметры у API наизусть, я же вполне могу писать на C++ с подстановкой параметров исключительно из открытых файлов.

Callbacks, closures и модель памяти Rust

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

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

Разрушающее сопоставление с образцом

В Rust используется разрушающее сопоставление с образцом, что в купе с моделью памяти Rust, иногда, дает очень занятные эффекты. Для примера возьмем структуру MyStruct и создадим две переменные типа Option в которых будет лежать наша структура, в одном случае 1 в виде стекового объекта, а во втором в виде уникального указателя 2.

struct MyStruct {
    val: int
}
let stack_data = Some(MyStruct{val:42});   // (1)
let own_data = Some(~MyStruct{val:42});    // (2)

Continue reading

Луч поноса авторам HomeBrew

Довольно давно, а если говорить точнее, то уже лет как 5 я использую MacPorts. Порты, конечно, не без багов, но все же они достаточно хорошо спроектированы и удобны в использовании. В них всегда можно найти несколько версий компиляторов и т.д. И тут, внезапно, мне понадобился HomeBrew. Да, я знаю, что писать пакеты для MacPorts трудно, а для HomeBrew легко. Да, я в курсе того, что заставить работать MacPorts через прокси не так уж и просто, а HomeBrew очень легко. Но…

КАКОГО ХЕРА HomeBrew требует что бы пользователь был Admin?! Что за жопорукий дебил это придумал?! Системное приложение ОБЯЗАНО уметь работать через sudo или каким-то иным способом повышать свои права!

Переменные окружения в OSX

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

Стандартный путь довольно прост: необходимо вписать в файл /etc/launchd.conf новые пути, следующим способом.

setenv PATH /new/path/a:/new/path/b

Собственно, я так делал всегда и все было нормально. Но, внезапно, а может и не очень, к примеру после какого-то обновления, ряд приложений (тот же Eclipse и Wireshark) перестал видеть что-либо за пределами переменных, прописанных в /etc/launchd.conf. В итоге, по мнению этого ряда приложений “исчезло” все, VJM, dir, ls да совсем-совсем все.

Гугла подсказала, что пользовательские переменные, которые должны стать доступны всем, можно добавить еще в пару файлов, например в /private/etc/paths. Формат файла прост: одна линия – один путь.

/new/path/a
/new/path/b

Слегка разочаровался в Scala

Когда-то, довольно давно, я взялся за поиск альтернативы для C++, который во все времена был и, как мне думается на данный момент, будет моим основным рабочим инструментом. Само собой, эта альтернатива мне была нужна не для того, что бы перейти в какую-то иную сферу, а для тех случаев, когда либо хочется написать что-то свое, либо нужно быстро создать какой-то прототип, проверить ту или иную концепцию. В такой ситуации JVM-based язык очень удобен и, по большому счету, безальтернативен, конкуренцию может составить разве что Python со своим простым синтаксисом и безграничным набором библиотек. Continue reading