Comments 30
MIR становится транслятором по-умолчанию и становится доступна инкрементальная компиляция
Не вводите народ в заблуждение! MIR в стабильном Rust 1.11 всё так же выключен по умолчанию, а включён он в Rust 1.12 beta, вышедшей в тот же день.
В целом релиз получился достаточно скромный, что говорит только об одном — заканчивайте уже ждать чуда и начинайте писать на языке — он уже давно стабилизоровался и годен к использованию.
Поправил, чтобы было понятнее, что имеется ввиду.
не удивлюсь если это приведет к большим изменениям в стандартной библиотеке
breaking changes? Сомневаюсь. Если они что-то и будут менять в стабильных интерфейсах стандартной библиотеки, то хорошенько пройдутся crater заведомо, чтобы точно никого не сломать. Так что бояться этого нет смысла.
Например, до сих пор не стабилизированы simd-интринсики и/или ассемблерные вставки
Это достаточно нишевые фичи, доступные в ночных сборках на крайняк. Так что "давно стабилизоровался и годен к использованию" вполне истинно для большинства прикладных задач.
Проблема кажется слегка надуманной:
другая работает в пару раз медленнее того что вы ожидали
Для вас это критичный по скорости участок кода? В одном из следующих релизов, когда SIMD/ASM стабилизируются, эта библиотека обновится и выдаст скорость на нужном уровне.
критичные участки кода написаны на Си
Так не все же, а только те, где нужен SIMD/ASM.
а для некритичных намного удобнее пользоваться языками со сборкой мусора
Rust — это не только более безопасная работа с памятью, а и вообще с ресурсами. Не говоря уже о явном контроле за ходом исполнения (control flow), отсутсвию null pointer exception, а также других особенностях языка, нацелленых на безопасность.
Если есть какие-то серьезные наработки + реальная перспектива использовать ржавчину "в продакшене", то, может, стоит отметиться в подобной теме: "Showcasing Rust in production; are you using Rust in production?"? Типа "нам очень хочется, но вот мешают такая-то и такая-то конкретные штуки". Как я понимаю, команда ржавчины тогда вполне может несколько перераспределить приоритеты задач. Все-таки каждая "история успеха" и организация-друг это большой бонус в продвижении языка.
не удивлюсь если это приведет к большим изменениям в стандартной библиотеке
обратно-совместимым же :)
Пару дней назад в ночные сборки добавили такую важную фичу как abstract return types, не удивлюсь если это приведет к большим изменениям в стандартной библиотеке.А где можно подробнее почитать? Все что я видел на эту тему, это давние ветки про impl Trait. Гугл тоже ничего свежего не дает.
Еее! Все по расписанию, круто! :-D
Я тут с месяц назад опять вернулся к относительно активной работе над своей игровой поделкой на ржавчине — https://github.com/ozkriff/zoc.
Рад быть полезным)
А вообще, там же в самом репозитории rusttype пример использования динамического текстурного атласа есть: https://github.com/dylanede/rusttype/blob/7d0664/examples/gpu_cache.rs
Мне этот атлас только не понравился тем, что очень сильно уж динамический — фактически, требует после любого малюсенького изменения заново всю геометрию перегенерировать.
Кстати, как вам gfx, стоит внимания в текущем виде?
Кстати, как вам gfx, стоит внимания в текущем виде?
Ну я три недели назад наконец-то переписал свою штуку с древних велосипедов на GFX и пока вполне доволен) Колебался между glium и GFX — оба, в принципе, неплохи, но у glium какие-то непонятные планы на будущее и он жестко завязан на GL2/3.
У GFX разве что хуже с документацией для новичков — чего-то актуального и близкого к http://tomaka.github.io/glium/book пока нет. Зато есть примеры, документация для основных типажей/структур и всегда можно спросить чего-то в https://gitter.im/ruRust/gamedev — меня устраивает)
Я под "новичками" подразумевал "не знакомый с этой библиотекой" скорее. Все-таки если более-менее знаешь ржавчину и имеешь кое-какой опыт с 3д графикой, то, кмк, по вышеописанным источникам знаний разобраться вполне реально.
Сомневаюсь, что GFX на текущем этапе развития ориентируется на полных новичков в 3д. Ну и библиотека все-таки еще не до конца устоялась — тоже аргумент против концентрации усилий на доках.
Вряд ликто-то спорит, что обширная документация не помешала бы, просто ее написание тоже трубет пропорционально обширных ресурсов, которых у основных авторов библиотеки сейчас нет :( .
удивленные ответы там от разработчиков — мол, а что, вам что-то непонятно
Хех, а можно подробнее? :)
Тут вариантов несколько. Скажем, если человек возмущается, мол, что нету доков вообще, то естественно никто не бросается описывать ВСЁ. Мы уточняем, где конкретно непонятно, чтобы с минимальными усилиями добиться максимального эффекта — хотя бы документацию прямо в коде подправить и уточнить.
Вы ж не подумайте, что мы ожидаем от всех, что наш API будет очевиден ;) Как закончим Vulkan и Metal, устаканимся с моделью API, там будет рационально и документацией заняться. Любая помощь приветствуется!
Лично мне не хватает туториала для чайников, как в glium. Потому очень помог код ozkriff (и его подсказка насчет vange, сам бы я его не нашел), поскольку в нем более понятно, откуда что берется и (что немаловажно) как его подробить на отдельные части.
В этом смысле, конечно, планы понятные.
Но вот будущее библиотеки мне видится туманным. Разве много кто на ней будет основывать новые проекты, если в долгосрочной перспективе gl2/3 будет только устаревать и все? С glium на vulkano (или на что еще) проект безболезненно не переведешь. Томака сейчас уже возится с glium постольку-поскольку, ему гораздо интереснее разрабатывать vulkano, а больше поддержкой особо никто не занимается.
https://users.rust-lang.org/t/glium-post-mortem/7063 — "Glium post-mortem" от Томаки. Теперь у glium планы понятнее некуда.
Заодно уж напишу тут, что вчера вечером выкатил ежемесячник по проекту:
https://users.rust-lang.org/t/this-month-in-zone-of-control/6993/1
Если кратко:
Со стороны пользователя
1) Является часть работы по внедрению инкрементальной компиляции — проще в обращении.
2) Позволяет делать часть специфичных оптимизаций на этом этапе, до оптимизаций LLVM
3) Более точный контроль типов и заимствований, позволит более точно контролировать заимствования, чуть ослабить требования (есть несколько очевидных мест, где контроль излишне жесткий из-за особенностей текущей реализации).
4) Позволило провести ряд долгожданных улучшений, например выкинуть скрытый бит drop из структур.
Со стороны компилятора
4) Некоторое упрощение внутренней архитектуры, уменьшение связности.
Анонс Rust 1.11