Обновить
4

Пользователь

4
Подписчики
Отправить сообщение
Ну здесь проблема не столько языка, сколько именно русскоязычной вики-статьи, которая концептуально не актуализировалась, наверно, с ее появления. 15 лет назад Haxe появился в качестве альтернативы AS3. Flash-платформа тогда была на пике: плеер в каждом утюге; игры, ютуб, энтерпрайз. Но сам язык уже тогда обладал гораздо более развитой системой типов и кучей других фишек, часть из которых позже стала мэинстримом, и кое-что сверху.
Что до флэша – сейчас это одна из десятки целевых платформ, далеко не самая популярная. Думаю, что трансляция в JS или что-то нативное сейчас используются гораздо чаще.
Рекомендую ознакомиться с англоязычной статьей на вики, она выглядит более актуальной.
Либо он загнется и не надо будет его поддерживать, либо он станет стандартом в геймдеве и надо срочно впиливать его поддержку.
Я бы оценил его шансы не загнуться в обозримом будущем достаточно высоко: инструмент изначально разрабатывался «для себя», и активно используется рядом весьма успешных инди-студий (MotionTwin, Shiro, Proletariat)
А куда предполагается впиливать его поддержку? Он сам кого хочешь поддержит: есть кейсы успешной интеграции с UnrealEngine, Unity, SDL, Node.js, массы браузерных библиотек типа pixi.js и т.д.; поддержка во многих IDE.

Самое забавное, что его используют компании с миллионными оборотами в $, и похоже не особо донатят в фонд т.к. как вы говорите там два землекопа и стажер.
Тут все на удивление прозрачно: на их сайте есть «тарифные планы спонсорства» и список компаний спонсоров (в том числе, уже упомянутых в треде).
К тому же, несмотря на небольшую команду, работа над компилятором ведется весьма активно (гитхаб, все видно). Далеко не факт, что есть потребность раздувании команды. Ну и вообще, «писать компилятор на OCaml» – довольно нишевая позиция, на которую вряд ли есть куча соискателей.
Ну почему же сразу бред? Вот, например, Shiro Games. Небольшая команда из Бордо. Свой язык программирования, пара виртуальных машин, 3D-движок и куча тулинга не мешают им делать хорошие игры и быть в плюсе.
Что такое «основная среда», и о какой среде речь? Выше в ветке были названы три распространенных варианта, два из которых кроссплатформенные. Этак и до плюсов докапаться можно из-за студии. Какое вообще отношение язык имеет к дистрибьюции VSCode или Intellij IDEA?
Документация по самому языку довольно неплохо написано, много хороших и интересных примеров можно найти в разделе cookbook.
Что до стартовых туториалов, особенно в контексте разработки игр – с haxe слишком много вариантов того, как начать, и в какую сторону двигаться. Гида по этим вариантам, действиетльно, не хватает. А сами туториалы есть не только у языка, но и у игровых движков; для старта может оказаться полезным смотреть на них. Каналов для общения хватает: есть и официальны форум, гитхаб, сообщества игровых движков. В русскоязычном сегменте есть скайп и телеграм-чаты.
Чтобы было более понятна ситуация приведу пример с шарпом, на котором тоже можно делать игры. Делать можно на юнити или на моногейм, а Introduction to the C#с MSDN не слишком поможет стартануть.
Да, часто языки, имеющие таргетами другие языки, тащат за собой рантайм и std-либу, которые могут весить очень много. Когда-то давно смотрел, что scala-js выдавала helloworld на несколько мегов.
В случае Haxe, ему приходится обеспечивать одинаковую работу строк, массивов, трейсов и прочего на всем заопарке целевых платформ (а заопарк впечатляющий).
Поэтому рантайм в пару десятков кб – довольно скромно. Это не множитель к размеру, а слагаемое. На helloworld-ах его вклад, конечно, наиболее заметен.
У Haxe в отличие от многих транспайлеров есть отличный dce, который вычищает почти весь неиспользуемый код, поэтому в результат попадает лишь необходимый минимум стандартной библиотеки.
Вот со студией как раз вообще никакой интеграции нет. У MS есть совершенно отдельный кроссплатформенный редактор VSCode – речь о нем. Для нее MS придумали очень классную штуку – поддержку language server, который позволяет всю интеллектуальную поддержку языка вынести наружу и легко интегрировать. В случае с Haxe так и сделано: сам компилятор, который знает все о типах (даже тех, которые генерируются макросами в процессе компиляции), обеспечивает поддержку языка. Поэтому в VSCode, наравне с другими редакторами, поддерживающими lang серверы, поддержка haxe на уровне.
FlashDevelop, который сейчас также известен как HaxeDevelop, вроде бы тоже имеет интеграцию компиляторной помощи; а так же много всяких удобных штук для haxe. Он продолжают развиваться.
Ну и наконец, люди, избалованные JetBrains, могут поставить отличный haxe-плагин, у которого как раз на днях вышел новый релиз. Я пользуюсь именно этим вариантом.
Не могу согласиться про скриптовщину, если правильно понял, о чем речь. Haxe никогда не позиционировался ни как «легковстраиваемый рантайм», ни как «shell-ориентированный интерпретатор». Если рассматривать кросс-компиляцию в другой скриптовый язык, то это всегда будет усложнением системы — даже при наличии своих плюсов, не панацея.

