Feature freeze C++20. Coroutines, Modules и прочее

То есть, сделали так из-за legacy, а теперь и само это решение переходит в legacy, с которым нужно считаться! В Rust, кстати, предвидя подобные проблемы своевременно внедрили механизм редакций.

Финляндия подвела предварительные итоги эксперимента с гарантированным базовым доходом

По своему опыту, до 6 месяцев спит и ест, папа вообще не требуется, только по своему желанию, мама имеет достаточно много свободного времени, для хобби или удаленной работы.

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

Выпуск Rust 1.32

Можете открыть issue.

Rust vs. C++ на алгоритмических задачах

С последней версией (1.32), Rust на моем ноуте либо выигрывал, либо слегка отставал на всех тестах, кроме задачи «Кодирования Хаффмана». На ней Rust проигрывал плюсам аж в 2 раза. Однако, после замены HashMap на FxHashMap (фактически я изменил только хешер) и включения opt-level = 3, производительность выросла в 4 раза, и теперь стала отставать в 2 раза уже реализация на C++. Так что многое зависит от используемых алгоритмов.

Выпуск Rust 1.32

Если сильно надо, то такое довольно просто реализуется:

macro_rules! dbgs {
    ($val:expr) => {
        dbg!($val)
    };
    ($($val:expr),+) => {
        eprint!("[{}:{}]", file!(), line!());
        dbgs!(@dbgs $($val),+);
        eprintln!();
    };
    (@dbgs $current:expr, $($val:expr),+) => {
        eprint!(" {} = {:#?},", stringify!($current), $current);
        dbgs!(@dbgs $($val),+);
    };
    (@dbgs $last:expr) => {
        eprint!(" {} = {:#?}", stringify!($last), $last);
    }
}
...
let a = 2;
let b = 3;

dbgs!(a + b);
dbgs!(a, b, a + b);

После запуска:

[src/main.rs:23] a + b = 5
[src/main.rs:24] a = 2, b = 3, a + b = 5

За что я не люблю Go

Не надо извиняться, мы просто с вами разных взглядов. Да, я считаю навязчивую рекламу плохим делом. Что же касается Раста, то я в целом доволен тем, как он развивается и как продвигается. Есть свои проблемы и шероховатости, но видеть Rust на месте Go по способу продвижения, я бы не хотел. Все-таки важна не только цель, но и средства.

Выпуск Rust 1.32

Также, как и раньше — ее нет )

За что я не люблю Go

А можете вкратце пересказать эти идеи, своими словами?

За что я не люблю Go

Гугл агрессивно продвигает Go — и это факт. Хотим мы такую же кампанию для Rust или нет — это уже другой вопрос. Лично я считаю такие маркетинговые продвижения вредными, так как в итоге популярность технология не «зарабатывает», а ей ее «покупают». Со всеми вытекающими, типа возможном быстром ее закрытии при смене коньюнктуры. Так что пусть лучше Rust рекламируют опробавшие его разработчики, чем мозилловские пиарщики (кои, кстати говоря, особо на маркетинг и не тратятся). Другое дело, что совсем без рекламы в современном мире уже не обойтись: тебя просто не заметят в море информационного шума.

За что я не люблю Go

Маркетинг — это объективный фактор )

За что я не люблю Go

А фразы borrow и ownership? Так вот, оказывается — встречаются. Причем иногда бывают очень забавные ситуации (вроде поста об удалении ownership из Rust). Так что чтобы лишний раз не нарываться, лично я часто пишу «Rust lang», а в YouTube так без этого вообще не обойтись. И, заметьте, пишется в два раздельных слова. Поэтому подсказки вроде «golang» вообще не к месту.

За что я не люблю Go

Без lang по слову Rust гугл зачастую выдает результаты, связанные с одноименной игрой.

К чему готовиться в 2019 году: тренды в программировании

Реклама Go на фоне приведенных данных выглядит неуместно.

Rust новости #4 (декабрь 2018)

В Cargo вы можете выполнять собственный скрипт при сборке. Дополнительно есть еще плагин cargo-script.

Но если вам достаточно просто вызовов некоторых команд подряд, то проще сделать shell-скрипт с вызовом cargo build и прочего.

Rust новости #4 (декабрь 2018)

Насколько я знаю, он в language team не входил. Так что его уход на дизайне самого языка никак отразиться не должен.

Так ли страшен Rust, как его малюют

Это вы не понимаете, что обеспечение соответствия времен жизни объектов и ссылок на них — важная часть механизма управления памятью. В Rust, также как и в языках с GC, эта часть присутствует, хотя и работает отлично от них. А в C++ ее просто нет. Поэтому для тех прикладных задач, где все же важен контроль, либо критичны издержки, налагаемые GC, Rust вполне применим. Тогда как C++ расположен уровнем ниже.

Так ли страшен Rust, как его малюют

но постойте… За то, что программист может спокойно сделать в языке с GC, компилятор раста даст по рукам. Это разве не относится к «удобству»?

Точнее то, что язык с GC сделает полностью автоматически (продлит время жизни объекта), компилятор Раста заставит это сделать программиста самому. Мороки в этом случае больше, но зато есть контроль над стеком, нет жирного рантайма и всяких непредсказуемых остановок мира.

Так ли страшен Rust, как его малюют

Если в Rust-е разработчик разместил объект на стеке, а затем захотел продлить время жизни этого объекта (например, нужно сохранить ссылку на объект в каком-то мапе/реестре), то сделать он этого не сможет. По тем же самым причинам, что и разработчик на C++.

Да, но только разработчик на C++ все же сможет сохранить ссылку, тогда как время жизни объекта продлено не будет. Язык с GC в этом случае позволит сохранить ссылку, увеличив время жизни объекта путем размещения его в куче, вместо стека. Rust же просто не скомпилирует такой код, пока программист вручную не обеспечит соответствие времен жизни. То есть в Rust, также как и в языках с GC, не возникнет ситуации с висячей ссылкой.

Конечно, на C++ возможно программировать так, чтобы небыло ошибок с памятью. Проблема в том, что это не обязательно.

Так ли страшен Rust, как его малюют

Так вот о том и речь, что в C++ нет механизма, позволяющего объекту своим временем жизни управлять ссылкой на него. Есть механизм, который позволяет ссылке управлять временем жизни некоторых объектов (умные указатели), но не наоборот. Поэтому на шкале от полностью ручного управления памятью до полностью автоматического, C++ расположен ближе к ручному, чем Rust. Так как программисту приходится самому следить за валидностью ссылок. Этот аспект не касается непосредственно выделения памяти или ее освобождения, он касается гарантии обращения к объекту только в промежутке межде этими двумя операциями. Понятно, что вам выгодно считать этот аспект вторичным и малозначимым, но с точки зрения прикладного программиста, это очень важное качество, которое принципиально отличает способ работы с памятью Rust от C++ и которое все-таки ставит Rust сильно ближе к языкам с GC.

Так ли страшен Rust, как его малюют

Как я понимаю, unique_ptr/shared_ptr избавляют от ошибки использования после освобождения для объектов, размещенных в куче. За счет того, что они берут на себя управление уничтожением объекта. Но стековый объект будет уничтожен при выходе из области видимости. Что при этом произойдет с умным указателем, если он указывает на стековый объект? А в случае возврата такого умного указателя из функции? Можно ли с помощью умных указателей гарантировать отсутствие висячих ссылок в программе, если в качестве ссылок как на объекты, размещенные в куче, так и для объектов на стеке используются только они?