Сложности сопровождения rust

Петон смог пережить эту стадию в развитии и не скатиться.

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

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

Для метапрограммирования нужны полноценные макросы, и в расте есть, аж двух типов(правда синтаксически страшненькие), а в плюсах такие приседания нужны из-за убогих сишных макросов. Вообще это нездоровый подход держать в базовом языке фичу нужную для чего-то очень редкого и специфичного, при том что в 99% случаев эту фичу будут использовать не правильно.

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

Это все тот же переход 2.x -> 3.x, с тех пор ничего концептуально нового не было. Что-то из старого безусловно сломали, но без конкретики не подскажу.

В руби докидывают (ненужные) методы бережно сохраняя обратную совместимость.

У меня есть конкретный кейс с jekyll, который не совместим с Ruby 3.x , который по-умолчанию присутствует в пакетах. А это суперпопурярный фреймворк.

1.8 это уж совсем антиквариат, не уверен что он поддерживается «просто так». Нужна конкретика.

И всё работает, охренеть. Питон нужно каждый год заново переучивать.

Опять же нужна конкретика, поскольку из моего опыта использования что петона что руби следуют сильно другие выводы.

Это сишка не системный язык, а раст вполне себе и даже в большей степени чем с++(Линус Торвальдс не даст соврать)

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

Ну, если вы не можете сходить по ссылке и увидеть, что термин начал официально использоваться за 10+ лет до того как, то… Ну что уж поделать, живите теперь с этим.

Вам важен факт что я в чем-то ошибся, правильно понимаю? В этом суть?

Суть в вычислении коэфициента доверия к вашим словам. Вы успешно опустили его до нуля.

Суть в вычислении коэфициента доверия к вашим словам. Вы успешно опустили его до нуля.

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

А что такого прямо пееворачивающего все с ног на голову добавили в пидон с 3.х версии? Aio не в счет, это костыль сбоку который к тому же был давно, но в другой имплементации (вспомним ту же торнадо).

С версии 2 до 3, да было много изменений. Но не фундаментальных. Конструкт ядра языка сместил акцент, не более. В 3.х версиях - да, есть сахар. Но фундаментальных изменений нет. По крайней мере пока.

Про руби - улыбнуло. Писал на Rails, Sinatra. И вот как раз Мац очень любил ломать обратную совместимость. Так-то старый мем «я разработчик языка, а не Фреймворка» принадлежит ему и касалась фраза хейта по поводу постоянно ломаемых рельс.

А что такого прямо пееворачивающего все с ног на голову добавили в пидон с 3.х версии?

#Python 2.7
print 'Hello, World!'

#Python 3
print('Hello, World!')

Это было когда-то круче чем горькая правда про Деда Мороза.

Туда добавили аннотации типов, если кто не заметил. Это делает питон вообще другим языком. Да, можно их не использовать, только кто же разрешит. В руби впрочем тоже добавили, но сделали это максимально неинвазивно.

версии 2 до 3, да было много изменений

Да и раньше было. Старые классы, новые классы, где еще такое увидишь? И туева хуча всяких наворотов — декораторы, генераторы. Это всё добавляли на ходу.

И вот как раз Мац очень любил ломать обратную совместимость

Это всё ерунда на уровне «задепрекейтили метод». Самое страшное что было емнип, это изменение механизма require. И сравнить с питоном, где 3 версия просто новый язык. Хотя я конечно согласен с оратором выше, что стандартная поставка безбожно раздута и все эти тыщи методов (которые то добавят, то убавят) никуда не годятся.

Туда добавили аннотации типов, если кто не заметил. Это делает питон вообще другим языком

class Employee(NamedTuple):
    name: str
    id: int = 3

employee = Employee('Guido')
assert employee.id == 3

Ужас-то какой, помимо вычисляемого типа дали возможность указать тип сразу - все, «другой язык».

Если честно то это лишь добавило новый класс ошибок характерный для Java - аля «ClassCastException», когда имеет место быть несовпадение указанного типа и самих данных.

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

системные кодеры с большим опытом

например автор зига

Что-то я не очень этому верю.

Rust это про переписать nodejs приложение для прироста производительности в однопоточных сценариях и с возможностью отрефакторить заодно

У меня вопрос https://github.com/alvr-org/ALVR/blob/9a1f409509466e88de0dc76ab5905a15c5f1ce20/alvr/session/src/lib.rs#L239

