Comments 32
Короче говоря, проблема человека в том, что он всё пытается делать на Rust, без добавления DSL. Те же самые соображения можно привести для разработки GUI, когда в 90-х впервые появились Visual Basic или Delphi. Можно было бы сказать а вот мышкой я легко могу быстро собрать интерфейс и переделать его, а если писать всё в коде, то всё долго и сложно.
Вот хорошая была тема в Delphi. За пол часа делается прекрасный десктопный GUI. Мне очень не нравится сегодняшняя тенденция к веб интерфейсам. Старые делфиевские интерфейсы были удобнее, отзывчивее и теплее, ламповее всех современных веб интерфейсов, в которых даже правая кнопка мыши недоступна.
Проблема "За пол часа делается прекрасный десктопный GUI." заключается в том, что как только мы меняем системный фонт или DPI экрана или еще какие-нибудь параметры, которые влияют на рендеринг и различаются на компьютере пользователя и компьютере разработчика, то из "прекрасного" GUI превращается в "ужасный".
На старом Windows эта проблема была практически незаметна, тупо потому что у 99% пользователей стояли стандартные настройки и все было хорошо. А вот с тем-же web-ом так уже не получается.
Сразу нахлынули воспоминания о "Сайт оптимизирован для экранного разрешения 800х600".
Это проблема старого VCL и его работы в Windows. Более свежий VCL и развитие WinApi в плане DPI сильно продвинулось, но и это не всё. В Delphi есть и другие фреймворки, например FMX, который основан на отрисовке на GPU и не привязан к платформе. Другими словами, GUI на всех ОС будут выглядеть одинаково, если так нужно (можно и чтоб выглядели по-разному). И в этом фреймворке абсолютно не важно какой будет DPI, т.к. масштабирование идет векторное, равномерное. Более того, об этом даже можно не задумываться при разработке.
Так что эта проблема не связана с механикой дизайнера, а лишь следствие работы конкретной платформы.
Чтоб гуй не был ужасным, нужно всего лишь...
(Использовать относительные координаты и использовать константы на основе системных компонентов)
И тут в поле зрения врываются мобильные девайсы все цветов и размеров.
Я видел огромную кучу самого разного внутрикорпоративного софта, который не предполагается использовать нигде, кроме как на рабочих компьютерах внутри организации и оно все имело веб интерфейс.
Всё это имеет решения. С некоторых пор даже из коробки.
Здесь одно и то же приложение, только собрано под разные платформы: Часы (Android), винда, смартфон (iOS)
Конечно, под часы не совсем и адаптировано, но для них, в этом же проекте можно создать отдельное представление (скрыть лишнее, изменить шрифты и т.д.)
Ну человек прав в том, что все rust комьюнити этого не понимает.
То есть они пытаются писать движки вместо игр
Что не понимает rust-комьюнити? Что человек неправильно использует язык и пытается заниматься на нём быстрым прототипированием? В лучшем случае претензии можно высказать к авторам движков.
Только недавно сидел в группе одних ребят, пока они пилили движок для вокселей и делали гуй, я уже это сделал на С++ и успел прикрутить Lua, хотя я трачу на это раза в два меньше времени.
И таких случаев много, они создают нездоровый фон и стереотипы, понимаешь?
Не понимают целей и задач разрабатываемого ПО.
Можно двигаться быстро или медленно, но это не важно, если ты идешь не туда.
Я бы хотел, чтобы раст не просто радовал нас экзотикой, но был крутым инструментом, решающим реальные задачи. В данном случае - задачи игровой разработки, игры, инструменты, движки.
Для этого нужно не просто что-то там пилить, а пытаться понять, что пилить нужно.
Не понимают целей и задач разрабатываемого ПО.
Подозреваю, что большинству из тех, кто пилит движки (тот же беви) интересно как раз пилить движок. Учитывая, что это всё делается на добровольных началах, то странно предъявлять претензии к тому как люди тратят своё свободное время.
Да, было бы неплохо, если появился бы конкурент коммерческим движкам на расте, но я не уверен, что есть смысл это требовать от кучки энтузиастов.
Все так, энтузиастам никто и не предъявляет.
Но назвался груздем - полезай в кузовок.
Речь же идет и о том, чтобы сделать раст продуктивным инструментом для всех, включая профессионалов, разрабатывать на нем реальные большие проекты, а значит, в том числе и коммерческие.
Если, к примеру, энтузиасты ракетостроения начнут рассказывать как 3д принтеры могут помочь с печатью ракетных двигателей, они должны быть готовы к вопросам инженеров боинга "А что с масштабированием?" и "А какими материалами можно печатать?"
Так я же не спорю с претензиями к языку. Автор оригинальной статьи поделился ценным опытом, можно быть в чём-то не согласным, но мнение в любом случае полезно. Но после вот этой цитаты:
Ну человек прав в том, что все rust комьюнити этого не понимает.
То есть они пытаются писать движки вместо игр
Мне показалось, что мы обсуждаем конкретно то, что движки делают "не так как надо". Вот и высказался, что пока этим занимаются несколько энтузиастов в свободное время, то такие претензии не совсем по адресу.
Rust-комьюнити слишком одержимо rust'ом как таковым, оно ставит инструмент выше решаемой задачи, в результате чего каждый первый проект на расте становится шоукейсом правильности и возможностей раста, а не продуктом.
Заходите на гитхаб, и у большинства растопроектов в ридми описание уровня "Х is an awesome Y, WRITTEN IN RUST!!1".
Это как если бы плотник рассказывал вам что сделанный им стол особенно ценен ибо кромки столешницы обрабатывались фрезером Makita а не каким-то китайским ноунеймом, и не важно что качество обработки для клиента идентично а цена выше за счет амортизации стоимости оборудования.
I use Arch, btw.
Delphi тоже можно отнести к инструментам с DSL, т.к. представление формы (окна, GUI) - это описательный формат с иерархией, который описывает что и где нужно создать и с какими параметрами. Вполне допускается создавать форму как кодом (динамически), так и через этот формат вручную, без дизайнера.
DSL
Либо мы пишет DSL параллельно с игрой, и врюхиваемся в рефакторинги, указанные в статье. Либо пробуем написать DSL заранее, а потом на него натягивать игру. Но тут тоже легко напороться на проблему. Например, гейм-дизайнер вдруг захотел, чтобы в UI выбора персонажа крылышко утки вылезало за пределы менюшки, а мы свои UI-окна спроектировали как прямоугольники.
Добавлю еще одну проблему Раста. FFI тяжело внедряется, вероятно вам нужно сделать много сахара или вы попадаете в ловушку, где можете отстрелить себе ноги не хуже чем в С++, а веротяно лучше. Ведь вы идете по минному полю, но привыкли к безопасности.
Комюнити в расте молодцы, делают много, но общая тенденция не хороша, а скорее плоха.
Люди сделали себе несколько идолов : WGPU / ECS и безопасность, последнее конечно спорно.
А силы размазаны по всей экосистеме. По тоннам фреймворкам который пытаются делать одно и тоже, а делают это плохо. Как пример, переписывают SDL / GLFW (долго, с кучей ошибок и недостатком функционала), а так же 10ки других либ.
В общем грустно, но я в комнате ожидания нового языка для разработки игр...
Надо просто сделать байдинги раста и C#
А чем Питон не угодил? Пространство для оптимизации есть, игру можно сделать под Линукс и Винду одновременно, а писать на Питоне намного легче того же Раста.
Обычно оптимизация Питона заключается в том, что тяжёлый код выносят в библиотеку, написанную на Си. В играх часто столько тяжёлого кода, что их проще сразу писать на других языках, либо использовать Питон только для скриптов (как в Civilization 4).
Мои надежды в этом плане на Mojolang. Синтаксис Питона, стат. типизация, скорость компилируемых языков, плюс, если нужно, взрослые вещи вроде того же заимствования и т.д. Самый современный бэкэнд и автор Swift'а и LLVM во главе разработки. Для меня близкое к идеалу сочетание параметров.
А какие преимущества перед другими компилируемыми языками?
В технологическом плане:
Mojo построен на бэкэнде следующего поколения - MLIR
Хорошая эргономика SIMD
Ещё более раннее освобождение памяти, чем при RAII
Может работать даже быстрее Rust'а и в некоторых случаях занимать меньше памяти на 4 порядка (я сам не сразу поверил, не факт, что на практике такое встретится)
Идентичность значений, чего нет в Расте, и из-за чего в нём нужно использовать Pin, и что, в свою очередь, может приносить страдания :).
В плане синтаксиса:
Более приятный, лаконичный, менее "колючий" синтаксис по сравнению с Rust. Хоть и тяжелее, чем в самом Питоне, что естественно, так как добавлена стат. типизация.
В практическо-человеческом плане:
В планах Mojo стать полным надмножеством Питона, а это означает, что Mojo может автоматически получить целую армию программистов, которые его (Mojo) уже "знают".
Ну и возможность относительно легко внести "добавки" в свои проекты на Питоне и получить скорость и остальные преимущества полноценного компилируемого языка - по моему мнению дорогого стоит.
Собственно, про особенности языка в сравнении с Rust'ом подробнее в статье Mojo vs. Rust: is Mojo ? faster than Rust ? ?
Ну и нацеленность языка на AI и Data Science, вместе с мощным фреймворком MAX. А ещё обильное использование юникод-символов :)
Глобально же - обычный, только технологически современный компилируемый язык.
Не взлетит, это язык-костыль созданный потому что математиков невозможно обучить программировать на чем-то сложнее питона.
Довольно слов, покажите мне игру на Яисте)
> Какое же можно использовать решение? Как и во многих случаях с Rust, мы с коллегой испытали эмоцию ?, а затем поменяли код на такой:
```
if let Some(character) = &self.selected_duck.clone() {
character_select_duck_detail(.., character, self);
} else {
character_select_no_duck(...);
}
```
Не имею такого колосального опыта как у Вас с коллегой, но почему нельзя сделать так:
```
if self.selected_duck.is_some() {
character_select_duck_detail(.., self);
} else {
character_select_no_duck(...);
}
```
А уж внутри функции прочитать значение `self.selected_duck` как Вам угодно?
Почему я отказался от разработки игр на Rust, часть 2