Ну почему же? Речь, очевидно, идет о core-геймплее. Всякие кликеры вполне могут обладать глубиной, если грамотно сделана вариативность прогрессии, билдостроения. А если "одну кнопку" расширить до "одного пальца", то тут же можно вспомнить бум сурвайворов.
Что же это за флаппи берд вы такой придумали, чтобы вот это вот все? Какой спавн объектов, производительность и коллизии? В оригинальной игре можно было обойтись десятком спрайтов и проверками уровня if (x>min && x<max). Если написать все тупо в лоб, то тормозить там в принципе нечему. https://codepen.io/ju-az/pen/eYJQwLx/ – первыя ссылка из гугла, 100 строк кондового js вместе с комментариями. И наоборот, скорости надо скрутить – большинство старых js игр работают слишком быстро в современных браузерах.
Для своего игрового движка решаю похожую задачу, рендеринг текста *sdf шейдером при помощи квадов с текстурами из атласа. Основная задача давно решена, сейчас занимаюсь автоматизацией добавления собственных пиктограмм в атлас. Общая идея: собственный файл шрифта в inkscape/svg → конвертация в ttf FontForge → генерация в общий атлас со шрифтами, используемыми в игре.
pecheny/fontgen – генератор текстурных атласов и описание шрифта в формате BMFont pecheny/htext – рантайм для рендеринга (ну не самого рендеринга, а генерации меша с UV). Вдруг, найдете для себя что-то полезным.
Если рандомные места будут свободно сбрасывать очередь событий клавиатуры, то рано или поздно учеловека, который быстро печатает или имеет медленный компьютер будут появлятся файлы eadme.tx или что похуже.
Чистить очередь событий клавиатуры перед показом диалога
Очередь событий клавиатуры обычно бывает в месте сильно отличном от места вызова диалога. И предполагаю, что давать доступ к очереди клавиатурных событий любому месту, которое показыавет диалоги, чревато сильно интересными последтсвиями. Но если вы думаете, что это тривиально, то можете попробовать форкнуть и показать всем, как надо.
Отмену операции и закрытие диалога повесить на разные клавиши
Позвольте уточнить: вы предлагаете, чтобы по эскейпу не вызывался диалог отмены? Или чтобы он не закрывался? Если честно, сомневаюсь, что многие пользователи обрадуются такому нововведению. Но если лично вам такая идея нравится, почему нет?
примерно сюда %USERPROFILE%\AppData\Roaming\Far Manager\Profile\Macros\internal\Dialog_Esc.lua (ну или где там у вас профиль фара) и назначьте любую другую кнопку по своему вкусу.
У меня есть гипотеза, что если диалог не появился сразу, то значит где-то в неожиданном месте встала колом блокирующая операция, и приложение не слишком решает как себя вести. Соответственно, если решать эту проблему – то блокируюшие операции нужно огораживать. Если огородить блокирующую операцию, то ВНЕЗАПНО окажется, что ничего не мешает диалогу рисоваться сразу. То есть ваше решение не "самое простое", а "самое бессмысленное". Собственно, я не помню, когда в последний раз видел ситуацию задержки диалога отмены. Возможно, потому, что давненько не ходил фаром на сетевые ресурсы – на локальных поиске/копировании диалог появляется моментально.
Пользователь far на связи. Да, именно этого и хотел. С вашего позволения, прямая аналогия: – работаем в ворде – нажимаем alt+f4 – получаем модалку: "файл изменен, сохранить? да | нет | не знаю – нажимаем esc – ворд закрывается. А что, мы же именно этого хотели нажимая alt+f4? Операции в far могут и, как правило, есть намного более длительны, чем реакция с модалкой на esc. Соответственно, потерять результаты выполнения операции от случайного прожмяка эскейпа – намного хуже, чем не отменить операцию.
Безотносительно F#, я бы отнес к мощной системе типов Algebraic data types, статическую типизацию с выведением типов для анонимных структур, возможность контролировать размерность для арифметики, как например с abstract type operator overloading в haxe и далее к зависимым типам.
Из статьи может и не очевидно, но по конфигурируемости emacs действительно намного превосходит VSCode. Посмотрите мой комментарий ниже. У них разные сильные и слабые стороны, но вот эта динамическая гибкость лиспа позволяет строить потрясающие системы типа org-agenda, org-babel, org-roam и пр. Я полагаю, именно лисповая гибкость позволяет быть им такими волшебными. Пользователи строят из них совершенно разные конфигурации и флоу, а разработчикам не нужно думать об апи для пользовательских расширений: весь код – одно сплошное апи.
Пользуюсь и vscode, и emacs, попробую объяснить, в чем разница подходов на недавнем примере. У VSCode стандартное поведение нажатия на ошибку в панели PROBLEMS – открыть редактор в нужном месте, выделив весь проблемный регион. Редко когда нужно заменять регион целиком, поэтому меня все время отвлекала необходимость нажимать ESC после перехода к ошибке, чтобы сбросить выделение. В какой-то тысячный раз, отвлекшись на эту ерунду, я решил: ХВАТИТ ЭТО ТЕРПЕТЬ!11 Ну и поправил. Для этого потребовалось: скачать исходники VSCode, VSCodium, подобрать необходимые версии node и зависимости msvc built tools, подготовить патч, разместить его в своем форке vscodium и собрать релизную версию редактора. (Способ подразумевает, что при желании обновить версию vscode, не приходилось патчить исходники вручную. В emacs, если мне что-то не нравится, я прямо через хэлп команды перепрыгиваю к исходникам, редактирую, заменяю в памяти реализацию функции и проверяю. Файл с исходниками не сохраняю. Если новый результат мне нравится, я просто копирую реализацию отредактированной функции к себе в конфиг. Речь идет не только о командах, у себя в конфиге можно переопределить вообще любую функцию из исходников.
Наверное не самый показательный пример, зато самый свежий.
В общем, моя гипотеза в том, C# код написанный максимально стандартным образом будет поддерживаться. Например, список совместимости https://www.nuget.org/packages/Newtonsoft.Json достаточно приличный и, как я понял, это всле для одной ревизии исходников. Так что вряд ли стоит ожидать, что с# таргет текущей версии компилятора перестанет поддерживаться c# экосистемой в обозримом будущем.
Ага, значит подобные вставки все же поддерживаются.
Технология делается 20 лет исключительно с целью применения. Ее вообще не пытаются кому-то втюхать. Разумеется, большинство практических задач решено.
Да, рад, что пришли к консенсусу и тоже надеюсь, что кому-нибудь пригодится.
Никогда не использовал Haxe, но полагаю сравнивать стоит со всем известным Unity, так что пусть будет Unity.
Haxe – язык программирования. Unity – игровой движок. C# – язык программирования. На нем пишут под юнити. Понятно, к чему я веду? Если не понятно: язык/тулинг корректно сравнивать с языком, движок – с движком. Примеры движков я вам уже привел. Можете еще Heaps - Haxe Game Engine - Heaps.io Game Engine посмотреть.
Ну я же написал «в пределах 5–7 лет ломают сам язык», те код написанный пять лет назад легко может не собраться в новой среде.
Ну у вас не работает, а у других работает. Если я не ошибаюсь, то многие изменения C# как языка – именно на уровне языка. Новый сахар часто компилировался в старый il код. Существует ли сейчас проблема, что dll с il кодом, собранная каким-нибудь C# 5 не может быть использована в современном проекте?
А как вы предполагаете забарывать такое без ручных правок на Haxe?
В haxe это предусмотрели более гибко и удобно, чем в юнити. Интероп с окружением таргета – это тоже сильная сторона haxe. https://haxe.org/manual/lf-externs.html Нюансы, разумеется, зависят от таргета. В общих чертах – не уникальо, описываем в терминах haxe, как вызывать платформенный код, собираем и/или исполняем так, чтобы вызовы были доступны. А концепция Abstract про которую я писал в контексте zero-overhead в комбинации с экстернами вообще позволяет творить чудеса. Можно написать обертку вокруг нативного класса так, что из прикладного haxe кода она будет выглядеть, как haxe класс, в сгенерированном коде будет вызов конструктора нативного класса. При этом в абстракт можно еще дописать методы, которые по желанию заинлайнятся вокруг обращения к нативному или превратятся в статические.
через вставку нативного кода
Но не редактирование же вывода транспилятора! Такой способ тоже доступен на уровне языка. Что-то вроде
Ну и мультитач давно доступен на уровне движков, по крайней мере, тех, что я называл.
В общем, я вижу, что в вас говорило совершенно необоснованное предубеждение перед мощной технологией просто потому что "так классно рассказывают, не может же на самом деле так быть".
есть отличие между законченным решением и вот такой универсальным транспилером
Из чего я предположил, что у вас есть критерии "законченного решения", которым не удовлетворяет haxe и экосистема вокруг него. Вероятно я ошибся и вы хотели сказать что-то другое.
Не работает такое, проходили уже.
Тоже весьма сильное заявление. Своей обобщенностью. Что не работает? Подход применияется, c# таргет используется, так что опровержение для вашей формулировки в общем виде у меня уже есть.
Еще я не очень понимаю весь жизненный цикл: ну сгенерировали вы этот код из Haxe, а дальше что?
Это хорошо, что вместо утверждений вы начали задавать вопросы. Дальше зависит от ваших задач и целей. Haxe – это инструмент, причем достаточно многогранный, решать им можно совершенно разные задачи. Если ваша задача – делать инди игру, например, то вы берете движок OpenFL или HaxeFlixel, настраивайте его по инструкции, после чего запускаете вашу игру на haxe одной командой на любой платформе.
openfl test android
и игра запустится на подключенном телефоне,
openfl test html5
– откроется в браузере и т.д.
Другой вариант. Вы делаете сложную стратегию. И клиент с красивой графикой, допустим, на юнити. А сервер, допустим, на ноде. Красивую графику вы, понятно, на c# пишете. А логику: сколько ресурсов списать, каких солдатов улучшить – на haxe. И на билд-сервере есть задачи, которые после пуша запускают тесты, конвертят ресурсы и много чего еще, но среди прочего запускают haxe два раза с разными флагами и получают два артефакта .net dll и js файл. Один попадает в проект на юнити, другой – в сервер на ноде. И клиент в результате может относительно долго играть в оффлайне, записывая действия пользователя. Когда подключится – отправит серверу эти действия. А сервер тоже выполнит их и будет уверен, что пользователь не жулил с результатами.
Ну или вот есть у меня там игра на openfl. А в игре я мешки использую и формат у меня свой, мне удобный. Я пишу на haxe маленькую утилиту-апи. Для использования как-то так:
var m = new Mesh();
m.addVert(0,0,0);
export(m, "asset.json");
Транспилирую в питон и кидаю в каталог аддона к блендеру. Уже на питоне пишу импорт утилиты как библиотеки и использую готовый экспорт в нужный мне формат.
Но рано или поздно от кодогенерации избавлялись, как раз из-за необходимости ручных правок и долгосрочной поддержки.
Ручные правки не используются. Человекочитаемые исходники помогают, если реально напоролся на случай, когда код работает по-разному и нужно разобраться. После этого либо переписываешь исходники haxe по-другому, либо репортишь баг. Либо и то и то. Ситуация в целом экстраординарная.
А просто исходники на разных языках нужны, чтобы использовать в соответствующих окружениях. Я перечислил далеко не все движки, под которые можно писать код на haxe.
Напомню, 20 лет уже проекту. Посмотрите только по стиму суммарно движки Lime/OpenFl, Heaps. https://steamdb.info/tech/ В веб-проектах распространение еще шире. Ничего общего с in-house наколенной кодогенерацией технология не имеет.
Ок, «код на другом языке не работает» — кто виноват? Куда бежать, кому заносить?
Очевидно, https://github.com/HaxeFoundation/haxe/issues/ Там открываются, обсуждаются, фиксятся и закрываются тикеты и по конкретным таргетам (языкам). Для этого даже в начале тикета в квадратных скобках указывается таргет, если проблема специфична для него.
есть отличие между законченным решением и вот такой универсальным транспилером
Сформулируйте, пожалуйста.
Ээм это... очень смелое заявление, с учетом объемной спецификации C#
Вы путаете направление взаимоотношений. Это не # код запускается в haxe, для чего потребовалось бы учитывать все особенности полной спецификации. Для того, чтобы сгениророванный код надежно работал в c# окружении, достаточно пользоваться необходимым минимумом из нее.
У них заявлена поддержа в виде target platform: Android, iOS, Windows, Linux и веб — слегка многовато для двоих разрабов, не находите?
Вы, наверно, не совсем понимаете, как это работает. Это как раз по поводу разных подходов к "управлению сложностью". По поводу двух разработчиков мне очень нравится вот эта история Beating the Averages. Во-первых, haxe – это в первую очередь транспилятор. Результатом его работы является код на другом языке. Для поддержки множества платформ достаточно поддержать в качестве результата компиляции один язык, который компилируется на все эти платформы. Так, например, многие современные языки не реализуют самостоятельно поддержку платформ, а используют LLVM. Это очень сильно упрощает разработку компиляторов. Так вот, поддержать кучу платформ – сейчас не сложно, такую возможность и предоставляют современные языки через LLVM. Во-вторых, уникальность haxe в том, что он позволяет получать (относительно человекочитаемые) исходники на хорошем спектре языков высокого уровня. Это позволяет реиспользовать код на haxe в куче окружений. Например, игровой сервер может быть написан на java, php, node, ... и подключить игровую логику просто как модуь. Или, например, запихать описание модели/сериализацию в нужный формат в блендер, через транспиляцию скрипта в питон (я так делал) Можно писать на haxe игровую логику под разные движки. Для Defold – через транспиляцию в lua, для Godot – через GDScript и т.д. И в-третьих, он интересен и хорош именно как язык, по выразительнсти и функциональности. Мощная система макросов, развитая система типов + современные фишки типа паттерн-матчинга и, уникальный по-моему подход к введению zero-overhead абстракций через понятие абстракта.
Полагаю речь про Mono и Unity ?
Совсем не обязательно. Haxe выдает исходники на c#, а вы уже можете использовать хоть на сервере/десктопе в .net, хоть в юнити (и через mono, и через il2cpp) – везде, где можно писать код на c#/
Ну почему же? Речь, очевидно, идет о core-геймплее. Всякие кликеры вполне могут обладать глубиной, если грамотно сделана вариативность прогрессии, билдостроения. А если "одну кнопку" расширить до "одного пальца", то тут же можно вспомнить бум сурвайворов.
Что же это за флаппи берд вы такой придумали, чтобы вот это вот все?
Какой спавн объектов, производительность и коллизии? В оригинальной игре можно было обойтись десятком спрайтов и проверками уровня
if (x>min && x<max). Если написать все тупо в лоб, то тормозить там в принципе нечему.https://codepen.io/ju-az/pen/eYJQwLx/ – первыя ссылка из гугла, 100 строк кондового js вместе с комментариями. И наоборот, скорости надо скрутить – большинство старых js игр работают слишком быстро в современных браузерах.
Для своего игрового движка решаю похожую задачу, рендеринг текста *sdf шейдером при помощи квадов с текстурами из атласа.
Основная задача давно решена, сейчас занимаюсь автоматизацией добавления собственных пиктограмм в атлас. Общая идея: собственный файл шрифта в inkscape/svg → конвертация в ttf FontForge → генерация в общий атлас со шрифтами, используемыми в игре.
pecheny/fontgen – генератор текстурных атласов и описание шрифта в формате BMFont
pecheny/htext – рантайм для рендеринга (ну не самого рендеринга, а генерации меша с UV).
Вдруг, найдете для себя что-то полезным.
Если рандомные места будут свободно сбрасывать очередь событий клавиатуры, то рано или поздно учеловека, который быстро печатает или имеет медленный компьютер будут появлятся файлы eadme.tx или что похуже.
Очередь событий клавиатуры обычно бывает в месте сильно отличном от места вызова диалога. И предполагаю, что давать доступ к очереди клавиатурных событий любому месту, которое показыавет диалоги, чревато сильно интересными последтсвиями. Но если вы думаете, что это тривиально, то можете попробовать форкнуть и показать всем, как надо.
Позвольте уточнить: вы предлагаете, чтобы по эскейпу не вызывался диалог отмены? Или чтобы он не закрывался? Если честно, сомневаюсь, что многие пользователи обрадуются такому нововведению. Но если лично вам такая идея нравится, почему нет?
Суньте примерно такое содержимое:
примерно сюда
%USERPROFILE%\AppData\Roaming\Far Manager\Profile\Macros\internal\Dialog_Esc.lua(ну или где там у вас профиль фара) и назначьте любую другую кнопку по своему вкусу.У меня есть гипотеза, что если диалог не появился сразу, то значит где-то в неожиданном месте встала колом блокирующая операция, и приложение не слишком решает как себя вести.
Соответственно, если решать эту проблему – то блокируюшие операции нужно огораживать. Если огородить блокирующую операцию, то ВНЕЗАПНО окажется, что ничего не мешает диалогу рисоваться сразу. То есть ваше решение не "самое простое", а "самое бессмысленное".
Собственно, я не помню, когда в последний раз видел ситуацию задержки диалога отмены. Возможно, потому, что давненько не ходил фаром на сетевые ресурсы – на локальных поиске/копировании диалог появляется моментально.
Пользователь far на связи. Да, именно этого и хотел.
С вашего позволения, прямая аналогия:
– работаем в ворде
– нажимаем alt+f4
– получаем модалку: "файл изменен, сохранить? да | нет | не знаю
– нажимаем esc
– ворд закрывается.
А что, мы же именно этого хотели нажимая alt+f4?
Операции в far могут и, как правило, есть намного более длительны, чем реакция с модалкой на esc.
Соответственно, потерять результаты выполнения операции от случайного прожмяка эскейпа – намного хуже, чем не отменить операцию.
Гляньте hxdefold/hxdefold: Haxe/Lua externs for Defold game engine
Если поменять user-agent, то не только открывается, но даже звонит и разговаривает.
Безотносительно F#, я бы отнес к мощной системе типов Algebraic data types, статическую типизацию с выведением типов для анонимных структур, возможность контролировать размерность для арифметики, как например с abstract type operator overloading в haxe и далее к зависимым типам.
Синтаксис GDScript, насколько я понимаю, практически идентичен питоновскому. Разница в доступном апи и нюансах обращения.
Смотри, не перепутай!
Извините, не удержался.
Из статьи может и не очевидно, но по конфигурируемости emacs действительно намного превосходит VSCode. Посмотрите мой комментарий ниже.
У них разные сильные и слабые стороны, но вот эта динамическая гибкость лиспа позволяет строить потрясающие системы типа org-agenda, org-babel, org-roam и пр.
Я полагаю, именно лисповая гибкость позволяет быть им такими волшебными. Пользователи строят из них совершенно разные конфигурации и флоу, а разработчикам не нужно думать об апи для пользовательских расширений: весь код – одно сплошное апи.
Пользуюсь и vscode, и emacs, попробую объяснить, в чем разница подходов на недавнем примере.
У VSCode стандартное поведение нажатия на ошибку в панели PROBLEMS – открыть редактор в нужном месте, выделив весь проблемный регион. Редко когда нужно заменять регион целиком, поэтому меня все время отвлекала необходимость нажимать ESC после перехода к ошибке, чтобы сбросить выделение.
В какой-то тысячный раз, отвлекшись на эту ерунду, я решил: ХВАТИТ ЭТО ТЕРПЕТЬ!11
Ну и поправил. Для этого потребовалось: скачать исходники VSCode, VSCodium, подобрать необходимые версии node и зависимости msvc built tools, подготовить патч, разместить его в своем форке vscodium и собрать релизную версию редактора. (Способ подразумевает, что при желании обновить версию vscode, не приходилось патчить исходники вручную.
В emacs, если мне что-то не нравится, я прямо через хэлп команды перепрыгиваю к исходникам, редактирую, заменяю в памяти реализацию функции и проверяю. Файл с исходниками не сохраняю. Если новый результат мне нравится, я просто копирую реализацию отредактированной функции к себе в конфиг. Речь идет не только о командах, у себя в конфиге можно переопределить вообще любую функцию из исходников.
В общем, моя гипотеза в том, C# код написанный максимально стандартным образом будет поддерживаться.
Например, список совместимости
https://www.nuget.org/packages/Newtonsoft.Json
достаточно приличный и, как я понял, это всле для одной ревизии исходников. Так что вряд ли стоит ожидать, что с# таргет текущей версии компилятора перестанет поддерживаться c# экосистемой в обозримом будущем.
Технология делается 20 лет исключительно с целью применения. Ее вообще не пытаются кому-то втюхать. Разумеется, большинство практических задач решено.
Да, рад, что пришли к консенсусу и тоже надеюсь, что кому-нибудь пригодится.
Чтобы рисовать кружоки нужно, внезапно, тренироваться рисовать кружочки.
Может, вот это подойдет
https://www.youtube.com/watch?v=7VasRZzPCXw
Haxe – язык программирования. Unity – игровой движок. C# – язык программирования. На нем пишут под юнити. Понятно, к чему я веду?
Если не понятно: язык/тулинг корректно сравнивать с языком, движок – с движком. Примеры движков я вам уже привел. Можете еще Heaps - Haxe Game Engine - Heaps.io Game Engine посмотреть.
Ну у вас не работает, а у других работает. Если я не ошибаюсь, то многие изменения C# как языка – именно на уровне языка. Новый сахар часто компилировался в старый il код. Существует ли сейчас проблема, что dll с il кодом, собранная каким-нибудь C# 5 не может быть использована в современном проекте?
В haxe это предусмотрели более гибко и удобно, чем в юнити. Интероп с окружением таргета – это тоже сильная сторона haxe.
https://haxe.org/manual/lf-externs.html
Нюансы, разумеется, зависят от таргета. В общих чертах – не уникальо, описываем в терминах haxe, как вызывать платформенный код, собираем и/или исполняем так, чтобы вызовы были доступны.
А концепция Abstract про которую я писал в контексте zero-overhead в комбинации с экстернами вообще позволяет творить чудеса.
Можно написать обертку вокруг нативного класса так, что из прикладного haxe кода она будет выглядеть, как haxe класс, в сгенерированном коде будет вызов конструктора нативного класса. При этом в абстракт можно еще дописать методы, которые по желанию заинлайнятся вокруг обращения к нативному или превратятся в статические.
Но не редактирование же вывода транспилятора! Такой способ тоже доступен на уровне языка.
Что-то вроде
Ну и мультитач давно доступен на уровне движков, по крайней мере, тех, что я называл.
В общем, я вижу, что в вас говорило совершенно необоснованное предубеждение перед мощной технологией просто потому что "так классно рассказывают, не может же на самом деле так быть".
Вы начали с уверенного утверждения:
Из чего я предположил, что у вас есть критерии "законченного решения", которым не удовлетворяет haxe и экосистема вокруг него. Вероятно я ошибся и вы хотели сказать что-то другое.
Тоже весьма сильное заявление. Своей обобщенностью. Что не работает? Подход применияется, c# таргет используется, так что опровержение для вашей формулировки в общем виде у меня уже есть.
Это хорошо, что вместо утверждений вы начали задавать вопросы. Дальше зависит от ваших задач и целей. Haxe – это инструмент, причем достаточно многогранный, решать им можно совершенно разные задачи.
Если ваша задача – делать инди игру, например, то вы берете движок OpenFL или HaxeFlixel, настраивайте его по инструкции, после чего запускаете вашу игру на haxe одной командой на любой платформе.
и игра запустится на подключенном телефоне,
– откроется в браузере и т.д.
Другой вариант. Вы делаете сложную стратегию. И клиент с красивой графикой, допустим, на юнити. А сервер, допустим, на ноде. Красивую графику вы, понятно, на c# пишете. А логику: сколько ресурсов списать, каких солдатов улучшить – на haxe. И на билд-сервере есть задачи, которые после пуша запускают тесты, конвертят ресурсы и много чего еще, но среди прочего запускают haxe два раза с разными флагами и получают два артефакта .net dll и js файл.
Один попадает в проект на юнити, другой – в сервер на ноде. И клиент в результате может относительно долго играть в оффлайне, записывая действия пользователя. Когда подключится – отправит серверу эти действия. А сервер тоже выполнит их и будет уверен, что пользователь не жулил с результатами.
Ну или вот есть у меня там игра на openfl. А в игре я мешки использую и формат у меня свой, мне удобный. Я пишу на haxe маленькую утилиту-апи.
Для использования как-то так:
Транспилирую в питон и кидаю в каталог аддона к блендеру.
Уже на питоне пишу импорт утилиты как библиотеки и использую готовый экспорт в нужный мне формат.
Ручные правки не используются. Человекочитаемые исходники помогают, если реально напоролся на случай, когда код работает по-разному и нужно разобраться. После этого либо переписываешь исходники haxe по-другому, либо репортишь баг. Либо и то и то. Ситуация в целом экстраординарная.
А просто исходники на разных языках нужны, чтобы использовать в соответствующих окружениях. Я перечислил далеко не все движки, под которые можно писать код на haxe.
Напомню, 20 лет уже проекту. Посмотрите только по стиму суммарно движки
Lime/OpenFl, Heaps.
https://steamdb.info/tech/
В веб-проектах распространение еще шире. Ничего общего с in-house наколенной кодогенерацией технология не имеет.
Очевидно, https://github.com/HaxeFoundation/haxe/issues/
Там открываются, обсуждаются, фиксятся и закрываются тикеты и по конкретным таргетам (языкам). Для этого даже в начале тикета в квадратных скобках указывается таргет, если проблема специфична для него.
Сформулируйте, пожалуйста.
Вы путаете направление взаимоотношений. Это не # код запускается в haxe, для чего потребовалось бы учитывать все особенности полной спецификации.
Для того, чтобы сгениророванный код надежно работал в c# окружении, достаточно пользоваться необходимым минимумом из нее.
Вы, наверно, не совсем понимаете, как это работает. Это как раз по поводу разных подходов к "управлению сложностью". По поводу двух разработчиков мне очень нравится вот эта история Beating the Averages.
Во-первых, haxe – это в первую очередь транспилятор. Результатом его работы является код на другом языке. Для поддержки множества платформ достаточно поддержать в качестве результата компиляции один язык, который компилируется на все эти платформы.
Так, например, многие современные языки не реализуют самостоятельно поддержку платформ, а используют LLVM. Это очень сильно упрощает разработку компиляторов.
Так вот, поддержать кучу платформ – сейчас не сложно, такую возможность и предоставляют современные языки через LLVM.
Во-вторых, уникальность haxe в том, что он позволяет получать (относительно человекочитаемые) исходники на хорошем спектре языков высокого уровня.
Это позволяет реиспользовать код на haxe в куче окружений. Например, игровой сервер может быть написан на java, php, node, ... и подключить игровую логику просто как модуь.
Или, например, запихать описание модели/сериализацию в нужный формат в блендер, через транспиляцию скрипта в питон (я так делал)
Можно писать на haxe игровую логику под разные движки. Для Defold – через транспиляцию в lua, для Godot – через GDScript и т.д.
И в-третьих, он интересен и хорош именно как язык, по выразительнсти и функциональности.
Мощная система макросов, развитая система типов + современные фишки типа паттерн-матчинга и, уникальный по-моему подход к введению zero-overhead абстракций через понятие абстракта.
Совсем не обязательно. Haxe выдает исходники на c#, а вы уже можете использовать хоть на сервере/десктопе в .net, хоть в юнити (и через mono, и через il2cpp) – везде, где можно писать код на c#/