Вот это вот это нормально для Rust при работе с json? Просто мне со знанием кучи языков (статика, динамика, ФП разных видов) это все, мягко говоря, не заходит. Хочется понять, это так там везде или конкретно в этом проекте лапши сготовили.

А что такого прямо пееворачивающего все с ног на голову добавили в пидон с 3.х версии?

Самое большое изменение, которое многие заметили, это изменения в подходе к работе со строками. См секцию Text Vs. Data Instead Of Unicode Vs. 8-bit: https://docs.python.org/3/whatsnew/3.0.html

Остальное - мелкие правки синтаксиса, функций и библиотек (те это можно было тащить в 2.x ветке).

Суть в вычислении коэфициента доверия к вашим словам. Вы успешно опустили его до нуля.

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

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

Слоган Batteries included появился в Python-сообществе ещё тогда, когда про Ruby за пределами Японии знало полтора человека.

Он даже в Википедии есть, правкой за 2014 год. https://en.wikipedia.org/wiki/Batteries_Included

Когда в середине нулевых на волне популярности и у Ruby появилась мода/потребность в каком-то слогане, то всегда было что-то вроде built/designed for developer/programmer happiness и с этого начинается «каждая вторая» книга.

Расскажи о своём опыте работы с давно написанным кодом, куда нет возможности приткнуть Раст. Не можешь же ты быть диванным теоретиком 😊

Кстати, на расте как и на руби любят писать веб фреймвоки.

Потому что Web Assembly и чтобы рвать производительностью жирные спринги и тормозные джанги. И на плюсцах бы полюбили, но языг не тот сильно 😁

Вся схожесть раста и джавахрипа реально в одном – это современные языки программирования, хотя второй и сильно старше, но развивается. Естественно, у анахронических плюсцов нет никаких атрибутов современного ЯП: ни пакетного менеджера, ни чёткого не бюрократизированного процесса принятия новшеств и т.д. Про Си лучше и не вспоминать в таком контексте. Современные кодеры просто не понимают, как такие языки сейчас могут существовать, где какую-то фичу можно ждать всю жизнь. Это естественный психологический барьер принятия отсталой технологии прогрессивными умами 😊. Не будет джаваскриптер ковырять плюсцы, это нонсенс. А Раст – стильный, модный, молодёжный. А научиться писать можно даже на Пердле, если есть желание. То есть дело не в преимуществах Раста, и даже не в рекламе, как старперы вещают: это борьба современного поделия и дедовского наследия. В которой старье проиграет неизбежно везде, где не сможет реально доказать свою неустаревшую актуальность. А как только возникнут наконец вопросы к безальтернативности, немедленно выкинут на обочину истории 😁. Кстати, выкинут необязательно в пользу Раста, далеко нет. Может, и он сойдет со сцены под натиском новых поделий 😁

Написал чепухи Слоган Batteries included появился в Python-сообществе ещё тогда, когда про Ruby за пределами Японии знало полтора человека.

Т.е тебе не интересна ни техническая дискуссия, ни идеи по теме, а надо просто до#баться до букв.

Ну замечательно, рад что это твой предел.

Еше поздравляю, ты (заранее) победил: я понятия не имею и знать не хочу в каком именно собществе появилась та или иная фраза, по какому поводу она там появилась и какой половой ориентации был автор.

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

Питон нужно каждый год заново переучивать.

Не ври, лгунишка. В рамках мажорных версий УМВР 😂

Современные кодеры просто не понимают, как такие языки сейчас могут существовать, где какую-то фичу можно ждать всю жизнь

Прости, напомнить тебе сколько async в Rust ехал?

Потому что Web Assembly

Не очень оно пока работает, им больше пугают чем реально используют. Живых проектов дальше демок пока не видел.

В другой мажорной версии сделали ломающее изменение! Ни в одном ЯП такого не было! Ну как же, как же!

Щупать зато можно. И раст был одним из первых, кто такую возможность дал. Это решает 🙂

Ну а примеры-то реального использования есть? Желательно не Google Earth, что-то поновее.

У меня вопрос https://github.com/alvr-org/ALVR/blob/9a1f409509466e88de0dc76ab5905a15c5f1ce20/alvr/session/src/lib.rs#L239

Не посмотрел сразу эту замечательную ссылку:

.cloned()
                .filter(|new_variant_json| {
                    new_variant_json
                        .as_str()
                        .map(|variant_str| {
                            variants
                                .iter()
                                .any(|named_entry| variant_str == named_entry.name)
                        })
                        .is_some()
                })
                .unwrap_or_else(|| old_session_settings["variant"].clone());

