А в раст-фаундейшн гугл входит, наверное, чтобы развалить организацию изнутри, да?..

Каждая библиотека пытается реализовать свой набор макросов, которые надо знать и уметь применять.

А можно примеров? Ну сериализация (#[derive(Serialize, Deserialize)]) понятно, но такие макросы легко воспринимаются после стандартных дерайвов (Debug, Clone и т.д.). Да и как-то не припоминаю чтобы серде неожиданно ломалось, так что тут тоже послушал бы. Ну #[tokio::main] без которого можно обойтись и который никакой магии не делает. Ну ладно tracing. А ещё?

Кроме того, тип переменной вычисляется не только по левой части, но и по тому, как эта переменная потом используется.

Да, есть такое, но чем оно мешает? Есть наглядные примеры когда такой вывод мог как-то неочевидно поломать логику?

Недавно был ещё один перевод этой статьи: https://habr.com/ru/articles/736842/

Думаю, что дело в другом: вот сериализация — вещь очень базовая и нужна всем, но если бы её поспешили добавлять в стд (про язык и не говорю), то это пришлось бы тащить ради совместимости "вечно". Помню до serde была другая библиотека с каким-то очень банальным названием вроде rust-serialize или типа того. Некоторый переходной период библиотеки поддерживали и её и серде. В общем-то и сейчас не всех серде устраивает, поэтому такие вещи лучше не тащить прям в "ядро языка".

И тем не менее, серде все используют и не парятся, что это дополнительная штука, которую надо изучить. Удобство перевешивает.

А что в данной статье "синтаксически замысловатого"? Ну кроме разве что макросов. Всё остальное — структуры и трейты. На последние можно смотреть как на привычные интерфейсы.

Это форк с некоторыми дополнительными фичами. Лично я бы не сказал, что eyre прям вытеснил anyhow. Мы у себя по в проекте по прежнему используем последний, crates.io показывает 1,772,950 "недавних" скачиваний у eyre и 14,839,310 у anyhow.

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

Мода иногда ничего общего с удобством не имеет.

Не буду так категоричен — сам этот девайс не пробовал (и пока не собираюсь), но как ни странно, купившие хвалят. Наверное, сейчас будет аргумент в духе "потратили деньги и жалко признать, что зря"?..

Наоборот. Сначала радар предупреждает, а потом велосипедист видит лужу.

Почему?

Зависит от обстоятельств. На относительно узких дорогах с практически отсутствующим трафиком можно не прижиматься к самому краю дороги постоянно, а только после предупреждения радара. Ну и плюс это всё-таки модная замена зеркала. То есть, велосипедист видит впереди лужу и хочет взять левее, но тут радар предупреждает, что сзади машина и придётся проезжать её, ну или тормозить.

Наличие опасности сзади движения велосипедиста предполагает его движение на трассе в центре дороги, что уже нарушение правил.

Не везде правила предписывают велосипедистам ехать "как можно правее".

Пользу от радара вижу на узких дорогах с не слишком оживлённым движением. Тогда можно не прижиматься (где покрытие может быть хуже) к самому краю дороги постоянно, а только при приближении автомобиля. Так-то сам не уверен насколько это удобно будет, но пользователи хвалят.

Не уверен, что понял аргумент. Если мы говорим о заметности самого велосипедиста, то сами по себе камера или радар как помогут? Вот фонарик и яркая одежда — да. То, что этот конкретный радар совмещён с фонариком — это удобно, спорить не буду.

В камеру придётся постоянно смотреть — тогда уж можно просто зеркалом обойтись. Плюс радара в том, что он может активно уведомлять.

В таком случае мне больше по душе подход раста, который заставляет оборачивать разыменование указателей в unsafe блоки. Но (кажется) понимаю почему так сделали.

В D это возможно, потому что безопасное для памяти подмножество языка не предотвращает прямой доступ к памяти как таковой.
…
Это безопасно для памяти, потому что safe D не позволяет создавать указатели int*, указывающие на нераспределённые области памяти

Не совсем понял этот момент. Можно ли в функции, не помеченной как @safe, создать кривой указатель, а потом передать его в "безопасную" функцию?

Ни одно из перечисленных правил не вызывает возмущения.

Ещё как вызывает. Дальнейшая дискуссия в основном ушла в обсуждение запрета оружия и прочей ерунды, что лично меня особо не затрагивает. Тем не менее, другие запреты на мой взгляд являются откровенным саботажем, особенно на фоне того, что раст, скажем так, ещё совсем не является мейнстримом.

Например, crate-пакеты рекомендовано именовать "имя-rs" вместо "rust-имя".

В оригинале, если мне не изменяет память, там не рекомендация, а именно требование. И ряд библиотек уже использует такие названия. Запрет задним числом выглядит странно и кроме этого является деструктивным: переименовывать — это неудобно, поломает сборку другим проектам и в целом только добавит головной боли. У меня это очень даже вызывает возмущение, особенно учитывая, что я являюсь одним из мейнтейнеров растовых байндингов к rocksdb.

Продажа товаров — без прямого одобрения использование имени и логотипа Rust запрещено для продажи или рекламы товаров с целью получения выгоды.

Ну и зачем? Вот печатает кто-то футболки с логотипом раста и продаёт их. Организации действительно нужны эти копейки?

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

Слышал, что люди уже приостановили написание статей и подобных материалов, по крайней мере, до момента когда не станет понятнее какие будут последствия. Это уже нанесённый урон! Всегда считал сильной стороной языка наличие достаточно качественных и бесплатных учебных материалов. Тем не менее, платная литература тоже нужна, а теперь её точно не станет больше. Возмущаюсь, да.

Использование логотипа Rust запрещено при какой-либо модификации самого логотипа помимо 'масштабирования';

Про перекрашивание (например, если фон чёрный) уже говорили, но ещё часто встречал безобидные модификации для ассоциации с продуктом или для конференций и подобных мероприятий, которые далеко не всегда являются "официальными". Кажется естественным, что некоторые поленятся получать официальное одобрение и забьют. Выглядит не смертельно и ничего хорошего тут тоже нет.

Ну и наконец весь этот срач уже бросает тень на будущее языка и "фаундейшн". Начинаются спекуляции на тему, что ещё могут запретить. Всё, репутация уже слегка подпорчена. Надеюсь, что у них хватит ума признать, что это было ошибкой и публично об этом заявить, но не удивлюсь, если опубликуют "исправленную" версию, которая будет всего лишь немного мягче.

Данный комментарий видел, не уверен, что полностью согласен. В любом случае, поглядывать по сторонам и пробовать что-то новое полезно. И опять же, если про язык/технологию никто не говорит, то она так и умрёт. Ну а с тем, что выбирать надо более подходящий инструмент вряд ли кто-то будет спорить.

Можно несколько примеров? По моему, достаточно приятная статья и это при том, что я "топлю за раст".

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

Потому что это рассказывают друг другу те, кто его не знает.

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

У раста работает маркетинг.

Пусть так, хотя не вижу в этом ничего плохого в наших реалиях. Каким бы прекрасным ни был язык/продукт, если о нём не говорить, то не взлетит. В любом случае, маркетинг должен был бы разбиваться о суровую реальность. Неужели человек, который с трудом сможет освоить питон, без проблем осилит раст просто из-за рекламы?..

Я сам идейный, ну или, по крайней мере, так считаю. Тем не менее, не вижу ничего странного в том, что люди идут за деньгами. В айти полно не особо творческой работы, не стоит так уж нашу сферу идеализировать. Если человек справляется, то мне пофиг какая у него мотивация.
Ну и кстати, наличие "продакшен опыта" сильно помогает, а войти через популярный язык всё-таки проще. Мысль уловил, но мне всё-таки кажется, что у С++ есть репутация "устаревшего языка", а не только сложного.

Возвращаясь к теме: если говорить о расте, то я бы не сказал, что язык кардинально проще С++, а вакансий до сих пор меньше. Поэтому вряд ли его выбирают в погоне за лёгкими деньгами. В будущем посмотрим прогадали ли авторы Slint.