У ржавчины, насколько мне известно, нет четкого стандарта языка. Тут как с перлом — ржавчина это то, что может сомпилировать rustc. :)

Конкретно этот RFC нелексические одалживания сам не добавит, он может косвенно подготовить для них почву, ну да не суть.

Про «сэкономлю кучу времени как на изучении языка» — мы точно об одном и том же говорим? Можно пример кода? А то, судя по моему опыту, проблемы, которые должны решить нелексические одалживания, на данный момент решаются или созданием временной переменной или оборачиванием нескольких строчек кода в `{}` и все.

Если что, есть задачи с меткой `E-easy`, как раз для постепенного вхождения новичков в разработку компилятора

https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy

Если интересно состояние ржавчины для написания игр, то вот еще хорошая и относительно свежая ссылка с мнением Tomaka (автором нескольких вышеупомянутых библиотек) — https://users.rust-lang.org/t/my-gamedever-wishlist-for-rust/2859.

Не знаю, если честно, сколько оно там сейчас кадров выдает — мне до оптимизации отрисовки еще далеко, сначала бы сделать это все играбельным.

https://github.com/ozkriff/zoc — вот, прототипчик, давненько уже ковыряю черепашьими темпами.

Звук пока не трогал совсем.

Для создания окна и получения ввода использую glutin (https://github.com/tomaka/glutin) — отличная библиотека, работает даже на андроиде, к ней претензий не возникало никаких.

Для вывода графики использую свои обертки (https://github.com/ozkriff/zoc/tree/f874c9e/src/zgl/src) над голым gl-rs. Обертки кривые, сто лет назад их еще написал). Думаю переписать все на glium (https://github.com/tomaka/glium) — тоже отличная библиотека, только уж очень долго компилируется и сильно увеличивает время линковки проекта, на скорости рендеринга особо не должна сказываться.

Для 3д математики использую cgmath-rs (https://github.com/bjz/cgmath-rs), вроде как он немного для игр лучше подходит, чем nalgebra (https://github.com/sebcrozet/nalgebra), хотя последняя тоже неплоха.

Для вывода текста накидал небольшую обертку над stb_truetype — https://github.com/ozkriff/stb-tt-rs и сделал простенький кэш глифов — https://github.com/ozkriff/zoc/blob/f874c9/src/zgl/src/font_stash.rs. Вроде, терпимо работает.

Тут от специфики программы зависит. Я вот, например, игру пытаюсь писать и меня полностью устраивает во многих случаях при возникновении ошибки просто сразу грохнуть все приложение. Ну и о причине написать в консоль, для чего expect и нужен.

О! Result::expect наконец-то стабилизировали, это приятно.

Плюсы наверху между css и питоном.

Если я правильно понимаю, они просто считают сколько было поисковых запросов по языку.

>> Радует, что разработчики других языков увидели в этом перспективы.

Саттер говорит, что он сначала сделал то что сделал, а потом уже пошел смотреть другие решения этой же проблемы:

https://www.reddit.com/r/cpp/comments/3m0d41/writing_good_c14_by_default_herb_sutter/cvcnmn5

Это не «C, C++ и D», это другой язык, тут есть свои особенности. Относительно безопасная работа с памятью без сборки мусора не может быть совсем бесплатной, нужны ограничения. И никого, думаю, не удивит, что на каком-нибудь хаскеле не выйдет написать точно так же, как в плюсах.

Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»? Есть, хотя и небольшое, русскоязычное сообщество, где будут рады помочь новичку.

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

>> Схему они заимствовали из какого‐то другого языка (популярностью тот, впрочем, совсем не отличался).

Из какого? Насколько я знаю, именно такой работы с памятью, завязанной на владении/одалживании и изменяемости/неизменяемости не было.

>> Часть строгости является ошибками компилятора и это починят…

А можно подробней про «ошибки, которые починят»? Там же просто мелочи хотят подкрутить, и то не факт что сделают.

https://github.com/sfackler/rust-phf, например.

>> docopt

https://github.com/kbknapp/clap-rs же :)

Он даже был пакетом недели недавно — http://this-week-in-rust.org/blog/2015/09/14/this-week-in-rust-96.

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

>> в 90% приводится код, который на плюсах никто и никогда не пишет.

Обычно (в презентациях и статьях про Rust, которые мне вспомнились) приводятся короткие примеры, которые ясно демонстрируют проблему. Да, на практике никто прямо так не напишет, но реальные ошибки часто «размазаны» по большому количеству кода — не заталкивать же сотни строчек кода в презентацию.

Учитывая, что очень многие видят в Rust`е потенциальную безопасную альтернативу C++, то и упоминания C++ в разговорах о Rust мне не кажутся чем-то странным. В данном случае C++ упомянут как пример другого относительного низкоуровневого языка со статической типизацией и схожими сложностями при работе со строками.

Автор оригинальной статьи, думаю, никаких сложностей с fizzbuzz в любом варианте не испытывает, так как является одним из разработчиков Rust`а. Статья скорее о том, что многие новички, особенно имеющие только опыт работы с высокоуровневыми языками, часто спотыкаются на строках. Для работы с ними, все-таки, уже надо более-менее осознать систему типов и систему владения. Еще людей сильно смущает то, что просто типа «str» в языке нет.

Можно, вроде как: is.gd/mWY8hH

Надо же не только в форматной строке поменять:
is.gd/SyVz0J: println!("{}", 1i - 2) => -1
is.gd/MN2Py3: println!("{}", 1u - 2) => 18446744073709551615