Это такое новомодное повертие, раскиданное по популярным языкам. Вот например как это выглядит в Джаве:

  int sum = widgets.stream()
                      .filter(w -> w.getColor() == RED)
                      .mapToInt(w -> w.getWeight())
                      .sum();

Практически близнецы-братья. В джаве сопли подобного говнокода это всегда гнездо разнообразных проблем и повод для чистки, врядли в расте дела обстоят как-то по-другому.

Чейнинг бывает полезным, но не всегда) Плюс ко всему, большинство применяющих его не совсем понимают, что творят и как итераторы с этим соотносятся)

Я скорее про другое имею ввиду. В тех же шарпах (на которых изначально был написан проект), можно было написать что-то на подобие:

class WOLOLO {
  public int Field = 9;
}

...

var wololo = JsonConvert.DeserializeObject<WOLOLO>(source_str);

И если Field в JSON нету, то оно будет установлено в дефолтное значение.

Если же там более сложная логика выбора, то всегда можно засунуть ее в геттер properties и там обработать (изменив для каждого конкретного поля + локализовав работу, те повысить читабельность и поддерживаемость кода). И это в языке со строгой статической типизацией.

В общем и целом - я в некотором недоумении, тк вопрос - а нафига козе баян у меня пока не находит ответа. cargo мб и не плох, но от тонны легаси на крестах не спасает (которое, как ты ни крути, а юзать придется ибо переписывать либы типа libxml, opencv и тд долго, муторно и никому нафиг не упало).

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

PS https://github.com/alvr-org/ALVR/blob/9a1f409509466e88de0dc76ab5905a15c5f1ce20/alvr/session/src/lib.rs#L456 вот более корректная ссылка, я так понял, что они там из JSON распаковывают объект, те аналог вызова JsonConvert.DeserializeObject.

Тут классика современного говнокода (примерно такое я по работе постоянно разгребаю):

 SchemaNode::Section(entries) => json::Value::Object(
            entries
                .iter()
                .map(|named_entry| {
                    (
                        named_entry.name.clone(),
                        json_session_settings_to_settings(
                            &session_settings[&named_entry.name],
                            &named_entry.content,
                        ),
                    )
                })
                .collect(),
        ),

Это заполнение вложенных DTO структур из объектов JSON парсера, эдакая ручная сериализация.

Вот это:

json::Value::Object

прям и есть тип данных в JSON под названием объект, оно же «{}» .

По-сути тут происходит «закат солнца вручную» и вместо автоматической десериализации, типа:

var wololo = JsonConvert.DeserializeObject<WOLOLO>(source_str);

делают создание и заполнение объекта вручную.

Лично я не стал бы использовать язык, где нет динамической линковки. Какое системное программирование без поддержки динамических библиотек? Они серьёзно?

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

Лучше сторонний кодогенератор. Чтобы не мелочиться. Это кстати очень показательно: раст настолько беспомощен, что самые элементарные вещи в нем приходится делать макросами (суть сторонней кодогенерацией).

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

а в плюсах такие приседания нужны из-за убогих сишных макросов

Какие «такие»? Сишные макросы убоги, но какое отношения это имеет к метапрограммированию?

аж двух типов(правда синтаксически страшненькие),

Хоть трех.

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

Какое это имеет отношение к обсуждаемой фиче? Что наследование реализации это вредно? Нет, я показал, что это полезно.

при том что в 99% случаев эту фичу будут использовать не правильно.

Кого это волнует? Откуда взята статистика? Кто сказал, как правильно, а как неправильно? Почему из-за того, что кто-то может использовать что-то «неправильно», приседать с макросами должны все?

а раст вполне себе и даже в большей степени чем с++(Линус Торвальдс не даст соврать)

Ага, Линус Торвальдс не даст соврать. Правда С++ на тот момент существовал как С с классами, и его не тащила толпа фанбоев с корпорацией за спиной и на волне хайпа.

Что до «вполне себе» системного языка – на этот позор в его загончике можно полюбоваться по ссылке

https://github.com/torvalds/linux/compare/master...Rust-for-Linux:linux:rust

Или вот, было:

https://github.com/torvalds/linux/tree/master/drivers/gpu/drm/vgem

стало (вернее, пока не стало и надеюсь никогда не станет)

https://github.com/mairacanal/linux/pull/11/files#diff-24ee291bcfec3f5da0c187f9728e6d80b2b6313ef085fd7a6bbc8167e9de259f

