У ржавчины, насколько мне известно, нет четкого стандарта языка. Тут как с перлом — ржавчина это то, что может сомпилировать rustc. :)
Конкретно этот RFC нелексические одалживания сам не добавит, он может косвенно подготовить для них почву, ну да не суть.
Про «сэкономлю кучу времени как на изучении языка» — мы точно об одном и том же говорим? Можно пример кода? А то, судя по моему опыту, проблемы, которые должны решить нелексические одалживания, на данный момент решаются или созданием временной переменной или оборачиванием нескольких строчек кода в `{}` и все.
Если интересно состояние ржавчины для написания игр, то вот еще хорошая и относительно свежая ссылка с мнением 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 и нужен.
Это не «C, C++ и D», это другой язык, тут есть свои особенности. Относительно безопасная работа с памятью без сборки мусора не может быть совсем бесплатной, нужны ограничения. И никого, думаю, не удивит, что на каком-нибудь хаскеле не выйдет написать точно так же, как в плюсах.
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»? Есть, хотя и небольшое, русскоязычное сообщество, где будут рады помочь новичку.
Работа с памятью уже фатально меняться не будет. Нелексические одалживания, наверное, немного упростят код, но только немного. И я бы не сказал, что работа в этом направлении является какой-то особенно приоритетной для команды — совсем не факт, что это все сделают в ближайшее время.
>> в 90% приводится код, который на плюсах никто и никогда не пишет.
Обычно (в презентациях и статьях про Rust, которые мне вспомнились) приводятся короткие примеры, которые ясно демонстрируют проблему. Да, на практике никто прямо так не напишет, но реальные ошибки часто «размазаны» по большому количеству кода — не заталкивать же сотни строчек кода в презентацию.
Учитывая, что очень многие видят в Rust`е потенциальную безопасную альтернативу C++, то и упоминания C++ в разговорах о Rust мне не кажутся чем-то странным. В данном случае C++ упомянут как пример другого относительного низкоуровневого языка со статической типизацией и схожими сложностями при работе со строками.
Автор оригинальной статьи, думаю, никаких сложностей с fizzbuzz в любом варианте не испытывает, так как является одним из разработчиков Rust`а. Статья скорее о том, что многие новички, особенно имеющие только опыт работы с высокоуровневыми языками, часто спотыкаются на строках. Для работы с ними, все-таки, уже надо более-менее осознать систему типов и систему владения. Еще людей сильно смущает то, что просто типа «str» в языке нет.
Конкретно этот RFC нелексические одалживания сам не добавит, он может косвенно подготовить для них почву, ну да не суть.
Про «сэкономлю кучу времени как на изучении языка» — мы точно об одном и том же говорим? Можно пример кода? А то, судя по моему опыту, проблемы, которые должны решить нелексические одалживания, на данный момент решаются или созданием временной переменной или оборачиванием нескольких строчек кода в `{}` и все.
https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy
Звук пока не трогал совсем.
Для создания окна и получения ввода использую 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. Вроде, терпимо работает.
Саттер говорит, что он сначала сделал то что сделал, а потом уже пошел смотреть другие решения этой же проблемы:
https://www.reddit.com/r/cpp/comments/3m0d41/writing_good_c14_by_default_herb_sutter/cvcnmn5
Может, все-таки стоит разобраться, а не говорить «у меня не вышло написать как на <подставить язык>, rust явно поломан»? Есть, хотя и небольшое, русскоязычное сообщество, где будут рады помочь новичку.
Работа с памятью уже фатально меняться не будет. Нелексические одалживания, наверное, немного упростят код, но только немного. И я бы не сказал, что работа в этом направлении является какой-то особенно приоритетной для команды — совсем не факт, что это все сделают в ближайшее время.
Из какого? Насколько я знаю, именно такой работы с памятью, завязанной на владении/одалживании и изменяемости/неизменяемости не было.
>> Часть строгости является ошибками компилятора и это починят…
А можно подробней про «ошибки, которые починят»? Там же просто мелочи хотят подкрутить, и то не факт что сделают.
https://github.com/kbknapp/clap-rs же :)
Он даже был пакетом недели недавно — http://this-week-in-rust.org/blog/2015/09/14/this-week-in-rust-96.
Обычно (в презентациях и статьях про Rust, которые мне вспомнились) приводятся короткие примеры, которые ясно демонстрируют проблему. Да, на практике никто прямо так не напишет, но реальные ошибки часто «размазаны» по большому количеству кода — не заталкивать же сотни строчек кода в презентацию.
is.gd/SyVz0J:
println!("{}", 1i - 2)=>-1is.gd/MN2Py3:
println!("{}", 1u - 2)=>18446744073709551615