Я так и не понял. Они хотят сделать проприетарную игровую консоль, конкурент PlayStation или открытую портативную платформу конкурент SteamDeck и прочим?
Если портативку по типу SteamDeck, то игры уже есть в стиме, который прекрасно заводится на линуксах, и через трансляцию с помощью Proton запускает виндовые игры. Пускай железячку собирают, тестируют Wine/Proton, пересобирают и переписывают под российские процессоры, и вперёд. Отечественные мобильные процессоры, которые реально поставить в такую железку у нас есть. Литьё пластика у нас осуществляется. Платы у нас производятся. Кнопочки, стики и прочее я думаю за годик, параллельно с написанием софта сделать смогут, все материалы и компетенции имеются у нас. Только поработать немножко нужно, вместо распила бабла.
Если желают консоль, подрубаемую к телику. То пожалуйста, современные консоли в себе содержат всё то же самое что компьютер. Возьми отечественный ноутбук, вынь из него экран, поставь в него графику и сделай красивый корпус. Поставь на него линух, с юзер френдли оболочкой, вот тебе консоль. Но графики у нас Российской, нет такой, которая бы могла запускать современные игрушки, придётся импортную ставить как-ни-крути. Если эту платформу тоже открытой делать, то окей Proton всё ещё работает, форкнуть и допилить драйверы можно, кадры способные на это у нас есть. Если же хотят поиграть в Российскость и проприетарность. То для них плохие новости, эра консолей к концу подходит, не вовремя они это. Да и консоли сейчас рассматриваются как Starter Pack молодого геймера, купил за 30 тысяч коробочку, оплатил подписочку и сидишь довольный за мало денях играешь довольный. Консоль Российская будет дорого стоить, потому что опт маленький. Да и очень сомневаюсь что Lesta будет разрабатывать эксклюзивные игры для неперспективной проприетарной консоли, да ещё и столько, чтобы тебе постоянно было во что играть.
Вместо того, чтобы хернёй заниматься. Лучше б денежку выделили на разработку графических процессоров, и интеграцию с отечественными центральными процессорами как существующих зарубежных GPU, так и в перспективе отечественных. Тем более, что GPU какие никакие у нас имеются всё таки, профинансируйте, скажите хотим, чтобы вы адаптировали и промасштабировали для игр ваши GPU, вот вам деньги, когда сделаете, мы купим, будем консоли продавать с ними, или игры под них поручим писать.
Василий Шпак, вообще человек не глупый как мне показалось, надеюсь примет верное решение об отказе о такой инициативе, и сосредоточится на более важных вещах.
У вас в любом случае после того, как процессор посчитал расположение частицы, она уходит потом на GPU, и рисуется шейдером. Вся разница в том, где именно вы считаете её положение, на CPU и отправляете только положение, или и положение тоже на GPU в собственном шейдере
У Сей UB написанное программистом косвенно развязывает компилятору руки на то, чтобы творить дичь, потому что спецификация не обязывает обращать внимание на UB ситуации, а скорее обязывает попытаться его избежать, что иногда из-за оптимизаций компилятора приводит к потенциальному неожиданному поведению во всех частях программы, в попытке компилятора избежать UB.
У Раста вроде как иная ситуация, и из блока unsafe компилятор сожрёт всё, что позволено написать в unsafe, если написал уб, компилятор не будет следовать из того, что раз ты так написал, то уб там быть не может, и ub маршруты выполнения можно выбросить, он честно упадёт в ошибку или выдаст неверный результат, а что с этим делать, уже проблема разработчика.
В целом скорее наверно вкусовщина. Но на мой взгляд, у раста компилятор поступает честнее.
По тонику может быть вкусовщина конечно. Мне просто не очень понравилось решение, где мне приходится самому реализовывать двусторонний канал связи, вкладывать его в структуру сервиса, которую я потом отправляю в рантайм, на который я никак не могу влиять после, у него нет никаких апи наружу, всё взаимодействие сводится к каналам, которые я могу вложить в сервис. Может быть это правильное архитектурное решение, но мне кажется, что это запутывает код, когда я вынужден держать в переменной рантаймы, а общаться с ними через отдельные от них компоненты, да можно обертку сделать и вложить внешний канал в обёртку вместе с рантаймом, просто мне кажется, что это излишнее награмождение абстракций
Не совсем так. 1. Даже плохой unsafe блок, хотя бы помечен в коде. 2. Даже плохой unsafe блок либо повалит программу в ошибку, либо испортит какое то значение локально, не приводя к общему UB программы. 3. unsafe по сути даёт не так уж много. Не убирая проверок с остального.
Десятка не назову, подтвержу вашу догадку про веб, и асинк рантаймы. Но вдобавок в вебе например бывают ещё и дополнительные разные инструменты, например крейт tonic, для осуществления связи по gRPC не отдаёт наружу никаких очевидных методов общения с программой. Он принуждает либо писать реализацию внутри рантайма, либо лепить костыли с пробрасыванием каналов внутрь. UI фреймворк iced, так же не откажется выступить скелетом программы (хотя с ним попроще вроде как, и если сильно захотеть, то можно всё таки реализовать и свой рантайм и ивент луп и подписки).
Потому что подход спорный, и макаронистый, в какой то момент данные могут и вовсе оказаться полностью не нужны, и придётся продумывать способ, как их удалить, и как отслеживать, что данные были удалены, и обращаться к ним не нужно.
И придётся ещё аннотировать времена жизни частенько, чтобы компилятор был уверен, что объект на который ваша ссылка, жив на протяжении всего времени, что на него ссылаются.
Коротко
Вариант из статьи: Объект валиден - пока на него есть хотя бы одна ссылка в любой части программы, и сам удалится из памяти, когда последняя ссылка будет удалена.
Вариант ваш: Ссылки валидны - пока объект существует, если объект не нужен, вам нужно точно точно убедиться, что он больше не нужен ни в одной части программы, и удалить все ссылки на него прежде чем удалить оригинал
Но ведь Zig и Rust для разного... Zig низкоуровневый язык, с низким уровнем абстракций. А Rust высокоуровневый язык, с высоким уровнем абстракций (и возможностью в низкоуровневость, но оно того не стоит в большинстве случаев).
Я полагаю, что претензия к тому, что пользователи Zig часто пытаются сравнивать его с Rust, или упоминать Rust в его контексте, хотя по сути у них нет никакой связи, кроме того, что они оба быстрые и безопасные (хотя так можно сказать ещё про сотню языков).
Уровень сравнения как сравнение дорогой немецкой стамески и бензопилы из сша
Почему же смысл скрытый? Язык вам даёт чёткую гарантию - когда переменная не в области видимости, в которой происходит выполнение, значит память точно освобождена и наоборот.
Что меня больше бесит, что многие зависимости в расте (ну соответственно претензия скорее к разработчикам наверно, хотя я им денег и не платил, чтобы делали так как мне надо, но всё же), разработаны в формате фреймворков, и не редко бывает, что когда пытаешься использовать какой то крейт в коде, то выходит так, что крейты крутятся независимыми изолированными системами в коде, из которых ты костылями пытаешься доставать данные и тасовать между ними нужным тебе образом, чтобы получить нужный результат
А чего в этом страшного то по сути? В однопоточном коде, в любом случае не получится изменить одну переменную сразу в из двух мест, а в многопоточном коде у вас есть возможность пользоваться мьютексами и рефкаунтерами, язык просто чётко обозначает вам, что вы должны осознавать, и планировать, что доступ к объекту у вас в программе осуществляется по очереди. А не одновременно из двух мест. Практика благая.
Но могу согласиться, что иногда компилятор слишком сильно опекает.
А. И самое главное то забыл. Про быстрому проектированию. На расте можно быстро проектировать, только код молниеносно превращается в хрючево. Согласен с автором. Временно (или нет) добавить десяток выделений памяти, за одну итерацию, чтобы не рефакторить систему, обычное дело.
Автор не хочет забивать гвозди отвёрткой, а пробует это сделать из любопытства, и того, что многие советуют попробовать это сделать =) Я рад что вышла такая статья, и моё мнение по поводу разработки игр на расте подтвердилось. Расту не хватает динамичности, для таких задач, с большим количеством связных и не связных систем как игры. Немало примеров, когда один элемент игры, должен иметь связь с другим настолько редко, что если возникнет проблема в реализации этого, то проще выкинуть фичу.
Кстати если говорить о языках, которые не предназначены для игростроя, то C++ тоже не предназначен, и в UE например, ты практически полностью пишешь на фреймворке, даже дефолтные фичи языка многие заменены (и вызовут ошибки компиляции или рантайма), для совместимости с горячей перезагрузкой и фичами движка. Да даже так, хоть скриптинг на плюсах, но прототипирование даётся легко и непринуждённо на блюпринтах. Причём ещё и с возможностью транслировать блюпринты в плюсы.
Моё имхо, пытаться писать на расте (да даже на чистых плюсах) скрипты для игры, мазохизм, на расте можно и я думаю это будет вполне даже удобно, писать внутренности движка, а скриптовать на quirrel, lua, haxe, да хоть на том же nim, если уж очень хочется что то скомпилировать.
Это которые pdb файлы?) Этим страдают даже многие крупные разработчики, уже много лет. Тоже не раз обращал на это внимание, бесит жутко. В итоге с релизной версией качаешь нередко двойной вес игры, при этом я не выпускал ни одной игры, но почему то знаю это...
И согласен и не согласен, местами бывает проекты уходят не туда и появляют hard-fork'и, которые в последствии вытесняют оригинальный проект, а иногда бывает что проект протух от ядра, до поверхности, и есть смысл начать новый, вместо реанимации трупа, используя его сильные стороны и наработки.
Про тех кто пишут совсем с нуля, не пользуясь чужим, согласен, боль и тлен, если не выстрелит, уходит в забытие, с сотнями человеко-часов в помойку, а когда стреляет, появляется технология, с которой приходится считаться другим, если наработка имеет экосистематический характер, вроде системы окружения.
Но к данному посту оффтоп. Парни просто решили развлечься, и написали довольно приятную на вид по отзывчивости и красоте штучку, на раз, побаловаться)
Действительно не особо приятная ситуация. P.S. А вы больше двух раз в год теряете паспорт? =) Обращение в МВД с заявлением о потере не снижает шанса на штраф?
И да, и нет. За одной вещью следить проще и спокойнее, чем за тремя разными, и пользоваться гораздо удобнее. К тому же несомненным плюсом является возможность превратить в кирпич сразу и паспорт и банковские карты и смартфон, при этом имея аналоговый паспорт и парочку банковских карт дома =)
Для большого объема кода, думаю вполне действительно больше, чем на написание. А на маленькие кусочки пойдёт, типо сделай 3 строчки запроса к бд по таким то параметрам или получи по апи оттуда - то, такую то структуру и достань оттуда имя пользователя.
Я так и не понял. Они хотят сделать проприетарную игровую консоль, конкурент PlayStation или открытую портативную платформу конкурент SteamDeck и прочим?
Если портативку по типу SteamDeck, то игры уже есть в стиме, который прекрасно заводится на линуксах, и через трансляцию с помощью Proton запускает виндовые игры. Пускай железячку собирают, тестируют Wine/Proton, пересобирают и переписывают под российские процессоры, и вперёд. Отечественные мобильные процессоры, которые реально поставить в такую железку у нас есть. Литьё пластика у нас осуществляется. Платы у нас производятся. Кнопочки, стики и прочее я думаю за годик, параллельно с написанием софта сделать смогут, все материалы и компетенции имеются у нас. Только поработать немножко нужно, вместо распила бабла.
Если желают консоль, подрубаемую к телику. То пожалуйста, современные консоли в себе содержат всё то же самое что компьютер. Возьми отечественный ноутбук, вынь из него экран, поставь в него графику и сделай красивый корпус. Поставь на него линух, с юзер френдли оболочкой, вот тебе консоль. Но графики у нас Российской, нет такой, которая бы могла запускать современные игрушки, придётся импортную ставить как-ни-крути. Если эту платформу тоже открытой делать, то окей Proton всё ещё работает, форкнуть и допилить драйверы можно, кадры способные на это у нас есть. Если же хотят поиграть в Российскость и проприетарность. То для них плохие новости, эра консолей к концу подходит, не вовремя они это. Да и консоли сейчас рассматриваются как Starter Pack молодого геймера, купил за 30 тысяч коробочку, оплатил подписочку и сидишь довольный за мало денях играешь довольный. Консоль Российская будет дорого стоить, потому что опт маленький. Да и очень сомневаюсь что Lesta будет разрабатывать эксклюзивные игры для неперспективной проприетарной консоли, да ещё и столько, чтобы тебе постоянно было во что играть.
Вместо того, чтобы хернёй заниматься. Лучше б денежку выделили на разработку графических процессоров, и интеграцию с отечественными центральными процессорами как существующих зарубежных GPU, так и в перспективе отечественных. Тем более, что GPU какие никакие у нас имеются всё таки, профинансируйте, скажите хотим, чтобы вы адаптировали и промасштабировали для игр ваши GPU, вот вам деньги, когда сделаете, мы купим, будем консоли продавать с ними, или игры под них поручим писать.
Василий Шпак, вообще человек не глупый как мне показалось, надеюсь примет верное решение об отказе о такой инициативе, и сосредоточится на более важных вещах.
У вас в любом случае после того, как процессор посчитал расположение частицы, она уходит потом на GPU, и рисуется шейдером. Вся разница в том, где именно вы считаете её положение, на CPU и отправляете только положение, или и положение тоже на GPU в собственном шейдере
Тоже не совсем согласен.
У Сей UB написанное программистом косвенно развязывает компилятору руки на то, чтобы творить дичь, потому что спецификация не обязывает обращать внимание на UB ситуации, а скорее обязывает попытаться его избежать, что иногда из-за оптимизаций компилятора приводит к потенциальному неожиданному поведению во всех частях программы, в попытке компилятора избежать UB.
У Раста вроде как иная ситуация, и из блока unsafe компилятор сожрёт всё, что позволено написать в unsafe, если написал уб, компилятор не будет следовать из того, что раз ты так написал, то уб там быть не может, и ub маршруты выполнения можно выбросить, он честно упадёт в ошибку или выдаст неверный результат, а что с этим делать, уже проблема разработчика.
В целом скорее наверно вкусовщина. Но на мой взгляд, у раста компилятор поступает честнее.
По тонику может быть вкусовщина конечно. Мне просто не очень понравилось решение, где мне приходится самому реализовывать двусторонний канал связи, вкладывать его в структуру сервиса, которую я потом отправляю в рантайм, на который я никак не могу влиять после, у него нет никаких апи наружу, всё взаимодействие сводится к каналам, которые я могу вложить в сервис.
Может быть это правильное архитектурное решение, но мне кажется, что это запутывает код, когда я вынужден держать в переменной рантаймы, а общаться с ними через отдельные от них компоненты, да можно обертку сделать и вложить внешний канал в обёртку вместе с рантаймом, просто мне кажется, что это излишнее награмождение абстракций
Не совсем так.
1. Даже плохой unsafe блок, хотя бы помечен в коде.
2. Даже плохой unsafe блок либо повалит программу в ошибку, либо испортит какое то значение локально, не приводя к общему UB программы.
3. unsafe по сути даёт не так уж много. Не убирая проверок с остального.
Десятка не назову, подтвержу вашу догадку про веб, и асинк рантаймы. Но вдобавок в вебе например бывают ещё и дополнительные разные инструменты, например крейт tonic, для осуществления связи по gRPC не отдаёт наружу никаких очевидных методов общения с программой. Он принуждает либо писать реализацию внутри рантайма, либо лепить костыли с пробрасыванием каналов внутрь. UI фреймворк iced, так же не откажется выступить скелетом программы (хотя с ним попроще вроде как, и если сильно захотеть, то можно всё таки реализовать и свой рантайм и ивент луп и подписки).
Потому что подход спорный, и макаронистый, в какой то момент данные могут и вовсе оказаться полностью не нужны, и придётся продумывать способ, как их удалить, и как отслеживать, что данные были удалены, и обращаться к ним не нужно.
И придётся ещё аннотировать времена жизни частенько, чтобы компилятор был уверен, что объект на который ваша ссылка, жив на протяжении всего времени, что на него ссылаются.
Коротко
Вариант из статьи: Объект валиден - пока на него есть хотя бы одна ссылка в любой части программы, и сам удалится из памяти, когда последняя ссылка будет удалена.
Вариант ваш: Ссылки валидны - пока объект существует, если объект не нужен, вам нужно точно точно убедиться, что он больше не нужен ни в одной части программы, и удалить все ссылки на него прежде чем удалить оригинал
К тому же котлин ещё и эффективнее использует ту же виртуальную машину что и java
Но ведь Zig и Rust для разного... Zig низкоуровневый язык, с низким уровнем абстракций.
А Rust высокоуровневый язык, с высоким уровнем абстракций (и возможностью в низкоуровневость, но оно того не стоит в большинстве случаев).
Я полагаю, что претензия к тому, что пользователи Zig часто пытаются сравнивать его с Rust, или упоминать Rust в его контексте, хотя по сути у них нет никакой связи, кроме того, что они оба быстрые и безопасные (хотя так можно сказать ещё про сотню языков).
Уровень сравнения как сравнение дорогой немецкой стамески и бензопилы из сша
Почему же смысл скрытый? Язык вам даёт чёткую гарантию - когда переменная не в области видимости, в которой происходит выполнение, значит память точно освобождена и наоборот.
Что меня больше бесит, что многие зависимости в расте (ну соответственно претензия скорее к разработчикам наверно, хотя я им денег и не платил, чтобы делали так как мне надо, но всё же), разработаны в формате фреймворков, и не редко бывает, что когда пытаешься использовать какой то крейт в коде, то выходит так, что крейты крутятся независимыми изолированными системами в коде, из которых ты костылями пытаешься доставать данные и тасовать между ними нужным тебе образом, чтобы получить нужный результат
А чего в этом страшного то по сути? В однопоточном коде, в любом случае не получится изменить одну переменную сразу в из двух мест, а в многопоточном коде у вас есть возможность пользоваться мьютексами и рефкаунтерами, язык просто чётко обозначает вам, что вы должны осознавать, и планировать, что доступ к объекту у вас в программе осуществляется по очереди. А не одновременно из двух мест. Практика благая.
Но могу согласиться, что иногда компилятор слишком сильно опекает.
А. И самое главное то забыл. Про быстрому проектированию. На расте можно быстро проектировать, только код молниеносно превращается в хрючево. Согласен с автором. Временно (или нет) добавить десяток выделений памяти, за одну итерацию, чтобы не рефакторить систему, обычное дело.
Автор не хочет забивать гвозди отвёрткой, а пробует это сделать из любопытства, и того, что многие советуют попробовать это сделать =)
Я рад что вышла такая статья, и моё мнение по поводу разработки игр на расте подтвердилось. Расту не хватает динамичности, для таких задач, с большим количеством связных и не связных систем как игры. Немало примеров, когда один элемент игры, должен иметь связь с другим настолько редко, что если возникнет проблема в реализации этого, то проще выкинуть фичу.
Кстати если говорить о языках, которые не предназначены для игростроя, то C++ тоже не предназначен, и в UE например, ты практически полностью пишешь на фреймворке, даже дефолтные фичи языка многие заменены (и вызовут ошибки компиляции или рантайма), для совместимости с горячей перезагрузкой и фичами движка. Да даже так, хоть скриптинг на плюсах, но прототипирование даётся легко и непринуждённо на блюпринтах. Причём ещё и с возможностью транслировать блюпринты в плюсы.
Моё имхо, пытаться писать на расте (да даже на чистых плюсах) скрипты для игры, мазохизм, на расте можно и я думаю это будет вполне даже удобно, писать внутренности движка, а скриптовать на quirrel, lua, haxe, да хоть на том же nim, если уж очень хочется что то скомпилировать.
Это которые pdb файлы?)
Этим страдают даже многие крупные разработчики, уже много лет. Тоже не раз обращал на это внимание, бесит жутко.
В итоге с релизной версией качаешь нередко двойной вес игры, при этом я не выпускал ни одной игры, но почему то знаю это...
И согласен и не согласен, местами бывает проекты уходят не туда и появляют hard-fork'и, которые в последствии вытесняют оригинальный проект, а иногда бывает что проект протух от ядра, до поверхности, и есть смысл начать новый, вместо реанимации трупа, используя его сильные стороны и наработки.
Про тех кто пишут совсем с нуля, не пользуясь чужим, согласен, боль и тлен, если не выстрелит, уходит в забытие, с сотнями человеко-часов в помойку, а когда стреляет, появляется технология, с которой приходится считаться другим, если наработка имеет экосистематический характер, вроде системы окружения.
Но к данному посту оффтоп. Парни просто решили развлечься, и написали довольно приятную на вид по отзывчивости и красоте штучку, на раз, побаловаться)
Действительно не особо приятная ситуация.
P.S. А вы больше двух раз в год теряете паспорт? =)
Обращение в МВД с заявлением о потере не снижает шанса на штраф?
И да, и нет. За одной вещью следить проще и спокойнее, чем за тремя разными, и пользоваться гораздо удобнее. К тому же несомненным плюсом является возможность превратить в кирпич сразу и паспорт и банковские карты и смартфон, при этом имея аналоговый паспорт и парочку банковских карт дома =)
То есть если я достаю банковские карты из смартфона, то паспорт мне там хранить не следует?
Для большого объема кода, думаю вполне действительно больше, чем на написание. А на маленькие кусочки пойдёт, типо сделай 3 строчки запроса к бд по таким то параметрам или получи по апи оттуда - то, такую то структуру и достань оттуда имя пользователя.