Но про несистемность С++ нужно побольше рассказать. Очень интересно получается: на несистемном языке уже десятилетия пишутся самостоятельные ОС и модули для мейнстримных ОС, драйвера, прошивки для микроконтроллеров – а для системного языка пара сдохших студенческих поделок выставляются как невероятное достижение.

Когда в середине нулевых на волне популярности и у Ruby появилась мода/потребность в каком-то слогане, то всегда было что-то вроде built/designed for developer/programmer happiness и с этого начинается «каждая вторая» книга.

Ага. Было еще что-то вроде «Ruby returns fun to programming». Что, надо сказать, было правдой, писал на Ruby (незадолго до того, как «стрельнул» RoR) с удовольствием.

Лучше сторонний кодогенератор

В том числе из-за этого я из Flutter/Dart ушёл, потому что весь зоопарк генераторов задолбал, так что статическое метапрограммирование это правильно. А то захотел протобафы сделать - запусти одно, захотел роутер - запусти второе, язык - третье. Всё постоянно код меняет и всё крякозябро полублобом лежит рядом, а уж какие веселые баги у кодгена. Не, такое не надо.

ЗЫ ну и с макросами в Rust проще, чем в C++, где это тупо чёрная коробка.

Опять же нужна конкретика

https://rubygems.org/gems/sequel

Required Ruby Version: >= 1.9.2

Автор по-приколу поддерживает античные версии, а может просто код в основном мало изменился? Ну с 1.8 конечно всё сложнее, как я понимаю из-за хрюникода.

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

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

Когда в середине нулевых на волне популярности и у Ruby появилась мода/потребность в каком-то слогане, то всегда было что-то вроде built/designed for developer/programmer happiness и с этого начинается «каждая вторая» книга.

Это конечно образчик гнусной пропаганды. Ну да ладно, теперь эта тема отъехала в раст, который каждый год побеждает в номинации «самый желанный самый любимый», но при этом продолжает болтаться в маргинальном болотце.

ну вот конкретный недавний кейс.

Разработчики де-факто стандартной библиотеки для (де)сериализации решили поставлять ее с предварительно скомпилированным блобом и отказываются это обсуждать. Тут прямо жир на жире.

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

Во-вторых, почему вообще в serde решили так сделать? Очень просто, потому что с нуля оно компилируется пару миллионов лет и адски тормозит даже на инкрементальных дебаг-сборках хелловорлдов. А тормозит оно потому, что в этом недоязыке все проблемы принято решать внешней кодогенерацией, скармливая llvm получившуюся кучу мусора, на что llvm очевидно не была рассчитана.

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

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

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

1. serde скорее всего форканут и запихают в Rust Foundation.

2. LLVM это дань портабельности, Zig столкнулся с такими же ограничениями и по факту сейчас отбросит себя на 3-4 года назад, ибо это сразу минус половина базовых его фич.

3. В любом языке можно подсунуть блобину, это проблема supply chain, а не языка.

ЗЫ вот уже и кстати форк с фиксом serde от разрабов Fedora

https://rubygems.org/gems/sequel

Полазил по его гиту:

I currently test Sequel on ruby 1.8.7, 1.9.2, 1.9.3, 2.0.0, 2.1.0, jruby 1.7, and rbx 2.2, so you appear to have everything covered.

Честь и хвала таким авторам, это действительно сложная работа, но не забывай что это лишь библиотека, а не большой проект, даже не пользовательское приложение.

Методы, которыми такое достигается я и сам практикую:

Looks like this breaks on Ruby 1.8.7, which Sequel still supports. I’ll modify things to make it conditional.

Ветвления в коде, включающие логику в зависимости от версии.

Additionally, adding warning as a development dependency would break on ruby 1.9.2-2.3, since warning requires ruby 2.4.

Постоянные проверки на совместимость и отказ от каких-то библиотек или решений ради обратной совместимости.

Вообщем да, такое есть, но цена сей обратной совместимости очень уж высока.

Надо мозги перепрошить под статическую типизацию, иначе будет цирк и профанация

Вообще-то даже в C++ уже появились вычисляемые типы и даже вот такое:

auto (*p)() -> int; // declares p as pointer to function returning int
auto (*q)() -> auto = p; // declares q as pointer to function returning T
                         // where T is deduced from the type of p

И никто не умер. Понятно что сишники икать будут с такого кода, но сам факт.

