Comments 25
Я тут подумал, что на хабре довольно много сочувствующих ржавчине, но не прям сильно следящих за происходящим в экосистеме (не подписанных на TWIR?).
Так что вот держите очень субъективный срез основных ржавых новостей за последние шесть недель.
(Большая часть ссылок ведет на темы в /r/rust, потому что я считаю его главным информационным узлом ржавого сообщества и там в комментариях можно наткнуться на кучу всего занятного.)
Активно идет подготовка к выпуску Rust 2018. На ночном канале уже можно начинать пробовать как оно вживую.
Заметно ожила работа над "кулинарной книгой" (cookbook) — сборником рецептов для решения конкретных задач. Добавилась пачка новых разделов и примеров.
CTO студии Ready at Dawn (список игр) сообщил, что студия переходит на Rust во всех новых проектах. План состоит в постепенной замене всех модулей на ржавые, с изначальным сохранением C API для интеграции со старыми модулями.
Так же, представитель R&D отдела Electronic Arts заявил что они используют Rust как основной язык уже 4-5 месяцев.
Был опубликован занятный отчет о результатах фаззинга популярных ржавых пакетов + разборе найденной уязвимости. TLDR: В целом Rust пакеты выдерживают фаззинг намного лучше библиотек на Си, но сообщество пока что прикладывает маловато усилий для вытравления неоправданных unsafe блоков и паник из кода.
Кстати об unsafe — много внимания привлек к себе веб фреймворк actix-web, в котором (внезапно для многих) нашли много не очень оправданных unsafe блоков и даже некоторые реальные UB. Правда, говорят что большую часть уже исправили совместными усилиями.
Между тем, Ockonal опубликовал отчет об использовании actix-web на музыкальном фестивале Atlas Weekend.
Ржавое сообщество продолжает уделять много внимания WebAssembly, например:
- Статья "A web application completely in Rust" (хаброперевод)
- Опубликован js-sys пакет
- Клабник размышляет, является ли wasm аналогом java апплетов или flash'а (хаброперевод)
Кстати, у рабочей группы rustwasm есть свой еженедельник: https://rustwasm.github.io
Microsoft заявили что используют ржавчину для части Azure IoT функциональности — https://github.com/Azure/iotedge/tree/master/edgelet
Физический движок nphysics обзавелся новой документацией и онлайновыми демками
Ребята из Jetbrains активно улучшают расширение для работы с растом. Вот заметка из журнала CLion с пачкой демонстрационных гифок.
Clippy (статический анализатор) теперь доступен как компонент rustup, т.е. можно перестать собирать его из исходников \o/. Пока доступно только в ночнике, но скоро и до stable доползти должен.
Возможно стоило такой обзор отдельным хабропостом сделать. )
Как уже существующий This week in Rust, только реже. Как насчёт This month in Rust?
А вот выбирать интересные новости за месяц, с прицелом на рекламирование языка и важных изменений в сообществе (что нам и продемонстрировал ozkriff), будет как раз то что надо.
А расскажите про аллокаторы поподробнее. Определять #[global_allocator]
можно только в конечном бинаре или в либе тоже? И что будет если несколько либ попробуют это сделать?
Определять #[global_allocator] можно только в конечном бинаре или в либе тоже?
Можно и в конечном, и в зависимостях (если очень надо):
It should be emphasized that in most cases, the "terminal" crate (i.e. the bin, cdylib or staticlib crate) should be the only thing selecting the global allocator. Libraries should be agnostic over the global allocator unless they are specifically designed to augment functionality of a specific allocator.
( ^ из RFC — http://rust-lang.github.io/rfcs/1974-global-allocators.html )
И что будет если несколько либ попробуют это сделать?
Если во всей сборке (включая и твой пакет, и все зависимости) есть больше одного #[global_allocator]
, то сборка сразу грохается, даже если используются одинаковые типы. Пример сообщения при наличии двух пакетов a
и b
, переопределяющих аллокаторы на системный:
error: the #[global_allocator] in a conflicts with this global allocator in: b
Спасибо.
Хотя возможность определять аллокаторы в либах всё-таки (для меня) выглядит странно, но может это от недопонимания.
Таким образом можно делать маленькие крейты, включающие нужный аллокатор, чтобы не писать boilerplate. Аналогичный пример — реализация паники (см. https://crates.io/keywords/panic-impl)
Если хочется максимально прямой и unsafe доступ к OpenGL, то есть пакет gl-rs.
Если хочется "более ржавого" GL, то обычно вспоминают о двух пакетах: glium и gfx-rs.
При этом наблюдается уход от OpenGL в сторону Вулкана — glium
автор вообще перевел в режим зомби, полностью переключившись на работу над vulkano, а gfx переживает масштабное переписывание, что бы быть ближе к новым низкоуровневыми апи и OpenGL бэкенд будет поддерживаться только как "второсортный".
А, еще забыл https://github.com/phaazon/luminance-rs. У него есть занятное и относительно непредвзятое сравнение с альтерантивами: https://phaazon.net/blog/luminance_comparing
Боюсь, ничего краткого по вулкану в приницпе написать нельзя. :) Ну и у меня самого желания руками писать непосредственно на вулкане, без прослоек, не много.
Могу дать ссылки на вводные уроки по Vulkano — http://vulkano.rs/guide/introduction — и на репозиторий с примерами — https://github.com/vulkano-rs/vulkano-examples (triangle, в принципе, вполне читабельный).
Дело в том, что меня привлекает высокая скорость этого языка и я хотел бы его использовать с OpenGL или с Vulcan.
Можете вот здесь посмотреть примеры использования OpenGL из Rust напрямую (с помощью gl-rs): https://github.com/bwasty/learn-opengl-rs
А эта библиотека предоставляет прямой доступ к Vulkan: https://github.com/MaikKlein/ash
Вот вам простейший пример вулканического кода, выводящего на консоль свойства первого устройства:
#[macro_use]
extern crate ash;
use ash::{vk, Entry, Instance};
use ash::version::{EntryV1_0, InstanceV1_0, V1_0};
use std::ptr;
use std::ffi::CString;
struct Vulkan {
entry: Entry<V1_0>, // Must have the same lifetime as the instance
instance: Instance<V1_0>,
}
impl Vulkan {
fn create() -> Self {
let entry = Entry::new().unwrap();
let app_name = CString::new("Vulkan test").unwrap();
let app_info = vk::ApplicationInfo {
p_application_name: app_name.as_ptr(),
s_type: vk::StructureType::ApplicationInfo,
p_next: ptr::null(),
application_version: 0,
p_engine_name: app_name.as_ptr(),
engine_version: 0,
api_version: vk_make_version!(1, 0, 36),
};
let instance_info = vk::InstanceCreateInfo {
s_type: vk::StructureType::InstanceCreateInfo,
p_next: ptr::null(),
flags: Default::default(),
p_application_info: &app_info,
pp_enabled_layer_names: ptr::null(),
enabled_layer_count: 0,
pp_enabled_extension_names: ptr::null(),
enabled_extension_count: 0,
};
let instance: Instance<V1_0> = unsafe { entry.create_instance(&instance_info, None) }
.expect("Instance creation error");
let physical_devices = instance
.enumerate_physical_devices()
.expect("Physical device error");
let physical_device_properties = instance
.get_physical_device_properties(physical_devices[0]);
println!("{:#?}", physical_device_properties);
let physical_device_features = instance
.get_physical_device_features(physical_devices[0]);
println!("{:#?}", physical_device_features);
Vulkan {
entry,
instance,
}
}
}
impl Drop for Vulkan {
fn drop(&mut self) {
unsafe {
self.instance.destroy_instance(None);
}
}
}
fn main() {
Vulkan::create();
}
[package]
name = "vulkan_test"
version = "0.1.0"
[dependencies]
ash = "0.24"
Есть довольно качественные привязки к сишному sdl2, это довольно проверенный способ звуки издавать.
Есть идиоматичная обертка над OpenAL — alto.
Есть максимально ржавый rodio, им пользуются игровые движки аметист и ggez.
Может еще что достойное в https://crates.io/keywords/audio и https://crates.io/keywords/sound найти можно, я не сильно со звуком работал.
Выпуск Rust 1.28