Comments 81
Итого: Rust мешает делать тяп-ляп и в прод, а надо.
естественно, зачем им конкурент
Раст мешает быстрому прототипированию. В прод это и не должно пойти.
Я так понял мысль автора
Не в оправдание проблем, но кого мы обманываем.
Для каждой задачи нужен свой инструмент. Если писать ОС, системные утилиты или скажем браузер - раст отличный выбор.
Но есть задачи, где много исследовательской деятельности. К таким относятся, например, ML или создание игр. Здесь нет четкого понимания, что надо сделать. Есть десятки или сотни экпериментов. Из них будет один удачный, который уже можно аккуратно запрограммировать. Для таких задач раст, как будто, и вправду не лучший выбор. Он не позволяет писать некачественно даже то, что заведомо будет выброшено.
Я прекрасно понимаю, как пишутся игры.
И согласен с посылом статьи.
"В прод это и не должно пойти"
Я про это. Кого мы обманываем, прототипный код регулярно идет в релиз.
Бывает, конечно. Но писать игры на раст, чтобы это исключить, выглядит неоптимальным решением. Исключить говнокод в проде можно более дешевым способом.
Конечно
Все равно как итог мы приходим к тому, что нужна более простая и понятная платформа для геймдизайнеров и редактор
И с этого момента с одной стороны, нет смысла всех учить разнице между передачей по ссылкой и копией, с другой стороны, ошибки зачастую вообще не относятся к теме безопасности, а относятся к теме поведения. Иными словами многие "баги" - это скорее случайные фичи, никакая безопасность кода с ними не поможет, потому что мы упираемся в конечное описание правил того, что есть конкретная игра.
А потом удивляются, почему в геймдеве зарплаты ниже, и истерик больше...
Ну вероятно все же не по этому.
В других отраслях плохого кода достаточно.
В геймдеве зарплаты ниже, потому что там больше энтузиастов, особенно в дизайне. Это жеж игры делать.
Вот не понимаю этого. Что интересного в желании игр? Нудная работа. Движки делать интересно, а вот сами игры уже нет. Какое ни будь финансовое ПО интереснее делать. Ну а самое интересное это делать что то где в основе лежит сложная мат. модель.
Думаю люди думают, что это почти то же самое, что играть в них.
Это не совсем правда, но отдельное удовольствие в создании игр безусловно есть.
Но, разумеется это довольно интересно. Я думаю все же типичные задачи по созданию игровых правил, тестированию прототипов и прочее все же поинтереснее типичных задач из других отраслей, типа клепания формочек. По крайней мере из моего опыта.
Создание движка и создание игр действительно разные, по своему увлекательные задачи.
Я раньше тоже по сути больше движки делал, чем игры. Но сейчас все сдвинулось в разработку геймплея и интерфейсов всеже.
В геймдеве - все мечтают стать Кармаками и купить себе Феррари после успеха игры, и потому согласны "потерпеть" ради такой цели.
По мне так, чем меньше языков тем лучше. Веб видели, тащить всё это в десктоп?
Не столько прототипированию, сколько склеиванию прототипов воедино. Ибо грязный код в соседнем минипроекте завёлся, но чтобы добавить его в игру нужен очередной рефакторинг кода. И это наиболее слабая сторона Rust - сигнатуры начинают протекать везде по коду, если ты хочешь быть все также быстр, а не иметь миллион .clone() .
В том же Хаскеле, где система типов очень жёстко держит программу, есть приёмы, позволяющие легко делать наброски:
не пишем сигнатуры функций/пишем излишне общие -
functionF :: a -> b -> cэкспортируем всё из модуля
включаем модули целиком
import Data.Listвставляем
undefineгде ни попадя (и, соответственно, прописываем частичные сигнатуры где нам нужно прямо в середине текста, что ухудшает читаемость)
Разумеется, в PROD коде это всё недопустимо/нежелательно, но в черновиках вполне себе. Вполне возможно, что и в Rust, когда делают наброски, надо вести себя примерно также. К примеру, работать сразу в режиме unsafe.
Вообще, во многих языках есть свои практики для ускорения разработки. К примеру, в Питоне нужно любой написанный кусочек кода прогонять в REPL.
И всё таки прототипирование в Хаскеле делается очень и очень медленно.
Даже в питоне, или в каком ни будь js прототипирование медленное. А знаете где прототипирование быстрое? А в экселе! Особенно если в excel сделать линковку на некоторые таблицы mdb access (а в mdb линковаться на некоторые таблицы из excel) то вообще что угодно можно запротипировать за пол дня. Экселевские таблички с их формулами, плюс возможность писать на лету запросы к этим экселевский табличкам в аксессе, а результаты этих запросов снова обработать в экселе, позволяют накидать бизнес логику любой сложности в кратчайшее время.
А знаете где прототипирование быстрое? А в экселе!
Так это функциональщина с динамической типизацией. Причём на грани визуального программирования.
Вы Пролог пробовали? Там, к сожалению, стандартная библиотека относительно бедна, но для ряда задач алгоритмы получаются в разы короче чем на Хаскеле.
Я тут нашёл чудесный сайт-книжку по современному использованию Пролога — https://www.metalevel.at/prolog (The Power of Prolog). Очень полезно то, что автор является современным практиком-энтузиастом, и поэтому позволяет не оставаться в 80х в обнимку с Бортко.
Пробовал Пролог когда то давно. Прикольный язык. Но ведь все, что он делает, это просто задаёт обход графа в декларативном виде. И мне показалось, что проще самому обойти нужное дерево императивно. Возможно это потому, что я очень поверхностно с ним познакомился, но я так и не понял, какой во всем этом смысл?
За ссылку на книжку спасибо. Как ни будь полистаю. Может даже пойму что такое может пролог, чего не может обход графа вручную ))
Если это трололо, то прекрасное. Если серьёзно, то лучше бы было трололо :)
Поэтому мы нагородим целую систему с параллельным индексированием и ЖЦ поверх (ECS) и будем игнорировать безопасность раст на высоком, архитектурном уровне.
Ну да, ECS как раз для ситуаций, когда ты до самого дня релиза не знаешь, что пишешь.
На самом деле нет, ECS это архитектура, обеспечивающая высокую производительность при сравнительно хорошей организации сущностей.
Ну то есть да, как и прочие подходы к написанию игр она достаточно гибка, но суть то не в этом.
Не нужна целая ECS со специфической организацией игровых сущностей, чтобы писать гибкий код.
Итого: Rust мешает делать тяп-ляп и в прод, а надо.
Мда. Неудивительно, что автор пишет такое:
Общение с сообществом Rust же часто похоже на разговор с подростком о любых его предпочтениях. Заявления пользователей часто оказываются категоричными мнениями, не имеющими особых нюансов. [...] Доминирование перфекционизма и одержимости «правильным способом» в экосистеме Rust часто заставляет меня думать, что этот язык привлекает новичков в программировании, легко поддающихся влиянию.
Кстати говоря, мои личные впечатления от общения с сообществом раста где-то совпадают с этим описанием.
Нет. Rust - это язык, который заставляет тщательно продумывать работу над всеми ошибками, включая редкие. Зачем вообще было браться, если неохота этим заниматься? Он бы ещё на Коке попытался тяп-ляп делать, и говорить, что это неудобно.
Я думаю в этой цитате автор статьи говорит о себе самом: это он поддался влиянию и не разобравшись выбрал Rust, когда для его задач и стиля работы он не подходит. Конечно, спустя годы тщетных попыток поменять под себя Rust, он теперь обижен.
P. S. Я более пяти лет профессионально разрабатываю на Rust, поэтому думаю, что имею право полемизировать с автором статьи, особенно в общеязыковых вопросах, а не специфически игровых (хотя тот же Bevy я использовал и свой собственный GUI на Rust писал).
Rust это язык специально сделаный для перфекционистов. С заметно большей практической жилкой, чем Haskell, но всё равно, "компилятор будет лупить тебя плёткой пока ты не сделаешь как положено" - это не проблема, это sales pitch.
Rust мешает реализовать идею в коде! У программного обеспечения есть этапы жизни и самую базу, наиболее творческий процесс, где необходима реализация идей Rust гробит — это большая проблема, я бы даже сказала это самая главная проблема Rust.
При этом я совершенно за то, чтобы уже готовые и развившиеся проекты или компоненты больших систем переписали на Rust. Примеров таких масса, например ruffie, части Firefox, части Windows и Linux.
Скорее:
что в коммерческой разработке игр продаются хорошие игры а не идеальный код
что не окупаются усилия по вылизыванию кода в игре, срок жизни которой примерно равен сроку хайпа, т.е. до полу года.
что грустно рефакторить и вылизывать код, а потом приходит гейм-дизайнер и говорит: а давайте по другому все сделаем.
и наконец нашлись мыши, которым надоело колоться.
Я в целом согласен с посылом статьи, хотя тут и намешано много разных идей.
Я бы сформулировал это как несколько разных тезисов:
Rust отличный язык, но у него есть ограничения и недостатки. Ставя во главу угла надежность и Zero Cost Abstractions, он увеличивает как порог входа так и сложность разработки
Требования к инструментам могут быть противоречивы. Разработка игр требует высокой скорости итераций, крайне позднего связывания и data-driven дизайна. Некоторые особенность rust противоречат этим требованиям, поэтому движки и пытаются их исправить. В частности те же ECS отказывается от нативного обращения к данным по ссылкам и контроля ЖЦ, создавая свою систему поверх (индексы через сущности и свой контроль времени жизни сущностей)
ECS сама по себе является очень специализированной архитектурой для разработки высокопроизводительных игр. Она хоть и позиционирует себя как хорошую замену классической организации объектов, на самом деле накладывает крайне много сложных ограничений на организацию кода, данных и логики и не совсем помогает в создании простого кода. То есть мы платим за эту производительность по умолчания более сложной организацией кода по умолчанию. В случае же нарушения этих ограничений мы вероятно ухудшаем производительность
Как итог, rust все еще не является хорошим инструментом для разработки игр по умолчанию. Хотя и имеет серьезные возможности стать им в будущем в силу специфики.
А потом мы удивляемся, что в ААА игре можно провалиться в текстуры и пройти сквозь непися
Напомнило старый добрый доклад про от одного из первопроходцев ржавого геймдева Кэтрин Уэст. Проблемы известны с ещё с момента появления геймдева на ржавчине, видимо поэтому в какой-то момент и появились всякие Any и глобальный объект мира.
Знаю, что это перевод, но всё равно напишу: на rust есть довольно любопытный движок Fyrox, он выглядит более зрелым инструментом, по сравнению с Bevy (в частности, из коробки есть весьма функциональный редактор).
Вообще не очень понравился язык повествования автора, он вначале много оправдывается, а потом говорит так, что кажется, что ему чем-то должны. Ну вот действительно, многие вещи реально требуют вот прямо разобраться, об этом ему много раз указывали, но вот так мир устроен, что тут поделаешь, но тут это звучит как некоторая претензия.
А по факту да, в Расте сложно делать любые задачи где есть ациклические графы - это вообще не секрет, для таких задач, кажется, лучше подходят языки со сборкой мусора. По сути арены это и есть специализированные реализации сборщиков мусора.
Это не про обход BC, его вообще глупо воспринимать как противника. Это история про обход его ограничений. Мне кажется, что точка зрения на проблему сама по себе даёт очень много для ее решения и негативное восприятие как раз и приводит к появлению таких статей.
Претензия в том что это плохо стыкуется с продуктивным геймдевом. Ты можешь написать идеальную игру с отличным геймплеем, но вместо полугода на прототип ты потратишь 3 только на рефакторинг.
Ну так Раст для этого слишком низкоуровневый и так сказать душный. Но блин, для самой логики игры больше какой нибудь dsl подойдёт, а Раст для условно говоря, движка для этого dsl.
С одной стороны да, с другой стороны скриптовый язык привносит своё легаси, которое будучи писанно гд, а не программистом начинает заметно тормозить проект, заставляя как дублировать логику, прокидывая интерфейсы в скриптовый язык, так и делать упражнения вприсядку, пытаясь соптимизировать то что там гд понафигачило. Как-то так Jon Blow и стал писатьсвой собственный язык Jai, дабы сохранять достаточно низкоуровневую систему, но при этом достаточную для того же скриптования и с быстрым циклом изменений - компиляция занимает меньше секунды в сравнении с тем же Rust (полминуты на инкрементальных сборках) или C++ (бесконечность не предел).Правда для сохранения скоупа Джон шарит компилятор языка через рассылку и только иногда, поэтому если кто-то хочет причаститься может потрогать альтернативу.
поэтому если кто-то хочет причаститься может потрогать альтернативу.
Спасибо большое за наводку, очень интересный язык!
вещи реально требуют вот прямо разобраться, об этом ему много раз указывали, но вот так мир устроен, что тут поделаешь, но тут это звучит как некоторая претензия
Почему-то мне это напоминает некоторые наезды на C++.
В C++ при желании можно сделать все что хочется и как хочется. Среда не указывает вам как писать- каждый себе сам злобный Буратино. Что в принципе правильно -если программист хочет себе проблем - не надо его удерживать.
При этом что, не надо "вот прямо разобраться"?
Rust - это заботливый родитель, который говорит, что можно делать, а что нельзя. Он похож на неопытного родителя, потому что запрещает слишком много, но он постоянно набирается опыта и постепенно учится общаться с разработчиком, давая ему больше свободы. Это идеальный баланс между производительностью и удобством.
C++ - это естественный отбор; свободный мир, где ты можешь создать как рай, так и ад, добро и зло. Он позволяет тебе делать все, включая возможность выстрелить себе в ногу. Ты никогда не будешь уверен, что делаешь все правильно, но всегда можешь посоветоваться с другими разработчиками, чтобы узнать, как они построили свой "велосипед". C++ один из лучших языков с точки зрения практической производительности.
Haskell - это опытный, но старый родитель - дедушка (отец Rust), бывший профессор, который всегда поможет и расскажет что-нибудь интересное из своего прошлого (начало ML и функционального программирования), поможет советами (классы типов), но не будет мешать. С ним всегда интересно, но никто не воспринимает его всерьез - для всех он просто дед, пережиток прошлого и история. Потомки обращаются к нему за помощью в теоретической части (удобство языка).
А javascript тогда кто? Дочь-проститутка?
Младший брат-даун. С таким же близнецом-Go
А Lisp кто? =)
Лисп - это мудрый и эксцентричный дядя (настолко эксцентричный что редко покидает свой замок в Трансильвании), который живет в своем мире и мыслит иногда настолько нестандартно, что тебе приходится выбросить из головы не только "все чему учили в школе", но и "best practices" индустрии.
В отличии от Rust он не пытается тебя ограничивать "как бы чего не вышло", в отличии от С++ - не бьет по рукам кувалдой, вместо этого он просто позволяет творческому процесу не создавать проблем - тебе не нужен Rc<RefCell<T>> потому что в языке уже есть быстрый GC, но если ты хочешь - ты можешь придумать что-нибудь свое - и это будет удобно сосуществовать с тем что уже придумано до тебя - без необходимости переписывать мир, потому что в Lisp типизируются не переменные а значения. И это позволяет лепить прототип так как ты захочешь, а перед релизом вдруг обнаружить что он написан на каком-то своем диалекте Лиспа, который включает все необходимое для конкретной этой игры. И если ты вдруг хочешь большей строгости - то твой дядя поможет написать тебе минимальный компилятор этого [твоего суб-диалекта] с разнообразными проверками статическими и динамическими.
Но будем честными, если тебя покусал этот твой дядя, то разработка игр становится уже куда менее интересной чем разработка новых Lisp-ов..
Хотя в последнем утверждении я может погорячился, иначе не было бы статей https://habr.com/ru/articles/767342/ "Геймдев на Lisp. Часть 1: ECS и металингвистическая абстракция"
C++ это свобода ^^
Ололо, у растишек бомбит от справедливой критики.
"ололо"? в 2024??
Это же @humbug, у него три статьи про раст в топе-10 всех лучших в хабе за всё время. Ирония его коммента очевидна, чего вы его так душите)
Браво автор.
Наконец кто-то не поленился расписать всё изнутри, без упоротости и фанатизма. Раст весьма нишевый продукт совершенно непригодный для генерального использования. Именно поэтому на нём за столько лет ничего серьезного так и не было написано.
А "серьезное" это что?
Боньк, это не так. Воть https://habr.com/en/articles/811163/#comment_26781483
GPU драйвера для M1 Маков, крупнейшая система для "карточек" для Spaced Repetition - Anki, один из более популярных терминалов для Linux - Alacritty, многие части бэка Discord, Deno и достаточно много других крупных и серьёзных проектов. Единственная проблема Раста для более "общего" применения - отсутствие серьёзного GUI фреймворка, так как Tauri не считается, а Iced/Slint не слишком готовы для полноценного продакшена
Если под "генеральным использованием" подразумевается "золотой молоток", то по определению для этого ни один язык программирования не пригоден.
Иногда интерпретация благо, иногда - зло. Иногда сборщик мусора благо, иногда - зло. Иногда ассемблерные вставки или intrinsics машинных команд благо, иногда - зло. Иногда декларативное программирование благо, иногда - зло. И таких примеров множество.
Очевидный недостаток Rust - общепризнанные шаблоны проектирования на нем либо не работают вообще, либо не работают в лоб, и нужно приседать. А шаблонов для конкретно Rust пока не систематизировали.
А можете привести примеры таких шаблонов проектирования?
https://github.com/fadeevab/design-patterns-rust?tab=readme-ov-file вот примеры для гоф, разной степени устрашения.
Я сходу ничего страшного не увидел, максимум известный подход Rc<RefCell<T>>. Можете указать куда конкретно смотреть?
То есть вас сам факт безальтернативного требования синхронизационных сущностей не смущает? При том, что он непортабельный, и для многопотока уже может понадобиться Arc<RwLock<>T>, да и в целом концепция владения тут явно мешает не берется во внимание..
Ну в джаве или плюсах для мнопоточности вам тоже понадобиться писать критическую секцию так или иначе, если вы планируете изменяемый доступ к объекту в рамках гонки. Раст просто не дает изначально допустить ошибку, требуя реализации send/sync при многопоточности. А концепция владения не исчезает, а переносится в рантайм, при RefCell у вас всеравно только одна мутабельная ссылка может быть.
Вот это вот выглядит прямо дико, и так точно не стоит делать.
https://github.com/fadeevab/design-patterns-rust/blob/main/creational/factory-method/render-dialog/gui.rs#L14
Но в целом, там ничего супер ужасного нет, просто многое из этих паттернов в Расте иначе называется и немного иначе применяется. То есть тут просто не учитывается специфика и идеология языка, но если включить голову и не использовать паттерны как есть, то все будет прекрасно.
Плюс в языке есть и свои хитрые паттерны, которых нет в оригинальной GoF.
Спасибо за очень интересную и познавательную статью.
В чём-то укрепил своё мнение касательно Rust.
Ещё Джонатан Блоу на своих стримах говорил, что Rust будет сильно мешать на этапе прототипирования, и что если бы он писал Braid и Witness на Rust, то из-за потери в скорости итерации на 10-15% его игры просто не дожили бы до релиза.
Данная статья подобное рассуждение по сути подтверждает.
Спасибо за статью. Да, Rust заставляет заморочиться. Но хорошо там, где нас нет. У других ЯП и их экосистем есть свои плюсы и минусы, везде есть свои заморочки. И бывает, что если смотреть по верхушкам, то всё красиво, а если копнуть, то выяснится, что не всё так радостно. Автор не сказал, на что он хочет пнресесть с Rust'а?
Эпическое чтиво, уже который день вечерами читаю оригинал статьи. Я конечно имею не настолько длинный и тесный опыт с Bevy и Rust в разрезе геймдева, но меня посещали все те же мысли, что автора, каждый раз, когда я пытался в Amethyst или Bevy, особенно в плане того, что ты безальтернативно должен оставаться в парадигме ECS, а не прибегать к нему только, когда тебе кажется это необходимым.
Еще в оригинальной статье есть интересный поинт про hot-reload (эта часть перевода еще не дошла до той части), о котором я не задумывался - что, даже если тебе кажется, что тебе не так уж и нужен hot-reload для разработки игры, то это значит, что ты просто не имел опыта быть в цикле разработки, где есть hot-reload, и что это в какой-то мере game-changer, потому что ты на лету можешь творить такую дичь о которой и не мечтал при привычном пайплайне "внес изменения -> пересобрался -> запустился -> проверил -> повторяем по-кругу до потери пульса"
Хочу перейти автостраду в неположенном месте, но вот понастроили заборов - не пролезть. Что такого то, вон же вижу машин сейчас мало, вполне мог проскочить бы.. Другое дело где-нибудь в Индии (сам там не был, сужу по видосикам, извиняюсь если необъективно) - едем как хотим, ни заборов ни правил, можно поперёк или по встрече если так короче. Продуктивно!
Аналогия конечно ложная, но текст мной воспринимается именно так )
То, что Rust прекрасен в рефакторинге, в основном решает его собственные проблемы с borrow checker
А вот и нет. Проблемы с borrow checker на 90% уходят по мере привыкания к нему. А вот то, что Rust прекрасен в рефакторинге, позволяет с меньшими усилиями развивать быстро меняющийся проект. Я на практике в этом убедился: Rust лучше, чем другие популярные языки подходит для "выращивания" проекта, создания MVP и далее его развития малыми силами.
На других языках можно писать код с мыслью «потом я это выкину»; для
меня это один из самых полезных подходов для создания хорошего кода.
Вот именно! С иллюзорной мыслью «потом я это выкину»: чаще всего код не выкидывается, а встраивается в проект, особо не меняясь. И тут как раз преимущество Rust в том, что он позволяет управлять гораздо большим проектом, гораздо большей сложностью меньшими силами. Преимущество его строгости, а также экономия сил и времени проявляются не в моменте, а в процессе роста проекта.
Самая фундаментальная проблема заключается в том, что borrow checker вынуждает выполнять
рефакторинг в самые неудобные моменты. Разработчики на Rust считают это
положительным моментом, потому что это заставляет их «писать хороший
код», но чем больше я работаю с языком, тем сильнее сомневаюсь, что это
так. Хороший код пишется благодаря итеративной работе с идеями и
экспериментам, и хотя borrow checker может заставить увеличить
количество итераций, это не означает, что таков желательный способ
написания кода. Часто я обнаруживал, что именно невозможность просто
пойти дальше, решить свою задачу, а проблему устранить позже, мешает
писать хороший код.
Людям, привыкшим к REPL, действительно, бывает сложно не то что использовать Rust, а вообще использовать любой компилируемый язык программирования со статической типизацией. Ну вот не могут они выражать свои идеи в типах и получать обратную связь от компилятора, им обязательно нужно пихнуть результат в строку и распечатать.
Если человек не хочет отказываться от привычного REPL, то ему действительно будет нелегко программировать на Rust. Есть ли области применения, для которых хорошо подходит только такой стиль? Может быть это геймдев, я не настолько опытный в нём, чтобы спорить с автором статьи. Пока то, что я вижу в околоигровой экосистеме раста - это разработка как статического, так и динамического инструментария. Предполагаю, что там делается попытка научиться использовать оба подхода.
Есть бизнесс, а есть работа по созданию нового и лучшего. Понятно, что геймдев экосистема в Rust на голову проигрывает экосистеме C++ и C#. Если вас интересует именно бизнесс и прямо сейчас - кажется, Rust будет не очень хорошим выбором. Это сегодня. А завтра ситуация вполне может измениться на противоположную. Благодаря тем, кто делает не деньги, а дело, кто работает не ради сиюминутной выгоды, а добивается стратегического превосходства. Каждому своё.
Почему я отказался от разработки игр на Rust, часть 1