Сейчас динамическая типизация идет вместе со статической, друг-друга дополняя, это мейнстримное явление, есть во всех популярных языках: Java, Scala, C# и так далее.

и что, serde магически начнет быстрее компилироваться, если его форкнуть и назначить мейнтейнить нужных людей? Или rustc прекратит eval-ить процедурные макросы? И при чем тут вообще llvm? С подобной внешней кодогенерацией будет тормозить абсолютно любой компилятор.

Ты несешь чушь, не имеющую отношения к делу.

Постоянные проверки на совместимость и отказ от каких-то библиотек или решений ради обратной совместимости.

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

Важно, что это вообще возможно, а не как с питоном получилось.

Если честно то это возможно лишь до определенного предела, дальше которого стена под названием рантайм.

В приведенном выше sequel, в трекере куча тикетов с багами, которые сыпятся из более новых версий Ruby или из альтернативных реализаций, типа такого:

Skip use of JRuby workaround on JRuby 9.3.9.0+ in named_timezones extension as JRuby fixed the related bug (jeremyevans)

Work correctly on Ruby 2.8+ by supporting second argument for initialize_clone

Make jdbc/mysql adapter work when using JRuby with Java 11

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

Автор суров вообщем.

serde магически начнет быстрее компилироваться

А в чем проблема? Да, большие либы долго компилируются, что теперь, не программировать? Это плата за надежность и производительность.

rustc прекратит eval-ить процедурные макросы

Про исполнение любого кода я уже написал - это не проблема языка. Уже сколько разных либ было в JS и Python скомпрометированных майнерами, и ничего, многие умудрялись их даже в прод просунуть. Это проблема аудита зависимостей.

при чем тут вообще llvm

Как это причем, это стек компилятора Rust. Быстрее станет, значит макросы/статическое метапрограммирование быстрее обрабатывать будет. За кодогенерацию в rustc отвечает именно LLVM. Но лучше уж так, чем c горой утилит, написанных левыми разрабами обычных либ. Есть работа с GCC (а он по бенчмаркам обычно шустрее) в виде rustc_codegen_gcc, прогресс идет долго.

Суров, у него openbsd на десктопе (о чем я узнал из какого-то интервью). И он поддерживает там порты руби.

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

Аннотации типов? Ох, видимо когда Facebook сделали свой flow, то фактически новый язык из JS сделали. Пойду расскажу пацанам, а то они до сих пор пишут как на старом. А тут вот оно как… И хер с ним, что оно ни на что кроме линтера не влияет. Но подход!

Еще раз, если серьёзно. Что было добавлено в Python 3.x из того, что меняет подход? Старые классы, новые классы - это все часть библиотеки, они не могут изменить подход в языке.

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

За кодогенерацию в rustc отвечает именно LLVM

сам-то понял, какую чушь написал?

Но лучше уж так, чем c горой утилит, написанных левыми разрабами обычных либ

а, ты просто нихрена не понимающая веб-макака. Вопросов больше не имею.

Давайте разделять JS программистов над подтипы. Я писал - применительно к NodeJS разработчикам и NodeJS экосистеме. С frontend - это очень большая разница. Плюс к тому же нормальный NodeJS программист должен знать C++ ибо аддоны/модули/ffi. А NodeJS экосистема прекрасно приспособлена к интеграции с плюсовыми частями.

JS и Rust имее общего гораздо больше, чем кажется на первый взгляд. Просто посмотрите сложное NodeJS приложение на каком-нибудь Koa+Sequelize и сложное Rust приложение на Rocket +Diesel. Окромя типов и npm/cargo разницы очень мало.

Аналогично с концепциями - очень сильно ощущение, что концепт владения брялася с правил формирования контекста JS. ООП? А вот то, что было изначально и что получилось в Rust - достаточно близко. Async/await? Ощущение, что калька. И так в очень многих вещах

И не забываем - Мозила делали его для разработки движка браузера. Вероятно в команду входили в том числе спецы по EcmaScript, предполагали, что Rust могут начать использовать и как альтернативу JS. Да и VM для JS надо было делать. А значит, очень вероятно, надо язык разработки максимально приблизить по общим концепциям к языку сценариев. Собственно - вполне вероятная гипотеза. Не утверждаю, что было так. Возможно все идет от того, что JS корнями - схема, а идеи Rust брались с лиспа.

Но все же оба языка очень похожи. ИМХО

предполагали, что Rust могут начать использовать и как альтернативу JS

https://www.youtube.com/watch?v=KKWoF7LcAFA