Раз тут так тихо, то хоть похвастаюсь, что моя инициатива по ежемесячникам о ржавом игрострое — https://rust-gamedev.github.io — продержалась уже аж целый год, юху!
Не новомодный — это старая полустебная традиция из Мозиллы.
Может и круто бы всё это свести к единому формату/домену, мысль поднимается время от времени. Но текущие сайты не так уж и жутко справляются со своей задачей, что бы нашелся желающий угробить кучу своего времени на реализацию такой инициативы.
Правда, в случае прокидывания из сей в ржавчину получится автосгенерировать только unsafe часть — безопасную идиоматизирующую "над-обертку" таки придется руками писать, это особо не автоматизируешь (в общем случае).
В официальном посте почему-то про это не написали, но 1.41 наконец-то стабилизировал очень ожидаемую многими разработчиками чего-то интерактивного штуку: "profile overrides". TLDR: позволяет выборочно использовать разные профили сборки для основного кода и зависимостей.
Т.е., например, теперь можно собирать отладочную сборку с оптимизированными зависимостями:
# Set the default for dependencies.
[profile.dev.package."*"]
opt-level = 2
Это очень в тему, например, при разработке игр, потому что ты получаешь вменяемое количество кадров в секунду на оптимизированном движке и мат библиотеках, но при этом непосредственно твой код игры быстро собирается и нормально отлаживается.
Еще оно может быть полезно, например, для выключения оптимизаций для build-time зависимостей (типа syn), что для некоторых проектов может чуть ли не в два раза уменьшить время полной release сборки.
Ржавые строки изкоробки юникодные, но для графемных кластеров (а, как я понимаю, тут нужны они) надо будет https://docs.rs/unicode-segmentation подключить.
Про просто кросспостинг еще можно подумать (вроде, хабр к этому теперь спокойней относится), а вот именно переводить дайджест, тем более довольно нишевый, мне не кажется, что стоит усилий — все ж таки там не лонгрид, а только названия с картинками + пара предложений описания.
Я забросил писать русскоязычные хабро-ежемесячники про раст, зато, если кому интересно, пару месяцев назад стал писать официальные ежемесячники чисто про ржавую разработку игр — https://rust-gamedev.github.io — только что вот октябрьский выпуск опубликован. :)
Компилятору нужны не полностью собранные зависимости для сборки пакета, а лишь их "метаданные" (список типов, зависимостей, экспортов и т.д.), генерируемые на ранней стадии компиляции. Начиная с Rust 1.38.0, Cargo будет сразу же начинать сборку зависимых пакетов, как только их метаданные будут доступны.
Т.е. сборка пакетов с зависимостями будет начинаться до того, как все их зависмости будут собраны до конца. При большом количестве рекурсивных зависимостей это может заметно ускорять сборку.
With ASCII diagrams, let’s say we have a binary which depends on libB which in turn depends on libA. A compilation today might look like this:
meta meta
[-libA----|--------][-libB----|--------][-binary-----------]
0s 5s 10s 15s 20s 30s
With pipelined compilation, however, we can transform this to:
кто-нибудь объяснит, какой у них здесь коммерческий интерес?
Собственно, в основном, azure продвигать прямо и косвенно. Тут все прозрачно, кмк.
Какие-то отделы экспериментально могут раст именно как яп использовать, но это вряд ли к текущему спонсорству отношение имеет.
у такого крутого языка куча зависимостей от внешней инфраструктуры
Этот вопрос там-сям всплывает периодически, но в целом аргументация растокоманды сводится к практичности и недостатку ресурсов.
Crates.io требует Github аккаунта
Это вот сюда — https://github.com/rust-lang/crates.io/issues/326 — старый вопрос. TLDR (как я его понимаю) в том, что это просто и практичное решение, которое устраивает абсолютное большинство текущих пользователей, а запилить свой независимый вариант так, что бы это точно не вышло боком — требует ресурсов и не так уж тривиально, поэтому отложено в бэклог.
Rust-doc построен на HTML+JS (тк там есть динамические фичи, например поиск) и справка очень жирная, у меня каталог /usr/share/doc/rust-doc занимает почти 300 Мб
А какой основной формат выдачи у генератора доков должен быть? Вроде как это ровно то, что нужно большинству пользователей. Что доки весят порядочно — ну да, не очень приятный момент, но стандартные, насколько помню, можно не выкачивать, а для своего проекта генерить, например, только для определенного набора зависимостей. Ну и хз, на фоне многогигабайтного веса target директории размер генеренных доков лично меня никогда не волновал))
Чат разработчиков идёт в Telegram (привет проприетарщина с идентификацией по номеру телефона).
Эм, чаты из статьи это ж неофициальное русскоязычное — где большая часть пользователей обитает, там оно стихийно и образуется. Так-то есть еще менее живые, но зато опенсорсные гиттер и форум.
Англоязычных средств общения тоже каких угодно хватает — как проприетарного дискорда, так и все еще живой ирки, открытого zulip, discourse'овых URLO/IRLO и т.п.
Теперь вот завязывание инфраструктуры тестов на azure и aws.
Ну, я так понимаю, это опять же вопрос доступных ресурсов. Было бы доступно свое железо в нужном количестве — строили бы все независимое, но денег на это нету.
я бы точно теперь попытался пропихнуть в cargo что-нибудь вроде команд для развёртывания в azure
В сам cargo сильно вряд ли выйдет, но вот удобное расширение cargo наверняка будет (или даже уже есть? надо прогуглить это дело).
Есть надежда в обозримом будущем (этом году или начале следующего?) получить — работающая в ночнике реализация есть, до стабилизации не так уж и много осталось работы: https://github.com/rust-lang/rust/issues/44580
Выпуск полезный, не сильно значительный — в основном мелкие эргономические улучшения. Ждем 1.36 с hashbrown и 1.37 с async'ом (какой бы там синтаксис не выбрали в итоге). :)
Тем временем, я пару недель назад таки срезал v0.5 версию своей пошаговой ржавой игры Zemeroth и написал огромную новость об этом в девлоге: "Zemeroth v0.5: ggez, WASM, itch.io, visuals, AI, campaign, tests".
Неприятные вопросы переезда между движками и работы в вебе хотя бы на время закрыты, роадмап написан, теперь планомерно движусь к выпуску v0.6.
В этом плане эта версия вообще никаких принципиальных изменений не привносит. Просто почитать что там с ООП в Rust можно, например, в Книге, отдельная глава есть: 17. Object Oriented Programming Features of Rust.
Раз тут так тихо, то хоть похвастаюсь, что моя инициатива по ежемесячникам о ржавом игрострое — https://rust-gamedev.github.io — продержалась уже аж целый год, юху!
В процессе перешли к более открытому процессу написания с полу-ручной координацией через гитхаб задачи: приглашаю сочувствующих присоединяться к написанию/вычитке 13ого выпуска. :)
Не новомодный — это старая полустебная традиция из Мозиллы.
Может и круто бы всё это свести к единому формату/домену, мысль поднимается время от времени. Но текущие сайты не так уж и жутко справляются со своей задачей, что бы нашелся желающий угробить кучу своего времени на реализацию такой инициативы.
https://github.com/rust-lang/rust-bindgen / https://github.com/eqrion/cbindgen
Правда, в случае прокидывания из сей в ржавчину получится автосгенерировать только unsafe часть — безопасную идиоматизирующую "над-обертку" таки придется руками писать, это особо не автоматизируешь (в общем случае).
Мой прошлый ответ все еще актуален: "Пока нет. За прогрессом можно следить тут: https://github.com/rust-lang/rust/issues/55467"
RFC принят, так что формально собираются. Но, судя по малой активности реализации, никто сейчас активно не паровозит это дело.
В официальном посте почему-то про это не написали, но 1.41 наконец-то стабилизировал очень ожидаемую многими разработчиками чего-то интерактивного штуку: "profile overrides". TLDR: позволяет выборочно использовать разные профили сборки для основного кода и зависимостей.
Т.е., например, теперь можно собирать отладочную сборку с оптимизированными зависимостями:
Это очень в тему, например, при разработке игр, потому что ты получаешь вменяемое количество кадров в секунду на оптимизированном движке и мат библиотеках, но при этом непосредственно твой код игры быстро собирается и нормально отлаживается.
Еще оно может быть полезно, например, для выключения оптимизаций для build-time зависимостей (типа syn), что для некоторых проектов может чуть ли не в два раза уменьшить время полной release сборки.
Ржавые строки изкоробки юникодные, но для графемных кластеров (а, как я понимаю, тут нужны они) надо будет https://docs.rs/unicode-segmentation подключить.
Про просто кросспостинг еще можно подумать (вроде, хабр к этому теперь спокойней относится), а вот именно переводить дайджест, тем более довольно нишевый, мне не кажется, что стоит усилий — все ж таки там не лонгрид, а только названия с картинками + пара предложений описания.
Пока нет. За прогрессом можно следить тут: https://github.com/rust-lang/rust/issues/55467
Я забросил писать русскоязычные хабро-ежемесячники про раст, зато, если кому интересно, пару месяцев назад стал писать официальные ежемесячники чисто про ржавую разработку игр — https://rust-gamedev.github.io — только что вот октябрьский выпуск опубликован. :)
А почему "не-пойми-откуда"?
Т.е. сборка пакетов с зависимостями будет начинаться до того, как все их зависмости будут собраны до конца. При большом количестве рекурсивных зависимостей это может заметно ускорять сборку.
(из IRLO темы)
Собственно, в основном, azure продвигать прямо и косвенно. Тут все прозрачно, кмк.
Какие-то отделы экспериментально могут раст именно как яп использовать, но это вряд ли к текущему спонсорству отношение имеет.
Этот вопрос там-сям всплывает периодически, но в целом аргументация растокоманды сводится к практичности и недостатку ресурсов.
Это вот сюда — https://github.com/rust-lang/crates.io/issues/326 — старый вопрос. TLDR (как я его понимаю) в том, что это просто и практичное решение, которое устраивает абсолютное большинство текущих пользователей, а запилить свой независимый вариант так, что бы это точно не вышло боком — требует ресурсов и не так уж тривиально, поэтому отложено в бэклог.
Аналогично. Хотя надо упомянуть, на всякий, что желающие могут развернуть альтернативные регистры — https://doc.rust-lang.org/cargo/reference/registries.html — без всяких гитхабов.
А какой основной формат выдачи у генератора доков должен быть? Вроде как это ровно то, что нужно большинству пользователей. Что доки весят порядочно — ну да, не очень приятный момент, но стандартные, насколько помню, можно не выкачивать, а для своего проекта генерить, например, только для определенного набора зависимостей. Ну и хз, на фоне многогигабайтного веса target директории размер генеренных доков лично меня никогда не волновал))
Эм, чаты из статьи это ж неофициальное русскоязычное — где большая часть пользователей обитает, там оно стихийно и образуется. Так-то есть еще менее живые, но зато опенсорсные гиттер и форум.
Англоязычных средств общения тоже каких угодно хватает — как проприетарного дискорда, так и все еще живой ирки, открытого zulip, discourse'овых URLO/IRLO и т.п.
Ну, я так понимаю, это опять же вопрос доступных ресурсов. Было бы доступно свое железо в нужном количестве — строили бы все независимое, но денег на это нету.
В сам cargo сильно вряд ли выйдет, но вот удобное расширение cargo наверняка будет (или даже уже есть? надо прогуглить это дело).
Это довольно избитый аргумент, ответ на который сводится примерно к тому, что есть разные виды кода:
Там в 99% случаев люди ругаются на две вещи:
1) std статически линуется по умолчанию
2) jemalloc статически линкуется по умолчанию
Первое решается много какими способами (например вышеупомянутым #![no_std]), второе убрано в Rust 1.32.
Тут вот можно найти основные ссылки по наработкам ржавой встройки: https://rust-lang.org/what/embedded
Есть надежда в обозримом будущем (этом году или начале следующего?) получить — работающая в ночнике реализация есть, до стабилизации не так уж и много осталось работы: https://github.com/rust-lang/rust/issues/44580
https://ru.wikipedia.org/wiki/permadeath
https://diablo.fandom.com/wiki/Hardcore
Там же еще даже PR не влит — https://github.com/rust-lang/rust/pull/56410 — раньше 1.37 точно не доберется.
Выпуск полезный, не сильно значительный — в основном мелкие эргономические улучшения. Ждем 1.36 с hashbrown и 1.37 с async'ом (какой бы там синтаксис не выбрали в итоге). :)
Тем временем, я пару недель назад таки срезал v0.5 версию своей пошаговой ржавой игры Zemeroth и написал огромную новость об этом в девлоге: "Zemeroth v0.5: ggez, WASM, itch.io, visuals, AI, campaign, tests".
Неприятные вопросы переезда между движками и работы в вебе хотя бы на время закрыты, роадмап написан, теперь планомерно движусь к выпуску v0.6.
В этом плане эта версия вообще никаких принципиальных изменений не привносит. Просто почитать что там с ООП в Rust можно, например, в Книге, отдельная глава есть: 17. Object Oriented Programming Features of Rust.
Нифига себе пустой — альтернативные реестры и TryFrom очень много кто ждал, как минимум.