Это первый стабильный релиз, который идёт в двух ABI (Application Binary Interface), кроме привычного GNU toolchain добавлена поддержка MSVC. Последний доступен пока в 64-битной версии, но я пользовался 32-х битным в nightly версии намного раньше, хотя официальная поддержка намечена на версию 1.6. Как бонус: теперь корректно обрабатывается перенос строки в windows-стиле, например, в BufRead.
Из других особенностей:
Можно использовать псевдонимы в множественном импорте:
use foo::{bar as kitten, baz as puppy}
Окончательно доломали:
pub extern crate
Это хорошая новость, так как экспорт внутреннего крейта, как минимум нарушает закон Деметры. Если нужно использовать структуру внутреннего крейта, ещё лучше явно экспортировать. А зачем это вообще нужно?! Если вы используете с внешней библиотекой разные версии крейтов, и попробуете её «накормить» инородным типом (например, набор полей в структуре поменялся), то всё сломается.
Исправлены ошибки с (пример, пока не залили 1.4 можно увидеть разницу на Stable)
&'static mut
Статическое время жизни было не так хорошо проработано ранее, и можно было обмануть строгие правила компилятора с правами на переменную.
Много изменений сделали в стандартной библиотеке. В основном по стабилизации, но есть некоторые улучшения, например, HashMap теперь реализует трейт Extend<T: Copy>. Ещё std::io::copy теперь умеет работать с типами, размер которых неизвестен при компиляции.
Cargo стал немного разговорчивее:
[cargo]$ cargo update
Updating registry `https://github.com/rust-lang/crates.io-index`
Updating libc v0.1.8 -> v0.1.10
Updating memchr v0.1.3 -> v0.1.5
Updating num v0.1.26 -> v0.1.27
Updating rand v0.3.9 -> v0.3.10
Updating rustc-serialize v0.3.15 -> v0.3.16
Кстати, я обновляю зависимости своих проектов раз в неделю, и всегда появляется что-то новое, это приятно, чувствуешь, что сообщество Rust живёт и развивается, но главное, от этого больше ничего не ломается.
Следующий релиз намечен на 10 декабря 2015: в этом году Дед Мороз принесёт подарки программистам на Rust чуть раньше )
Комментарии (33)
ozkriff
30.10.2015 09:14+1О! Result::expect наконец-то стабилизировали, это приятно.
deko
30.10.2015 10:08Согласен! Некоторые другие возможности тоже хочется видеть стабильными (плагины компилятора, например, но это пока всё ещё довольно сырое).
Что касается Result, заметил интересную особенность: если никогда не делать unwrap, код очень выигрывает в качестве, так как приходится явно продумать как Result дойдёт до верхушки стека. Это привело к тому, что код на Rust для меня теперь является эталонным в проекте, все протоколы описаны в нём и я получаю подробнейшее указание, где была ошибка в одном лаконичном сообщении. Скорость решения любой проблемы удивительно высокая. Да, и больше не требуется пугать системных администраторов трассировкой исключений.ozkriff
30.10.2015 10:22Тут от специфики программы зависит. Я вот, например, игру пытаюсь писать и меня полностью устраивает во многих случаях при возникновении ошибки просто сразу грохнуть все приложение. Ну и о причине написать в консоль, для чего expect и нужен.
deko
30.10.2015 10:31Игра — это интересно! Пока не удалось опробовать пласт графических и звуковых библиотек. Какие библиотеки используете? Быстро ли работают? Какие есть недостатки в их реализации?
ozkriff
30.10.2015 15:22+1https://github.com/ozkriff/zoc — вот, прототипчик, давненько уже ковыряю черепашьими темпами.
Звук пока не трогал совсем.
Для создания окна и получения ввода использую glutin (https://github.com/tomaka/glutin) — отличная библиотека, работает даже на андроиде, к ней претензий не возникало никаких.
Для вывода графики использую свои обертки (https://github.com/ozkriff/zoc/tree/f874c9e/src/zgl/src) над голым gl-rs. Обертки кривые, сто лет назад их еще написал). Думаю переписать все на glium (https://github.com/tomaka/glium) — тоже отличная библиотека, только уж очень долго компилируется и сильно увеличивает время линковки проекта, на скорости рендеринга особо не должна сказываться.
Для 3д математики использую cgmath-rs (https://github.com/bjz/cgmath-rs), вроде как он немного для игр лучше подходит, чем nalgebra (https://github.com/sebcrozet/nalgebra), хотя последняя тоже неплоха.
Для вывода текста накидал небольшую обертку над stb_truetype — https://github.com/ozkriff/stb-tt-rs и сделал простенький кэш глифов — https://github.com/ozkriff/zoc/blob/f874c9/src/zgl/src/font_stash.rs. Вроде, терпимо работает.deko
30.10.2015 17:10Походил по ссылкам, честное слово, узнал много нового. Проект получился не маленький совсем. Есть, что скомпилировать на выходных )
Есть статистика, сколько FPS удаётся выжать?ozkriff
31.10.2015 09:47Не знаю, если честно, сколько оно там сейчас кадров выдает — мне до оптимизации отрисовки еще далеко, сначала бы сделать это все играбельным.
ozkriff
31.10.2015 13:00Если интересно состояние ржавчины для написания игр, то вот еще хорошая и относительно свежая ссылка с мнением Tomaka (автором нескольких вышеупомянутых библиотек) — https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859.
deko
31.10.2015 17:57Спасибо. Фронт работ в направлении игр, конечно, ещё большой, хотя базовые вещи, действительно закрыты.
mkpankov
Из других новостей: на 1.3 racer собирался 4:45 на моей машине, на 1.4 — 3:57. Один мой проект собирается теперь за 1:00 вместо 1:14. Примерно 20% ускорения в обоих случаях.
Что радует, ускорения компиляции примерно такого масштаба происходят в каждом релизе.
erlyvideo
вы уже в продакшне его?
deko
В продакшене можно и нужно, но пока не всё, например, веб-сервер hyper болеет этим: github.com/hyperium/hyper/issues/368
Проблема вроде бы решена, но просто таймаутом, который и то, добавили недавно в стандартную библиотеку, 10К так не решить. Для последнего есть MIO, который весьма хорош. Драйверы БД тоже иногда болеют багами, но в целом всё можно исправить самому, честное слово, git clone && cargo build и у вас все готово к отладке внешнего проекта. Код всегда строгий и простой, так что проблем разобраться в чужом коде точно не будет.
erlyvideo
очень завораживает, если честно.
Хотим заюзать раст внутри эрланга, пока вокруг да около ходим.
deko
Мы начинали как раз с того, что написали несколько расширений для проекта на Erlang + С. Постепенно проект на Rust поглотил проект на Erlang (на последнем кусок был небольшим). В результате получилась такая штука: чтобы написать хорошее расширение на Rust нужно погрузиться в unsafe, что-то хорошо сделать в unsafe совсем не просто, это не самая комфортная зона языка, придётся много колдовать с Box, Cell, Rc. Rust очень многое хранит в стеке, и тут легко что-нибудь перепутать и потерять данные (язык без GC, всё мгновенно режет, да и в стеке ничего надолго не сохранишь). В зоне unsafe язык просто промолчит и разрешит всё уничтожить.
Другими словами, чтобы хорошо написать расширение пришлось основательно изучить Rust, но изучив захотели попробовать его для всего проекта.
В итоге: в проекте есть прирост по скорости в целых 16 раз. Задача — имитационное моделирование. Много CPU-bound, не так много IO. Может потому и такой прирост. Программа просто стала монолитом на системном языке. На C++ по скорости был бы тот же результат. Но с блэкджеком хотелось…
erlyvideo
ну ёлки, на C++ вы бы по пути повесились от сегфолтов и стектрейсов =)
Очень интересный результат, спасибо.
Судя по вашему описанию, действительно у вас не про эрланг была задача.
erlyvideo
мы хотим кусочек кода попробовать перевести на раст, но не уверены в результате.
Сейчас есть медленная и работающая реализация на эрланге, есть побыстрее в полтора раза и в 4 раза лучше по памяти реализация на С.
Смущает малое ускорение куска на С (я ожидал раз в 5) и не очень понятно, что в нём медленного, но самое главное: на С переползать страшно, потому что это сегфолты. Поэтому хочется пощупать раст.
deko
Прирост скорости, действительно, спрогнозировать сложно. Но если он был маленький на C, то возможно просто упёрлись в возможности ОС, а прослойка над ней была довольно маленькая. Например, отдавать видео-поток, по скорости примерно все одинаково: nginx = go = python = rust = erlang = с, так как во всех случаях будет использоваться sendfile, и в нём программа будет находиться 70-80% времени. Тут ускорить не получится, к сожалению. С другой стороны в Rust полный контроль над памятью и реально без сегфолтов, это на случай транскодера.
erlyvideo
про sendfile неверно. Это старый миф про его крутость, который не хотят проверять.
Разница, безусловно, есть, потому что при раздаче видео происходит куча другой работы по перепаковке контейнеров, учету сессий и т.п. Это и отличает примитивные реализации видеостриминговых серверов от более фичастых.
deko
Если, действительно, прокачать фишками, то работы для языка побольше, конечно. Тут точно Rust хорошо ляжет. Сам язык/компилятор к продакшн точно готов, а вот во внешних библиотеках слегка будет дефицит функционала, иногда ошибки. До полной практической прокачки лэнда осталось всего месяцев 6-10. Спустя этот период писать будет чуть полегче, но я думаю сейчас самое время испытать все это добро на опережение. На изучение самого языка уходит не мало времени, месяца 2 минимум, при опыте в С, Java, Erlang, хотя поначалу он кажется очень простым, прочитать учебник без перерывов на еду мне удалось ровно за день. Потом долго будет ощущение, что вроде пишите и много пишете, но будто топчитесь на месте. Потом приходит озарение как всё правильно сделано и желание выкинуть всё остальное с GC.
Кстати, а как конфигурируется сервер? Скриптом на мини-языке или конфигом?
erlyvideo
у нас конфигурация была вольная, но выкинули и перешли на строгий валидируемый конфиг. Я могу немало рассказать, почему это правильно и полезно, но это будет неприятно читать, потому что аргументы сведутся к «люди не читают документацию, а нас задолбало отвечать на одни и те же вопросы»
Zelgadis
Ну как это. sendfile крут когда файл уже в кэше. Насколько я помню линуксовская реализация sendfile не умеет SF_NODISKIO, поэтому senfile может перестать быть крутым.
erlyvideo
невозможность внятно определить наличие файла в кеше делает sendfile непредсказуемым, а следовательно непригодным для контроля за высокими нагрузками.
Zelgadis
Просто надо выбирать правильную ОС для нужной задачи. Netflix например использует sendfile, а все потому, что в ОС которую они используют есть AIO и SF_NODISKIO.
erlyvideo
И зачем менять ОС с поддерживаемой и популярной на фрибсд, под которую осталось три админа в нашем полушарии?
Zelgadis
Чтобы использовать правильный инструмент для задачи. Впрочем мой комментарий был только о том, что senfile унылый только в некоторых ситуациях и только на Linux. Другая проблема с sendfile вне FreeBSD еще с использованием TLS.
erlyvideo
а во фре tls в ядре для sendfile?
Zelgadis
bulk encryption ядерный в 11-CURRENT (ветка которую netflix в продакшене использует). Сессия устаналивается в user space, ядро только шифрует данные. https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
mkpankov
Я с вами не спорю, но хочется уточнить один момент: проверки Rust в unsafe не отключаются. Есть ровно три вещи, которые разрешаются дополнительно только в unsafe: разыменование сырых указателей, вызов опасных функций, и доступ к изменяемым статическим данным. Есть довольно большой класс поведения, которое считается не определенным и которое недопустимо даже в unsafe, но есть и поведение, которое явно не считается небезопасным и называется вместо этого «нежелательным» (например, утечка памяти).
deko
Полностью согласен. В unsafe очень помогло заходить под GDB. Некоторые абстракции работы с кучей довольно хитрые и не всегда очевидно, что под ними лежит. Часто исходный код Rust очень помогает.
Halt
А вы не могли бы ваш опыт оформить в виде статьи? Очень интересно почитать про реальное применение языка и особенно про проблемы, с которыми столкнулись по пути.
deko
В действительности, пока дошли до релиза по ряду вопросов сформировалось мнение, которое иногда отличалось от первого впечатления. Я думаю написание статьи — это хорошая идея, постараюсь найти время.
alist
Я гоняю в продакшене на одном проекте, но там на расте только кусок, который как библиотека подключен в остальное приложение. Кусок просто перерабатывает данные и делает по ним статистику определенного рода. Работает хорошо, нареканий нет, добились снижения по потреблению памяти без проседания производительности, хотя это не было какой-то целью.
Делать сервер целиком на Расте я бы не стал, а вот на уровне extensions для Node, Python, Ruby он заходит очень хорошо.
mkpankov
Нет, пока ещё нет.