Волшебства не делают — на выходе дают очень неидиоматичный код, наполненный сишными типами, сырыми указателями и unsafe'ом — т.е. годится только как первый шаг в портировании кода на раст.
Комментарии нарративщиков выше прям грусть навевают — вот жеж прям все прям игры делают исходя из сюжета или атмосферы, а игровые механики это, якобы, дело десятое уже :-\ .
Немного удивлен, что в статье не упомянуты бумажные аналоговые прототипы — для каких-нибудь пошаговых игр (или просто где нюансы взаимодействия в реальном времени не критичны) невероятно время может экономить же, особенно если еще понадергать физических проксей из уже готовых настольных игр.
мне кажется, что RFC в IETF, IAB и ISOC не пересекаются, и RFC однозначно можно было найти по номеру
Вполне может быть что так, это все ж таки связанные организации и их RFC находятся в одном "пространстве имен". Хотя я не то что бы прям сильно в теме как это все структурно устроено.
до тех пор, пока не появились ржавые RFC, которые уже пересекаются
Я не уверен что Rust это первый проект, который стал свои формализованные предложения обзывать "RFC": быстрый гуглеж показывается как формальные "MS RFC" еще аж в 2006ом году, так и просто неформальное использование аббревиатуры, например, на форумах D в 2011ом. А за последние годы так вообще распространенной практикой стало (хотя это уже, возможно, под влиянием ржавчины): emberjs/rfcs, yarnpkg/rfcs и еще десятки.
В общем, видимо, если контекст неоднозначен и есть шанс запутаться, то лучше сразу писать "<ИмяПректа> RFC <номер>".
Для 3D графики использовалась библиотека Three.rs которая является портом библиотеки Three.js
three-rs не настолько близка к 3js, что бы портом называться, она просто вдоховлена 3js. Так же как amethyst — не порт (уже мертвого) Стингеря, а ggez — не порт LÖVE.
Как бы там ни было с правилами роутинга, речь же просто о дизайне одной из библиотек, а не всего языка, у rocket.rs вполне себе есть живые ржавые альтернативы.
Да, походу в совсем узкой консоли имена компилируемых пакетов не показываются и все окей. А вот если сделать 90-100 шириной, то справа от индексов компилируемых пакетов показываются их имена и они уже не влезают в границу строки нормально. :(
Новый прогрессбар так себе помещается в узкие вертикальные консоли по 90-100 символов, но не могу найти опций cargo для его отключения. Никто не натыкался?
Cтолько срачей вокруг закрытия как раз потому что это вовсе не какая-то особенная ситуация для крупных и не очень игровых студий, это беда всей неокрепшней индустрии. Бизнес довольно рисковый, держать студии на плаву сложно, желающих делать игры очень много — почти все прибегают к подходу "выжмем вот этих с горящими глазами, а потом на их место возьмем новых". Просто так люди о профсоюзах говорить на начнут.
Черт, жалко :( Остальными играми не сильно проникся, но первый волк чем-то прям зацепил. Как-то особенно хорошо к его сеттингу и истории ложились телтейловские игровые и повествовательные механики.
Не уверен, может это и имелось в виду, но обычно советуют c уже написанными проектами переходить по схеме "в целом проект остается на чем он и был написан, но новую функциональность мы реализуем на Rust, переписывая только самый минимум нужных для этого модулей". И постепенно-инкрементально проект и разработчики перебираются на ржавую сторону.
По этой теме недавно доклад от разработчиков Tor'а был на растконфе:
Это все раво не так просто как с самого начала проект на расте начать, конечно, но уже намного более реальный путь чем "просто берем и RIIR!!! переписываем разом весь код ржавчину", о котором многие думают в первую очередь.
надо учить язык, а он окончательно ещё не устоялся
Этот момент немного смутил. Если речь о том что какой-то конкретной вещи в языке еще не хатает (async/await того же) — может и имеет смысл подождать ее выпуска и стабилизации.
Но в целом, 1.0 с гарантиями обратной совместимости давно уже вышел и однажды написанный корректный код так и продолжит работать, а какие-то доработки в язык так и будут вноситься до самой его смерти скорее всего.
Для Си есть, как минимум, два более-менее живых:
Волшебства не делают — на выходе дают очень неидиоматичный код, наполненный сишными типами, сырыми указателями и unsafe'ом — т.е. годится только как первый шаг в портировании кода на раст.
Можно тут почитать отчет о недавней попытке использовать для портирования библиотеки: https://wiki.alopex.li/PortingCToRust
Комментарии нарративщиков выше прям грусть навевают — вот жеж прям все прям игры делают исходя из сюжета или атмосферы, а игровые механики это, якобы, дело десятое уже :-\ .
Немного удивлен, что в статье не упомянуты бумажные аналоговые прототипы — для каких-нибудь пошаговых игр (или просто где нюансы взаимодействия в реальном времени не критичны) невероятно время может экономить же, особенно если еще понадергать физических проксей из уже готовых настольных игр.
У mkpankov есть об этом вопросе заметка на rustycrate — https://rustycrate.ru/обучение/2017/06/11/oop-in-rust.html — и есть целая глава в растбуке — https://doc.rust-lang.org/book/second-edition/ch17-00-oop.html (перевод).
Вполне может быть что так, это все ж таки связанные организации и их RFC находятся в одном "пространстве имен". Хотя я не то что бы прям сильно в теме как это все структурно устроено.
Я не уверен что Rust это первый проект, который стал свои формализованные предложения обзывать "RFC": быстрый гуглеж показывается как формальные "MS RFC" еще аж в 2006ом году, так и просто неформальное использование аббревиатуры, например, на форумах D в 2011ом. А за последние годы так вообще распространенной практикой стало (хотя это уже, возможно, под влиянием ржавчины): emberjs/rfcs, yarnpkg/rfcs и еще десятки.
В общем, видимо, если контекст неоднозначен и есть шанс запутаться, то лучше сразу писать "<ИмяПректа> RFC <номер>".
А, извиняюсь, я чего-то подумал что вопрос значил "как в расте отличают RFC от членов команды разработки и RFC от внешних людей из интернета?".
По умолчанию "RFC" значит именно ржавые, а для IETF, IAB, ISOC или еще каких явно указывается префикс организации:
В идеале, никак не должны отличаться. По крайней мере процедуру одинаковую проходят.
Кстати, у движка GGEZ есть хороший пример/урок про змейку с подробными пояснениями почему и зачем так сделано.
three-rs не настолько близка к 3js, что бы портом называться, она просто вдоховлена 3js. Так же как amethyst — не порт (уже мертвого) Стингеря, а ggez — не порт LÖVE.
В теории можно, но используемый three-rs движок в данный момент не поддерживает WASM.
Если говорить о ржавых 2д движках, то недавно слышал что quicksilver сравнительно прямолинейно в вебе заводится.
Сколько людей, столько и определений слова "рогалик".
Как бы там ни было с правилами роутинга, речь же просто о дизайне одной из библиотек, а не всего языка, у rocket.rs вполне себе есть живые ржавые альтернативы.
Да, походу в совсем узкой консоли имена компилируемых пакетов не показываются и все окей. А вот если сделать 90-100 шириной, то справа от индексов компилируемых пакетов показываются их имена и они уже не влезают в границу строки нормально. :(
Новый прогрессбар так себе помещается в узкие вертикальные консоли по 90-100 символов, но не могу найти опций cargo для его отключения. Никто не натыкался?
У него и так проблемы намечаются с тревисом: https://blog.travis-ci.com/2018-10-11-windows-early-release
Меня вот эта часть немного смутила. Правильно понимаю, что речь не идет о проектах, где много обсуждений проходят таки в задачах и ПРах?
Изоморфность?
Cтолько срачей вокруг закрытия как раз потому что это вовсе не какая-то особенная ситуация для крупных и не очень игровых студий, это беда всей неокрепшней индустрии. Бизнес довольно рисковый, держать студии на плаву сложно, желающих делать игры очень много — почти все прибегают к подходу "выжмем вот этих с горящими глазами, а потом на их место возьмем новых". Просто так люди о профсоюзах говорить на начнут.
Черт, жалко :( Остальными играми не сильно проникся, но первый волк чем-то прям зацепил. Как-то особенно хорошо к его сеттингу и истории ложились телтейловские игровые и повествовательные механики.
Хм, мне не кажется что оно сильно имеет смысл, но вот спросил — https://github.com/rust-lang-nursery/rustfix/issues/146 — можно подписаться.
Не уверен, может это и имелось в виду, но обычно советуют c уже написанными проектами переходить по схеме "в целом проект остается на чем он и был написан, но новую функциональность мы реализуем на Rust, переписывая только самый минимум нужных для этого модулей". И постепенно-инкрементально проект и разработчики перебираются на ржавую сторону.
По этой теме недавно доклад от разработчиков Tor'а был на растконфе:
https://www.youtube.com/watch?v=WI4ApeHH9QE
Это все раво не так просто как с самого начала проект на расте начать, конечно, но уже намного более реальный путь чем "просто берем и
RIIR!!!переписываем разом весь код ржавчину", о котором многие думают в первую очередь.Этот момент немного смутил. Если речь о том что какой-то конкретной вещи в языке еще не хатает (async/await того же) — может и имеет смысл подождать ее выпуска и стабилизации.
Но в целом, 1.0 с гарантиями обратной совместимости давно уже вышел и однажды написанный корректный код так и продолжит работать, а какие-то доработки в язык так и будут вноситься до самой его смерти скорее всего.