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++?

Rust в Dropbox

Как мне кажется, не так давно произошло довольно знаковое событие для мира C++: Dropbox заявил о том, что перевел часть своей инфраструктуры на компоненты написанные на Rust. Чуть позже программисты из Dropbox ответили на вопросы интересующихся посвященные этой миграции. Немного интересных ответов:

> Are you happy using rust ?
Yes, overall the team has been very pleased with it. Compile times are the only serious complaint.

> How many lines of rust code are you using in production?
About 60k of our own, about 300k incl crates.

> Are you using nightly? or just stable version of rust?
We’re pinned to a particular nightly right now, as we rely on a fair amount of features that are still stabilizing. I imagine we’ll be on a stable by this summer.

> What drove the move to Rust precisely? Most of the players in the industry are somewhat reluctant about moving to Rust.
Well, we basically needed C++, but:
1) Dropbox doesn’t have a strong C++ ecosystem on the backend, and it takes a lot of work to build one.
2) Given (1), we had basically a blank slate, and our team is C++ and Haskell type folks, we decided to use Rust so we could get C++ with better type safety and fewer sharp corners.
So realistically, if we had been at a place with an awesome preexisting set of C++ libraries, practices, etc, we probably never would have used Rust.

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

Генератор CMakeLists.txt файлов

Довольно часто возникает необходимость быстренько написать тестовое приложение на C++ и опробовать в нем что-то. IDE я не слишком люблю, а каждый раз где-то выискивать завалявшийся шаблон к CMake-у довольно лениво. После очередных поисков запилил небольшой вспомогательный скриптик (само собой на Python) для генерации CMakeLists.txt.

На данный момент поддерживается только генерация приложений, как надоест конвертировать приложения в библиотеки, так будут и они генериться

Сам скриптик с руководством по использованию тут: https://github.com/astavonin/gen-cmake

Clojure & SQLite

С базами данных я не работал уже лет… 10 наверное. Само собой, мой старый опыт это ODBC, C++ обертки над ним и прочие реально страшные штуки. И тут я столкнулся с современными способами взаимодействия с базами данных и не в монстроподобном C++, а в изящной Clojure и обомлел! Все так просто, изящно, правда, потенциально, тормознуто Но про тормознутость это не более чем теория вызванная тяжелым C++ опытом, когда подозреваешь в плохой оптимизации все, что автоматически генерирует какие-либо сущности.

На мой неискушенный взгляд, поддержка баз данных в Clojure замечательная. Я ограничился довольно скромным набором состоящим из ядра org.clojure/java.jdbc, драйвера для SQLite org.xerial/sqlite-jdbc и библиотечки для работы с SQL в Clojure-стиле java-jdbc/dsl. Continue reading

Правильно выбранный инструмент творит чудеса

Сегодня мне попалась на глаза замечательная заметка о том, что мессенджер, с более чем 900 миллионами пользователей, пишет команда из, внимание, 50 человек! Да, именно 50, а не 500 и не 1500, как можно было бы ожидать. При этом, пишется сие чудо (серверная сторона, само собой) на Erlang. Не то что бы я огромный поклонник этого языка, но сама ситуация наводит на мысли о том, что правильный выбор инструмента может сильно сократить необходимое количество разработчиков. Continue reading

Как уехать в…

В последнее время довольно популярной темой на РСДН-е стал вопрос “как уехать в …”, хотя в большинстве случаев он больше похож на “как уехать из РФ”. Как мне кажется, у меня действительно есть что сказать по этому вопросу, все же переездов у было мягко говоря не мало. Если коротко, то вырос я в Бишкеке, после этого работал в Алмате откуда переехал в Москву. Из Москвы я отправился в Сувон, Ю.Корею, откуда вернулся в Москву. Сейчас я пишу эту заметку из Сингапура и, с довольно большой вероятностью, этот город может оказаться не последним в списке переездов. Что довольно важно, только первый “понаезд в Москву” был сделан за мой собственный счет, все остальные переезды полностью оплачивались работодателем.

Continue reading

Обработка исключений в Clojure

Одной из основных претензий к Java у меня всегда была её “многословность”. Особенно эта многословность раздражает в обработке исключений, где сравнительно небольшой участок кода часто обильно сдабривался “соплями” обработки исключений. Разнообразные среды типа IDEA эту многословность позволяли в той или иной степени сгладить в процессе написания кода, но, к сожалению, она никуда не девалась из кода уже написанного и мозолила глаза. Как эту радость прятали в Scala я уже не помню, т.к. язык мне показался мало пригодным для моих нужд, а вот варианты доступные в Clojure мне очень даже понравились.
Исключения в Clojure, по логике работы с ними, можно разделить на две группы. Первая группа – это исключения возбуждаемые Java-библиотеками. Для примера возьмем функцию выполняющую запрос HEAD:

(defn test-fn [url]
  (client/head url)
  )

Continue reading

Конфигурации

Со всех сторон нас окружают файлы конфигураций. Иногда, это просто некий набор значений по умолчанию, который читается на старте и пишется при изменениях. Такой тип конфигураций обычно оказывается в более-менее приемлемом и читабельном виде вне зависимости от его формата. Но периодически приходится сталкиваться с довольно странной формой извращения – “программирование на конфигурациях”. Обычно для этих целей берется совершенно не пригодный инструмент, например XML файл или, что еще хуже, база данных и придумывается загадочный псевдоязык для скрещивания логически не совместимых вещей.
Continue reading

C++XX в CMake

Вообще я очень люблю использовать CMake для создания различных небольших тестов. Собирается везде, ручной работы ощутимо меньше, чем если писать правила для Make, генерируется поддержка для любой IDE (если тестик в что-то более крупное перерастет и т.д). И как-то меня угораздило “проспать” как CMake 3.x так и довольно полезную фифу в нем – простое и понятное подключение поддержки C++11. Я всегда подключал C++11 по старинке:

list( APPEND CMAKE_CXX_FLAGS "-std=c++11")

Но, оказывается-то, прогресс шагнул далеко вперед! так что для тех кого так же как и меня “заморозили” сообщаю – все стало проще и понятнее:

cmake_minimum_required(VERSION 3.1 FATAL_ERROR) # (1)
project(cpp11_test)

add_executable(cpp11_test main.cpp)

set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD 11)          # (2)
set_property(TARGET ${PROJECT_NAME} PROPERTY CXX_STANDARD_REQUIRED ON) # (3)

Прекрасная фича доступна начиная с CMake 3.1 1 и включается она 2 очень просто. Если какие-то обходные пути при отсутствии у компилятора поддержки C++11 не планируются, то стоит объявить 3 наличие поддержки C++11 обязательной.