#[proc_macro_derive] давно стабилен и использует proc macro API, прямо или через инфраструктурные крейты типа syn/proc-macro2.
До 1.29 всё делалось через строки, а 1.29 стабилизировал полноценное API для токенов, на которое все инфраструктурные крейты, например, сразу же перешли, это большое дело на самом деле.
Обычно все добавления в библиотеку анонсируются, даже крошечные, а в этом случае начались какое-то маневры ¯_(ツ)_/¯
Ибо толку, если я перейду, а все остальные разработчики на работе — нет?
Эта проблема от платформы и библиотек не сильно зависит.
"Остальные разработчики" в принципе редко хотять переходить на что-то другое если то что есть и так работает.
Несбалансированные скобки это убивство как минимум для системы макросов Rust.
Макросы могут принимать на вход любую последовательность токенов (m!( a ; d89 d ** 38 +() {} 'd )) с единственным ограничением — ()[]{} скобки должны быть сбалансированы, т.к. сбалансированная закрывающая скобка это единственный способ определить где вызов макроса заканчивается.
можно же было реиспользовать троеточие
Оно и было ... сначала, но люди очень громко жаловались что слишком похоже на .., без очков разницы не видно. Люди с decision power на жалобы поддались и выбрали вместо него этот страшный ..=, типа стерпится-слюбится, зато разницу сразу видно.
А основной С/С++ toolchain у вас какая-то вариация Mingw-w64 как я понимаю?
А LLVM им собрать на ReactOS можно?
У меня было некоторое желание попробовать завести компилятор Rust на ReactoOS, но то сам ReactoOS намертво зависал в первые пять минут работы без всякой причины (0.4.4 в VMware кажется), то штатный mingw ломался (какая-то из предыдущих версий), я и не стал продолжать.
Кто говорит о 50/50? Поддержание 50% это совсем не цель.
Цель чтобы стереотип "ИТ — не женское дело" перестал влиять на умы нынешних школьниц и студенток и их родителей при выборе будущей профессии.
Я не знаю какой конкретно процент для этого нужен, может быть 20%, может меньше, может больше, это может зависеть и от других факторов, например объема рекламы/пропаганды в медиа на эту тему.
Тем более, что многие люди, работающие в технологической сфере, являются одними из самых толерантных людей в мире.
Это неправда по моему опыту, почитайте хотя бы комментарии к этому посту. По крайней для отечественного ИТ, с американскими/канадскими тов-щами, с которыми я работал, разница разительная конечно.
Из инстутута тоже помню похожую историю, хиханьки-хаханьки, "женщина-физик — не физик и не женщина", вот это все.
В остальном написали полный бред.
Вы, батенька, фашист.
Отличные аргументы.
«через позитивную дискриминацию» — за такие слова я бы вообще банил
Это конечно красная тряпка, но попробуйте думать трезво, логика такая же как с социальными льготами при поступлении в ВУЗы, или бывшем предпочтении девочек при равных баллах при поступлении на ФизТех (не знаю есть ли оно сейчас).
Если вы хотите прорвать барьер "я буду единственной девочкой в классе/на факультете/в отделе", то позитивная дискриминация это работающее стартовое решение, потом после некоторого уровня всё может идти естественным путём (aka "хочет программировать — программирует, не хочет — не программирует").
Представьте себя работающим в компании состоящей из 100 индусов и вас.
Индусы вам не доверяют потому что вы белый, не дружат с вами особенно, не делятся новостями, смеются о чем-то у вас за спиной на своем индусском.
Было бы вам комфортно работать в таких условиях если сама работа устраивает?
Вероятно нет, если только вы не абсолютный асоциал.
Что-то в этом роде ощущает и женцина в большом мужском коллективе, что усугубляется тем, что асоциальных женщин не бывает. В этой ситуации несчастные сотрудники ИТ женского пола вынуждены идти в бухгалтерию и HR и общаться с тамошними тетками чтобы хоть как-то сохранить крышу над головой от съезжания.
Это реальный барьер, который удерживает женщин от ИТ в общем, и в частности от относительно высоких зарплат, которые наблюдаются в этой области. Женщины вынуждены отказыватся от ИТ и идти в менее оплачиваемые профессии, например в социологи или воспитатели детского сада. А разница в доходах, основанная на половых признаках это нехорошо, мкай?
Барьер может быть преодолем путем "насильственного" наращивания доли женщин через позитивную дискриминацию до определенного уровня, при котором пропадает ощущение одиночества в толпе индусов.
В CONTRIBUTING.md достаточно подробно всё описано (в том числе как искать entry-level тикеты).
Для начала рекомендую найти какую-нибодь опечатку или функцию с плохой документацией, исправить и сдалать pull request на гитхабе просто чтобы опробовать процесс. Патчей такого рода много, ревьюеры доброжелательные и если что-то не так всегда подскажут, поправят + ревью и мердж достаточно оперативно происходят, не надо ждать месяц пока maintainer соизволит взглянуть на патч, как в некоторых проектах.
План такой, что разрешение имен и разворачивание макросов будут работать вместе — "разрезолвили имена -> развенули макросы -> разрезолвили опять -> опять развернули" и так далее до точки равновесия.
Оно на самом деле уже так частично работает, просто работа не закончена еще.
По поводу API я так и предполагал. Я так понимаю, в будущем будет возможность конвертации между quote::Tokens и TokenStream, или же оно вообще будет приведено к одному типу? Ну или через From/Into/AsRef.
Я конкретно за этим подробно не слежу, но про предварительные планы можно почитать тут и тут.
Что куриличем руководствовались разработчики, почему было сделано именно так?
Вообще, я так понимаю, можно ответить вашими же словами, про то что сделали чтобы было, а потом это все будет допиливаться.
Да, разумеется, функционально оно работает, компилятор и библиотеку собирает и тестирует, можно дальше улучшать. Новые фичи добавляются на порядок легче по сравнению с мейкфайлами.
То что дизайн некошерный, это вопрос ортогональный. Меня в основном беспокоит то, что для контрибьюторов, которые хотят собирать и тестировать локально, rustbuild хуже чем старая система.
Есть ли конкретные обрисованные планы развития?
Важная инфраструктура (производство релизных сборок, расширение тестирования для разных платформ) будет расширяться, в остальном расчет на то что сторонние контрибьюторы будут подчищать конюшни.
Одна из целей переписывания системы сборки было как раз привлечение новых контрибьюторов.
Те макросы, которые есть сейчас (macro_rules!) это в некотором смысле временная мера, связанная с тем, что в 1.0 должны были быть макросы, но привести их в идеальное состояние не было времени.
Сейчас вместе с процедурными макросами, описанными в статье, делаются макросы by-example 2.0, у которых будет и собственное пространство имён, и модулярность, и разрешение имён совмещённое вместе с разворачиванием макросов в один этап.
Это тоже дело долгое, но в roadmap'е назначено на этот год.
Если честно, я тоже не понимаю, зачем тасовать данные туда-сюда через строки и почему нельзя было сразу сделать вменяемый интерфейс
Вменяемый и стабильный интерфейс это дело долгое с большим количеством неразрешенных вопросов, это дело если не всего этого года то следующего. А serde и diesel на стабильном Rust должны были работать еще вчера. Поэтому пока сделали ровно необходимый минимум.
Cистема сборки компилятора и стандартной библиотеки Rust была переписана на сам Rust с использованием Cargo
Ууу, rustbuild, сраное говно.
Вместо того, чтобы вести себя как приличные системы сборки и работать с графом зависимостей с таргетами в узлах и командами привязанными к таргетам, это наколеночное поделие херачит большую часть билда и тесты подряд в императивном стиле, режет параллелизм, добавляет зависимости. Когда совсем приспичивает приходится сравнивать timestamp'ы вручную (!) кодом на Rust.
Как же его хочется переписать, но нет возможности.
Хотя читается, конечно на порядок лучше старых мейкфайлов.
Кто вообще использует stable, это же как Windows Home Edition, всё урезано.
Вот понадобился внезапно какой-нибудь интринсик и что делать.
Только фиксированные nightly, только хардкор. Если нужна практическая стабильность, можно минимизировать использование нестабильных фич и избегать совсем нестабильных вещей вроде внутренностей компилятора.
#[proc_macro_derive]давно стабилен и использует proc macro API, прямо или через инфраструктурные крейты типаsyn/proc-macro2.До 1.29 всё делалось через строки, а 1.29 стабилизировал полноценное API для токенов, на которое все инфраструктурные крейты, например, сразу же перешли, это большое дело на самом деле.
Обычно все добавления в библиотеку анонсируются, даже крошечные, а в этом случае начались какое-то маневры ¯_(ツ)_/¯
И procedural macro API стабилизировали.
Эта проблема от платформы и библиотек не сильно зависит.
"Остальные разработчики" в принципе редко хотять переходить на что-то другое если то что есть и так работает.
Несбалансированные скобки это убивство как минимум для системы макросов Rust.
Макросы могут принимать на вход любую последовательность токенов (
m!( a ; d89 d ** 38 +() {} 'd )) с единственным ограничением —()[]{}скобки должны быть сбалансированы, т.к. сбалансированная закрывающая скобка это единственный способ определить где вызов макроса заканчивается.Оно и было
...сначала, но люди очень громко жаловались что слишком похоже на.., без очков разницы не видно. Люди с decision power на жалобы поддались и выбрали вместо него этот страшный..=, типа стерпится-слюбится, зато разницу сразу видно.Товарищ Федерико автором книги не является, и соответственно во это
тоже интерпретировано неверно. Он имеет в виду что c многопоточностью в Rust еще не работал, а не то что главу не дописал.
К слову о важных тонкостях, там "as" а не "is" в заголовке.
А основной С/С++ toolchain у вас какая-то вариация Mingw-w64 как я понимаю?
А LLVM им собрать на ReactOS можно?
У меня было некоторое желание попробовать завести компилятор Rust на ReactoOS, но то сам ReactoOS намертво зависал в первые пять минут работы без всякой причины (0.4.4 в VMware кажется), то штатный mingw ломался (какая-то из предыдущих версий), я и не стал продолжать.
Кто говорит о 50/50? Поддержание 50% это совсем не цель.
Цель чтобы стереотип "ИТ — не женское дело" перестал влиять на умы нынешних школьниц и студенток и их родителей при выборе будущей профессии.
Я не знаю какой конкретно процент для этого нужен, может быть 20%, может меньше, может больше, это может зависеть и от других факторов, например объема рекламы/пропаганды в медиа на эту тему.
Первые два абзаца вообще нерелевантные.
Это неправда по моему опыту, почитайте хотя бы комментарии к этому посту. По крайней для отечественного ИТ, с американскими/канадскими тов-щами, с которыми я работал, разница разительная конечно.
Из инстутута тоже помню похожую историю, хиханьки-хаханьки, "женщина-физик — не физик и не женщина", вот это все.
Отличные аргументы.
Это конечно красная тряпка, но попробуйте думать трезво, логика такая же как с социальными льготами при поступлении в ВУЗы, или бывшем предпочтении девочек при равных баллах при поступлении на ФизТех (не знаю есть ли оно сейчас).
Если вы хотите прорвать барьер "я буду единственной девочкой в классе/на факультете/в отделе", то позитивная дискриминация это работающее стартовое решение, потом после некоторого уровня всё может идти естественным путём (aka "хочет программировать — программирует, не хочет — не программирует").
Представьте себя работающим в компании состоящей из 100 индусов и вас.
Индусы вам не доверяют потому что вы белый, не дружат с вами особенно, не делятся новостями, смеются о чем-то у вас за спиной на своем индусском.
Было бы вам комфортно работать в таких условиях если сама работа устраивает?
Вероятно нет, если только вы не абсолютный асоциал.
Что-то в этом роде ощущает и женцина в большом мужском коллективе, что усугубляется тем, что асоциальных женщин не бывает. В этой ситуации несчастные сотрудники ИТ женского пола вынуждены идти в бухгалтерию и HR и общаться с тамошними тетками чтобы хоть как-то сохранить крышу над головой от съезжания.
Это реальный барьер, который удерживает женщин от ИТ в общем, и в частности от относительно высоких зарплат, которые наблюдаются в этой области. Женщины вынуждены отказыватся от ИТ и идти в менее оплачиваемые профессии, например в социологи или воспитатели детского сада. А разница в доходах, основанная на половых признаках это нехорошо, мкай?
Барьер может быть преодолем путем "насильственного" наращивания доли женщин через позитивную дискриминацию до определенного уровня, при котором пропадает ощущение одиночества в толпе индусов.
В CONTRIBUTING.md достаточно подробно всё описано (в том числе как искать entry-level тикеты).
Для начала рекомендую найти какую-нибодь опечатку или функцию с плохой документацией, исправить и сдалать pull request на гитхабе просто чтобы опробовать процесс. Патчей такого рода много, ревьюеры доброжелательные и если что-то не так всегда подскажут, поправят + ревью и мердж достаточно оперативно происходят, не надо ждать месяц пока maintainer соизволит взглянуть на патч, как в некоторых проектах.
План такой, что разрешение имен и разворачивание макросов будут работать вместе — "разрезолвили имена -> развенули макросы -> разрезолвили опять -> опять развернули" и так далее до точки равновесия.
Оно на самом деле уже так частично работает, просто работа не закончена еще.
Я конкретно за этим подробно не слежу, но про предварительные планы можно почитать тут и тут.
Да, разумеется, функционально оно работает, компилятор и библиотеку собирает и тестирует, можно дальше улучшать. Новые фичи добавляются на порядок легче по сравнению с мейкфайлами.
То что дизайн некошерный, это вопрос ортогональный. Меня в основном беспокоит то, что для контрибьюторов, которые хотят собирать и тестировать локально, rustbuild хуже чем старая система.
Важная инфраструктура (производство релизных сборок, расширение тестирования для разных платформ) будет расширяться, в остальном расчет на то что сторонние контрибьюторы будут подчищать конюшни.
Одна из целей переписывания системы сборки было как раз привлечение новых контрибьюторов.
Те макросы, которые есть сейчас (
macro_rules!) это в некотором смысле временная мера, связанная с тем, что в 1.0 должны были быть макросы, но привести их в идеальное состояние не было времени.Сейчас вместе с процедурными макросами, описанными в статье, делаются макросы by-example 2.0, у которых будет и собственное пространство имён, и модулярность, и разрешение имён совмещённое вместе с разворачиванием макросов в один этап.
Это тоже дело долгое, но в roadmap'е назначено на этот год.
Сорри.
(Это я писал.)
Вменяемый и стабильный интерфейс это дело долгое с большим количеством неразрешенных вопросов, это дело если не всего этого года то следующего. А serde и diesel на стабильном Rust должны были работать еще вчера. Поэтому пока сделали ровно необходимый минимум.
Ууу, rustbuild, сраное говно.
Вместо того, чтобы вести себя как приличные системы сборки и работать с графом зависимостей с таргетами в узлах и командами привязанными к таргетам, это наколеночное поделие херачит большую часть билда и тесты подряд в императивном стиле, режет параллелизм, добавляет зависимости. Когда совсем приспичивает приходится сравнивать timestamp'ы вручную (!) кодом на Rust.
Как же его хочется переписать, но нет возможности.
Хотя читается, конечно на порядок лучше старых мейкфайлов.
То что попало в стандарт (см. свежую версию черновика) совпадает с cppreference.
Хм, а вот в одной из предыдущих версий успешно устанавливался и запускался MSYS2, a в 0.4 всё поломалось.
Вот понадобился внезапно какой-нибудь интринсик и что делать.
Только фиксированные nightly, только хардкор. Если нужна практическая стабильность, можно минимизировать использование нестабильных фич и избегать совсем нестабильных вещей вроде внутренностей компилятора.