Третий крупный проект на Rust

Правильные мысли, и я ниодной статьи не написал в стиле «Go супер, а раст Г», сам пользуюсь Го, всё работает как часы и доволен как слон.

А некоторые клепают и клепают пропогадистские и провокационные штучки

Ну как обычно для нового языка, экосистема, сообщество, да и вообще нужно в что-то новое вникать, когда можно использовать проверенный инструмент.

Надеюсь, ты не всерьёз этим пользоваться предлагаешь?

Это юзается уже в продакшне, посмотри на modules.map в том же самом clang. Оно сокращает время компиляции проекта в два раза.

Например? Ну и ничего что ООП в расте куцее относительно плюсового.

в расте он прямее плюсового: выражение полиморфизма через наследование является примерным аналогом этого -

https://www.youtube.com/watch?v=4jPiY56KsbU#t=22m00s

Это юзается уже в продакшне, посмотри на modules.map в том же самом clang. Оно сокращает время компиляции проекта в два раза.

В смысле, сам Clang «внутри» использует? Ну ок. А ещё примеры, чтобы кто-то использовал есть?

в расте он прямее плюсового

О прямости/кривости речи не было. Разговор был о «тяжести». Так вот, повторю вопрос - что в ООП в плюсах «тяжелее»?

А ещё примеры, чтобы кто-то использовал есть?

Ну libc++, а из сторонних от LLVM проектов, CERN'овый ROOT вроде использует.

Это юзается уже в продакшне

Опирать продакшн на экспериментальную фичу — путь к успеху, ага.

Оно сокращает время компиляции проекта в два раза.

Время компиляции — ещё одна больная мозоль крестов. У меня впечатление, что кресты все сотканы из мозолей.

Макросы в С это переписывание строк, макросы в расте это переписывание термов (с фичами вроде гигиены), плагины к компилятору в расте — полноценная работа с AST.

Что-то я не понимаю, какое отношение макросы имеют к плагинам к компилятору.

Они делают одну и ту же вещь: преобразуют AST в AST. В любом случае, в расте есть и то, и другое.

You may have seen the vec! macro, used to initialize a vector with any number of elements.

let x: Vec<u32> = vec![1, 2, 3];

This can’t be an ordinary function, because it takes any number of arguments. But we can imagine it as syntactic shorthand for

let x: Vec<u32> = {
    let mut temp_vec = Vec::new();
    temp_vec.push(1);
    temp_vec.push(2);
    temp_vec.push(3);
    temp_vec
};

Што? Штооо? Я надеюсь оно вот так вот не реализовано? Это к чему вообще такие примеры?

Што? Штооо?

Успокойся. https://github.com/rust-lang/rust/blob/master/src/libcollections/macros.rs#L44

Это к чему вообще такие примеры?

Чтобы довести тебя до истерики, очевидно же.

А менее впечатлительные люди смогут понять семантику макроса.

Ну сами плюсы тяжелее, раст уровнем чуть пониже.

раст уровнем чуть пониже.

Возможно.

А вот насчёт тяжести всё-таки хотелось бы увидеть пример - в каких случаях «эквивалентные» (по поведению) конструкции в плюсах тяжелее. Или тяжесть заключается тупо в том, что «больше всякого» и можно найти, в том числе, тяжелые штуки?

Код на расте может быть тяжелее плюсового только в двух случаях:

А) Пробег по массиву через индексы (в расте делается проверка выхода за границы)

Б) В плюсах получилось удачно ввернуть шаблонную магию.

Во всех остальных случаях раст легче. Т.е. нужный тебе пример находится сразу же.

(в расте делается проверка выхода за границы)

Справедливости ради, её можно «отключить» через unsafe. Так что это я бы примером не считал - поведение не эквивалентно и есть «буквальные аналоги», которые работают одинаково.

Во всех остальных случаях раст легче. Т.е. нужный тебе пример находится сразу же.

Да ладно? То есть вот даже тут:

const string s("test");

let s = "test".to_owned();

Вообще любой контейнер взять можно было. А строки в расте более вменяемые, а значит и более тяжелые как раз.

Они работают на этапе компиляции.

Чем оно лучше inline функции?

Они работают на этапе компиляции.

Чем оно лучше inline функции?

Толсто.

Чем оно лучше inline функции?

Это совсем разные штуки. Макросы позволяют порождать другой код, inline функции - нет.

Как пример применения: regex! макрос. В итоге корректность регулярного выражения проверяется во время компиляции, а не в рантайме. И скорость выше, разумеется.

корректность регулярного выражения проверяется во время компиляции

constexpr?

Не уверен, что constexpr'ом можно скомпилить регулярку во время компиляции. Можно пример?

http://cpptruths.blogspot.ru/2011/07/compile-time-regex-matcher-using.html

Сам не читал.

Александресково. Норм.

constexpr?

Ты ведь в курсе ограничений налагаемых на constexpr функции? А в макросах может произвольный код выполняться.

Сам не читал.

Зря. Потому что результат на «обычные» регулярные выражения похож весьма отдалённо. Ещё есть Boost.Xpressive, где тоже приходится изобретать свой синтаксис, чтобы впихнуться в ограничения.