А «не взлетел» он, скорее всего, потому, что нет того, что у HaxeFoundation нет продавана. Самый заметный продаван – Джошуа, но он продвигает OpenFL, из-за чего, к сожалению, Haxe ассоциируется именно с ним.

Язык мощный, но у него своя ниша. Не всегда там, где он мог бы быть полезен, про него знают/понимают.
Согласиться безоговорочно я могу только с первым утверждением: документация – полезно.
Но многие используют lang server, так что в редаткторе видно выведенный тип, даже если он не указан.
А как можно сократить использование досрочных return? Если что, в haxe тоже everything is an expression, и всегда можно обойтись одним.
В общем, ответ на начальный вопрос можно перефразировать в «потому что оно плохо согласуется с системой выведения типов».
Одна фича против другой, есть выбор и он сделан.
Под «типом функкции» понимается возвращаемый тип? В haxe активно используется выведение типов, поэтому возвращаемый тип часто не указывается. В этом случае, тип как раз выводится из выражения в return, либо на основе первого вызова. Если бы тип любой функции без return приводился на основе первого вызова, то компиляция бы ломалась добавлением вызова функции без сохранения результата в начало программы. Если бы всегда на основе последнего выражения, то это очень странно бы выглядело на статических таргетах. В конечном итоге, от выведения возвращаемого типа пришлось бы отказаться вообще. Мне кажется, оно того не стоит.
Типизация статическая, Void-функции нужны. Вероятно, дело в этом.
Если язык абстрагирует работу, скажем с самым слабым местом, с i\o или же структурами данных, с помощью собственных реализаций, то он он просто нивелирует все плюсы.

Язык предоставляет абстракции для обобщенной работы с I/O и структурами данных на разных платформах. Как один из инструментов.
Кроме этого, он предоставляет много других инструментов: экстерны, абстракты и тайпдефы, которые позволяют писать обобщенный, и в то же время эффективный код.
Из недавнего: писал абстракцию над промисами для шарпов и js. При компиляции в js оно превращалось в работу со встроенными промисами, а на шарпах использовало библиотеку RSG.Promise. АПИ у них отличается принципиально, но в сгенерированном коде нет прослоек, один и тот же хаксовый код превращается на каждой платформе в прямые обращения к собственным платформенным классам.
Почему бы не писать сервер, на тех языках, на которых хочется и связывать это все при помощи микросервисов?

Сам сервер можно писать на чем угодно, но есть большие куски логики, которые бывает очень удобно использовать независимо на клиенте и сервере.
Если их писать на haxe, то даже без микросервисной архитектуры можно использовать эту логику в совершенно разных стеках (В частности, менять стеки, не меняя логику). Мне известны успешные примеры использования haxe c серверной стороны, например, в стеках node.js, java, php.
А код на ue и unity разве может быть идентичным?

Я верю, что можно написать такие прослойки, которые позволят запускать один и тот же код на обоих движках, хоть это будет и не самым эффективным/целесообразным.
Тем не менее, большая часть кода может быть написана с использованием абстракций, что позволит переносить наработки между платформами независимо.
Вот эти ребята использовали оба движка с хаксом
www.youtube.com/watch?v=WKs8QRuMC3k
и в каком-то из докладов я слышал, что чать наработок успешно перекочевала.

Кроме того, есть Kha, который предоставляет абстракции для работы с графическими АПИ, и позволяет писать достаточно низкоуровневые вещи типа шейдеров, корые можно компилировать под OpenGL, DirectX, Metal, Vulkan, WebGl, канвас и т.д (в том числе, для запуска внутри готовых движков типа анрила).
Так делают все крутые игровые чуваки.

Ну тут я даже не знаю, как и возразить. Такая уверенность завораживает.
Зато haxe позволяет написать 30 строк макроса, который позволяет сгенерировать безопасный десериализатор для всех интовых полей классов, отмеченых метой.
Довольно изящно работая с узлами AST через pattern matching (к слову об устаревшем синтаксисе)
try-haxe.mrcdk.com/#4a425
Вот пример, сам макрос на закладке Source 2, можно посмотреть, как работает на js, и какой код генерирует.
12 ...
12

Информация

В рейтинге
5 398-й
Зарегистрирован
Активность