Да по факту для геймдева лишь 3 ЯП: С, кресты и раст. Ну может ещё свифт.

Но тут вопрос про архитектуру. Ведь всё то, что написано на наследовании, приходится переделывать. Think Different в общем.

Итого C/C++?

хорошо распаралелленый раст думаю вполне возможен

Ha сколько я знаю у Раста с графонием не очень дела (по крайней мере пока). Ну и в работе с одним потоком на ядро он уступает C/C++ (из-за грязных хаков что позволяет С)

Ну и ещё для оптимизации производительности прогеры на Сях, Плюсах делают ассемблерные вставки, такая практика применяется в разработке на Расте?

вряд ли. Я из-за того и перешел на раст, что сегфолты достали. Неуловимые гейзенбаги.

Куда интереснее, как строить архитектуру с композицией вместо наследования. Есть свои плюсы, например, можно какой-то String сделать и Serializable и MyEngineSerializable. А с другой, сделать иерархию объектов трудно, но с третьей: а нужно ли это, или композиция лучше:
1) MyExtendedTank наследует от Tank — тут наследование круть, а в расте тебе фига
2) Наследовать своего актора от актора в вакууме, что бы получить позицию актора, нескольк методов — средне.
3) Долгая цепочка наследований, причём каждое наследование добавляет лишь пару методов — это уже плохо.

Кстати в анриале есть свои классы-интерфейсы и там выключено множ. наследование. В общем, как в жабе. Я даже начинаю сомневаться,  а так ли крут анриал, раз он на крестах: всё равно там сборщик мусора, но на уровне акторов, а не строк и массивов. А jit ныне быстро превратит код игры в код на крестах + с оптимизацией под конкретный комп.

слухи, слухи

возможно, да, только думаю совершенно лишнее, крейт simd и правильный дизайн структур данных поможет

Я вообще привык к RAII насколько, что мне проще с ним, чем с GC. + RAII заставляет правильно раскрадывать мир по полочкам(концепция владения, борровинг). + объекты уничтожаются когда надо.

Но RAII быстрее GC, но в случае горячей замены кода и частичных отказов.. можно получить вечные объекты, потому что из-за отваливания объектов тупо не декрементятся счётчики.

Можешь глянуть ещё в сторону яп D

Я тут даже скидывал ссылку на новенький 2д движок на D

А есть ли смысл надрачиваться на 2% производительности? Куда выгоднее получить меньше гейзенбагов, быстрее выпустить качественный продукт. А время вместо ассемблерных вставок лучше посвятить  борьбе с багами и фичам. + в расте тоже можно писать на асме вроде. Только нужно ли это? Ныне компиляторы куда умнее большинства программеров, что раст иногда обгоняет С++.

Meня самого сейчас больше волнует вопрос, на чём можно фрилансить когда у тебя нет портфолио и ты не работал больше года, а ещё ты нигде официально не работал

ну gfx есть. Интересная штука. Только не знаю, позволяет ли она работать многопоточно — фича вулкана и кажись директа 12-го. До этого было плохо — лишь один поток рендер.

а зачем этот D? Кресты с GC. И не раст. Довольно обыденный с точки зрения науки. Или в нём есть какая-то фича уровня борровинга?

Что касается jit-а (если мы говорим про жаву или дотнет) то его возможности по отпимизациям довольно ограничены (в плане, он конечно оптимизирует, но не стоит ждать чуда), не говоря уже о том, что сам jit жрет ресурсы на свою работу)

Имеет смысл если пишешь код под конкретное железо (маломощное). Ну и что бы компилятор выдавал производительный код его (компилятор) следует очень хорошо знать, что бы сконфигурировать для генерации производительного машинного кода (а ещё сам исходный код на Расте надо специальным образом кодить)

Я плюнул на раст и устроился писать на анриале на крестах + VR. Очень полезно. В Wargaming не пошел, хотя тестовое сделал. Gaijin-у надо тестовое за 4 часа... откладывал до самого отказа.

есть случаи, когда jit обгонял кресты и С. Но эти случаи не относятся к геймдеву. Но если у тебя много циклов, они юзают 5 переменных, а у тебя лишь две из них действительно юзают, то в теории jit может сильно упростить цикл и ты получишь куда большее быстродействие, чем если кресты или раст последовательно всё выполняли.

Имхо, скорее главное зло это GC.

Все ЯП с GC существуют для прикладного программирования где на скорость и потребление памяти всем насрать (потому что железо зачастую стоит дешевле чем труд программиста на C/C++/Rust/Verilog/Asm)