Комментарии 3
А вот по поводу SDK этого вашего... Мы тут на haxe дискорде недавно обсуждали вопрос: вот язык вроде идеально подходит для разработки SDK, но никто ни разу не слышал, чтобы его для этого реально использовали. Вы такой вариант не рассматривали?
Почему я считаю, что такое решение подходит для разработки SDK? Потому что это именно тот тип ПО, которое требуется реализовать на куче языков / под кучу платформ.
Используя haxe можно транспилировать в lua, php, js, c#, python, java, с некоторым приложением напильника можно и под плюсы. Это же сразу сколько движков можно окучить! (unity, godot, defold, love2d, libgdx и т.д. я уже не говорю про flixel/openfl/heaps). Нет, понятно, что под каждый таргет нужно будет что-то специально дописывать, но не бизнес-логику. А написав клей под движки можно будет выкатывать новые версии под все таргеты с одной кодовой базы вообще одной кнопкой...
А мы рассматривали haxe. Но там были нюансы:
Много зависимостей тащил.
Какая-то каша в сгенерированном коде.
Дублировались моменты.
С рефлексией проблемки.
Может на что-то по незнанию натолкнулись, может и правда есть проблемы. Но в итоге решили на плюсах, т. к., как минимум, с ним опыта больше у команды.
Используя haxe можно транспилировать в lua, php, js, c#, python, java, с некоторым приложением напильника можно и под плюсы
А плюсы в целом ни во что не надо (кроме веба), только обвязки на языке движка писать нужно.
О. На самом деле, это очень интересные моменты, которые хотелось бы обсудить, если будет возможность. Потому, что звучит все крайне странно для меня:
1. У самого haxe нет зависимостей, кроме, разве что neko для работы haxelib, без которого в принципе сейчас уже можно обойтись. О каких зависимостях речь? Библиотеки, которые дополняют функционал, недостоющий стандартной либе? Или инструменты сборки под таргеты? Даже юнити будет хотеть android sdk для билда.
2. Сгенерированный код, хоть изначально и не предназначен для человека, читается вполне неплохо. Там есть некоторые нюансы: введение локальных переменных для развертывания итераторов и подобных задач; специфика таргета, кое-где лишние касты. Мне доводилось вести проект, на котором бизнес-логика работала в юнити и на ноде, иногда приходилось залезать в сгенерированные исходники на шарпе и js. После понимания некоторой специфики с ними вполне можно иметь дело человеку. Плюс,надо иметь ввиду, что компилятором можно управлять через мету и флаги компиляции. Например, уровень dead code elimination, управление тем, что инлайнить, включить/отключить оптимизатор. Да, оптимизатор и dce – это тоже весьма полезные особенности компилятора.
3. Дублировались в каком смысле? Мне приходит в голову только то, что сгенерированный код включает классы стандартной библиотеки, которые по смыслу могут дублировать платформенные (коллекции, например). Но поскольку требуется соблюдать поведение на всех таргетах, а нативные реализации всегда отличаются – это основной способ приведения "к общему знаменателю".
Для чувствительных мест тоже есть инструменты: абстракты и экстерны позволяют довольно много платформенного завернуть в zero-overhead сахар, который можно запилить под нужные таргеты – главно конкретные задачи сформулировать.
4. А с рефлексией какие проблемы? Она же великолепно работает. Нет, подводные камни там тоже встречаются. Например, на js для объектов в список ключей могут попасть поля платформенных объектов. Мы один раз накололись и пару дней искали баг, когда в игру добавили персонажа constructor. Кроме того, в ряде случаев, вместо рефлексии можно использовать макросы, которые тоже огого какие. Еще есть https://haxe.org/manual/cr-rtti.html
А плюсы в целом ни во что не надо
только львиная доля SDK – это пользовательский апи. Куча функций с сигнатурами, как все то, что лежит в основном npm пакете, который core, не wasm. И все это было бы неплохо, чтобы у пользователя комплитилось и подсвечивалось. Используете что-то, чтобы генерить это из схемы на каждый язык?
С другой стороны, всякие jni и wasm хорошо-удобно работают, когда приложение как вещь в себе. Насколько эффективно получается, когда основное приложение регулярно по-мелочи дергает wasm по событиям? Не будет ли это создавать дополнительный оверхэд по перфомансу? Особенно весело, когда приложение wasm, sdk wasm, но все данные и вызовы они гоняют через js.
Может на что-то по незнанию натолкнулись
У haxe кстати довольно активное и дружелюбное коммьюнити. Вполне вероятно, что смогли бы помочь на ранних этапах с значительной частью шероховатостей. Я и сам с удовольствием пообщаюсь на эту тему, если у вас возникнут потребность/желание.
Недельный геймдев: #211 — 2 февраля, 2025