
The Joy of Haxe - yawn
https://medium.com/@fontstruct/the-joy-of-haxe-84f933f4b859
======
dyarosla
Like the author, I too have the same opinion after having used Haxe for over 5
years.

    
    
      Five years on from starting with Haxe at FontStruct, I’m genuinely surprised to find that I feel no regret whatsoever regarding our decision to go with the technology.
    

I absolutely adore the language. Not only is it awesome at
transpiling/compiling to native across this whole spectrum of targets, the
language itself keeps surprising me with how versatile it is; with great type
inferencing, compile time macros, platform-conditional compilation, and more.

I've launched iOS, Android, Web, Windows and Mac apps that all shared the same
code base. I can't see myself ever wanting to go back to using a single-target
language again. I highly recommend trying it if you're on the fence. [0]

 _Note: I am not affiliated with Haxe, just a huge fan._

[0] [https://try.haxe.org/](https://try.haxe.org/)

~~~
mlthoughts2018
I’ve only had the opposite experience. I worked on a team that inherited a
large Haxe codebase for an online education tool, and we found Haxe to be
exceedingly bad, even apart fron the nature of the code we inherited. We spent
a lot of time porting most of it to a mix of Scala and Javascript. I still
remember the daily emotional stress of working in Haxe.

... _shudders_

~~~
dyarosla
What was bad specifically? This comment reads more of a ‘the codebase we
inherited sucked to rewrite’ than anything else.

~~~
mlthoughts2018
Some things are generic critiques of haxe: standard library has poor
documentation and big feature gaps, often important third party tools are
basically abandoned, no support, generated code is extremely hard to debug or
understand (both C++ and Javascript outputs for us).

Conditional compilation is a horrible, horrible idea period, and is
particularly easy to turn into an indecipherable brittle mess in haxe. This
was made worse by the previous authors of the code we inherited, but is really
a case where it’s the tool’s (haxe’s) fault for implementing the feature in a
way that makes it an intrinsic foot gun.

Lastly, it was a big turn off to our candidates, and many people we
interviewed expressed lack of interest in working with it.

~~~
dyarosla
I’d love to hear more. What’s missing from the std features? Where are the
docs lacking?

I will agree to your point about abandoned third party tools but that happens
with any language? It’s just more pronounced on a less popular one. I will
also agree about the code it produces: the point of a transpiled language
isn’t for its output to necessarily be readable but first and foremost fast.
You wouldnt expect c to produce understandable assembly in all cases, would
you? Plus it maps all lines to your Haxe source so you shouldn’t even have to
debug large blocks of native code anyway.

What necessarily does Haxe do that makes for conditional compilation to be so
bad? AFAIK it works in the exact same way other cross platform frameworks have
it (eg, Unity)- it’s probably the cleanest way to do it; I certainly wouldn’t
say it promotes brittle code practices at all, but ofc, like anything, can be
misused.

I can see it being a potential turnoff to candidates given it’s relatively
unknown status... but the language itself reads and writes like a C-style OOP
language: there’s nothing that should necessarily turn people off besides that
it’s an unknown, especially anyone coming from a C or Java background.

~~~
hzhou321
> the point of a transpiled language isn’t for its output to necessarily be
> readable but first and foremost fast. You wouldnt expect c to produce
> understandable assembly in all cases, would you?

I would like to argue about this philosophy. When your target output is not
readable, then you restrict the developer to work inside your upper-level
language. This is fine if your upper layer is robust and transparent enough to
reason about. In C's case, there is rarely a case one needs to work at the
assembly level to reason/debug. Is this the case for Haxe? Now if you even
imply that developer need work in your output layer even one percent of the
time, then it is responsible to make sure the output is readable. Otherwise,
it is a gun shooting the foot -- even only 1% of the time.

The background is that I love C. I find C very straightforward to reason about
and very simplistic to allow more logic to be spelled out in a clean way (than
C++ for example). Now the above passage -- putting assembly as an analogy to C
-- sounds prickly.

~~~
dyarosla
The idea is that yes, you do 99.9% of your work in Haxe and it is robust
enough to handle things. Only times you might drop down to your native
compiled language is if you want to interface with a native library/component
for which there is no 3rd party extension to Haxe yet. Even then there are
Haxe based methods to fit most of those cases too.

I think the analogy is accurate: Haxe is not meant to be used to compile to
native and then modified in native further. It can be... but the general
usecase is to write everything in Haxe and not have to then modify the
transpiled result. Similar to typescript in a way... you can add JavaScript
after the fact, but most likely you’d directly add native untyped JavaScript
within your Typescript code, not directly to your transpiled result.

------
danso
I first learned about Haxe through Lucas Pope’s dev log for “Papers, Please”.
Sounded interesting and fun, though Pope (who developed PP on a Mac) said he
also had written custom tooling for his work — maybe that situation had
changed since 2014:
[https://www.gamasutra.com/view/news/209905/Road_to_the_IGF_L...](https://www.gamasutra.com/view/news/209905/Road_to_the_IGF_Lucas_Popes_Papers_Please.php)

For his new game, Return of the Obra Dinn, he went with Unity because of its
3D capability:

[https://forums.tigsource.com/index.php?topic=40832.0](https://forums.tigsource.com/index.php?topic=40832.0)

> _I 'm gonna use Unity for this one. I fell in love with Haxe/OpenFL on my
> last project but unfortunately the 3D situation is not that great there yet.
> Also, it's time to finally see why 90% of the indie scene is using Unity. I
> have a good amount of experience with 3D games and the few days I've played
> around with Unity so far have been pretty productive. The animated title
> screen scene up there (with post-processing shaders and all) was created in
> one day. I now have unrealistically high hopes._

~~~
dyarosla
I wouldn’t be surprised if he does a mix of Haxe and Unity; Haxe compiles to
C# too and works very nicely with Unity.

In my current project I ultimately switched off of Unity for 3D due to its
less than stellar WebGL support (and I wanted to target web), but with Haxe I
simply changed my target to JS and got to reuse most of my code. The ability
to switch/add targets at any point of your product’s lifecycle is incredible.

------
jondubois
Haxe is strange in that it seems to be very well known among developers but
relatively very few actually use it. I guess it's an old project with very
specific use cases; like building certain kinds of multi-platform apps.

It's nice to see a project with such a dedicated community.

It's a shame that most developers started using TypeScript instead of Haxe;
that seems like a missed opportunity. TypeScript was pretty painful to use in
its early days; it shows the importance of positioning and marketing.

~~~
sdegutis
Well TypeScript also had a huge corporation with infinite budget and a large
full time team of contributors and evangelists which probably helped adoption.

~~~
m_sahaf
Counter-example: Dart.

If corporate support is a definite factor, Dart would have taken off way
earlier than now. A bigger factor in TypeScript's success would be the ability
to gradually migrate the projects as it's a superset of JavaScript. How do you
start migrating? Flip the file extensions from .js to .ts with loose compiler
options, then gradually add typing as the options are tightened. It's factors
like these that drive spread of language, not "huge corporation with infinite
budget and a large full time team of contributors and evangelists." Dart had
no short of those and still not much accepted.

~~~
pjmlp
Dart suffered from corporate politics, Chrome team wasn't really into it, got
rescued by Ad Words team, and now are trying to become relevant outside Google
with help Flutter.

If Chrome team actually cared about Dart and went ahead with Dartium's
integration, Dart's future would have been much different.

Then the Angular team decided to dump Dart and go with Typescript.

So politics as usual.

~~~
ppseafield
Dart also suffered from external politics: a chrome-first Dartium VM stank of
ActiveX to most people. IIRC Microsoft had discontonued its silverlight plugin
for lack of interest/support. The general attitude began to shift towards just
JS/HTML5 tooling in the webdev community.

And in addition to not having full support from Google, there was not and
probably would never have been buy-in from Mozilla or Microsoft. Also the
language IMHO didn't offer much more than JavaScript, and 6to5 -> Babel was
gaining traction at the same time. It wasn't a good recipe for success.

------
Lerc
I used haxe a lot in the past, but with the newer enhancements to JavaScript I
found that I ended up using JavaScript. Destructuring assignment arrow
functions and more concise object literals, ... operator enable much more
concise and readable code.

Haxe seems to be much more conservative in development. Haze is aquiring arrow
functions but I think there was quite a degree of initial resistance to the
notion. I proposed a change to allow the new Javascript style consice object
literals (simply allowing {fish,cheese} instead of {fish:fish,cheese:cheese}
but was shut down with a 'we don't like it'

I would prefer to use a independent language over one developed by a megacorp,
but I fear Haxe will fall behind TypeScript due to their resistance to change.

My own personal experience has motivate me to move to something else. The
proposal I mentioned above left somewhat of a bad taste. The process went
contrary to the processes listed. Notably The proposer is supposed to call a
vote after discussion had concluded. Instead it was just shut down with a "we
had a meeting and decided against it". I could give no counterargument because
there was no argument to counter. I'm not against languages having a
dictatorial model for development, but having a facade of an open process that
carries no weight seems wrong.

~~~
dyarosla
Sucks to hear about your experience. Like you said yes arrow functions are
slated for the next major release.

As for the process, I think it has become a little more stringent for sure. To
submit a request for consideration you’d need to submit a proposal on GitHub
with attention paid to impact to existing code and impact on future Haxe
features- perhaps your feature request wasn’t deemed to be thought out enough?
It also looks like you’d get more explicit consideration if you are a sponsor
of the language ([https://haxe.org/foundation/support-
plans.html](https://haxe.org/foundation/support-plans.html))

So yes, while it isn’t a completely open vote, I also think most languages’
directions are decided by committee in a similar way. I’m sure the Haxe
community would love to see examples of other communities with better
practices to learn from.

~~~
GordonS
> perhaps your feature request wasn’t deemed to be thought out enough?

In which case surely it should be discussed, rather than shut down with "no"?

This thread had me interested in Haxe, but reading these comments about the
unfriendly, negative responses to proposals has put me right off.

~~~
dyarosla
To play devils advocate: if every feature request had to be thoroughly
discussed you’d never get anywhere.. the onus should be on the proposer.

That said, you can always file an issue in github and have a discussion there.
For Haxe it’s a very active location for discussion there.

~~~
bendmorris
>the onus should be on the proposer

I'll bite: what should @Lerc have done differently in his proposal
([https://github.com/HaxeFoundation/haxe-
evolution/pull/51](https://github.com/HaxeFoundation/haxe-evolution/pull/51))?

~~~
dyarosla
It seems like there’s some leeway in ‘After reaching general consensus or
voting takes place, the PR is merged by someone from the Haxe developer team,
and the proposal becomes "active". When merged, the proposal will receive its
number from the corresponding pull request. If the proposal is rejected, the
PR is closed with a comment explaining the reasons.’

I think general consensus was reached without a formal vote. Discussion was
limited but explanation was given: language clarity would be impacted. A few
main contributors agreed. @lerc didn’t provide much of a counterargument.

That said, what would you have wanted to see done differently? A formal vote
held? This proposal seemed to be a matter of preference, with no real
consensus on clarity. Workarounds were even proposed. What would be your ideal
resolution? Not shutting down the discussion as haphazardly? How much further
should it have gone?

~~~
Lerc
I didn't give much of a counterargument because there was hardly any argument
to counter. If the issue had not have been closed so quickly I would have
pressed people for specifics of what they thought were wrong. At the time I
believed I was the person responsible for calling the vote so I was prepared
to give them time to provide a coherent argument.

~~~
dyarosla
I think at the end of the day there was simply no interest in the proposal.
Nadako was "not opposed to it" but that was about it. Personally, I would have
liked to not have seen the conversation ended with a "that's what we decided
elsewhere" message.

That being said, this particular proposal seems like a matter of opinion (on
the level of tabs vs spaces) to which no amount of argument would have really
swayed people. Definitely something to learn from here. Thank you for sharing
your story!

~~~
Lerc
I feel like you are missing the point here. Project maintainers can behave
like absolute arbitors if they want to. Many projects successfully work by
this mechanism. The issue as stake here isn't how they decided on the proposal
but rather that the way that they decided on the proposal is different to the
processes that they specified.

They are soliciting contributions by promising an open process ( see
[https://github.com/HaxeFoundation/haxe-evolution#voting-
proc...](https://github.com/HaxeFoundation/haxe-evolution#voting-process) )
but disregarding those processes when they feel like it.

Ironically, the discussion we are having here is much closer to the level of
engagement that should have happened there.

As a sidenote, I'm just curious, what do you personally think of the proposal?
Would you like to have the concise object literal notation in Haxe?

~~~
dyarosla
I think I posted in a parent comment that I think they did follow the
(somewhat arbitrarily defined process) if you give leeway to the phrase "After
reaching general consensus or voting takes place"; whereas it seemed like a
general consensus was reached in that situation. I think a clearer process
that's a little more transparent would definitely be beneficial, including
clearing up that phrasing.

On the sidenote, I personally don't run into many (if any) situations where I
would use concise object literal notation. I'm on the fence as to the issue of
clarity and whether it would help/detract/be neutral for Haxe.

The style of concise object literals is fairly inconsistent with the rest of
the language at the current time, and I could see how it could lead to
clarity/confusion issues. Because I believe it's more of a syntactic sugar
than anything else I am leaning to agree that macros may be the way to go for
it.

------
chc4
I was talking with some friends a bit ago and was surprised to learn that Haxe
is used a lot in game dev and embedded a lot. Apparently a lot of set top
boxes like Tivo or car infotainment systems use it, and there's a lot of very
good game engine infrastructure in it -
[https://armory3d.org/](https://armory3d.org/) was specifically mentioned as
being surprisingly high quality, and all the people that wrote games on
Kongregate apparently switched to Haxe.

------
mromnia
Is it possible to use Haxe for anything except gamedev and keep the
crossplatform aspect? For example for backend webdev, it seems like you can
compile to nodeJS and use express, but then you can't really compile to any
other platform. You can compile to PHP, but you're also stuck with PHP
frameworks.

Basically what I'm saying is that for Haxe to be truly crossplatform, it
requires Haxe-native frameworks in the target domain. But that doesn't really
seem to be the case outside of games, so that advantage is lost.

~~~
ofrzeta
Does it realistically make sense to have a web meta-framework that compiles to
different backend frameworks such as Node.js or PHP?

~~~
mromnia
Maybe, maybe not. It just feels to me like Haxe only really makes sense for
gamedev, and even then only barely, because of huge, crossplatform game
engines like Unity.

I really like the language (after reading the tutorial at least), but I'm not
sure where would using it make sense. For backend stuff it just seems
completely inferior to Typescript (considering library support especially).

------
roywiggins
I am glad Haxe is still going strong. I remember when it was an alternate
language for the Flash virtual machine- everyone thought it was very cool at
the time. Now Flash is dead, long live Haxe!

~~~
zwetan
you're comparing apples and oranges

Flash (a browser plugin) being dead does not make ActionScript (a programming
language) dead

you can use ActionScript to publish with Adobe AIR and Haxe AFAIK can do that
too

~~~
titanix2
No he's right. Haxe was developed by a French game company to target the Flash
runtime instead of using Adobe's compiler. It can also compile to other
languages: it was uses to code the full stack in the same language will using
popular runtimes at the time (PHP, Javascript, Flash).

------
jimhefferon
Best way to learn it?

~~~
haxiomic
The manual on haxe.org is a good place to start
[https://haxe.org/manual/introduction-what-is-
haxe.html](https://haxe.org/manual/introduction-what-is-haxe.html)

Then explore the code cookbook for more advance usage and patterns
[https://code.haxe.org/](https://code.haxe.org/)

------
giancarlostoro
I want to love Haxe but tooling outside of Windows seems limited, although I
havent looked at how good VS Code is with it yet, so maybe I'll look into
that. Otherwise I am going to stick to D and Python.

~~~
k_
I never used Haxe in windows. I agree that ten years ago tooling wasn't all
that great (on linux at least), but now with the focus on VS Code we have a
language server following Microsoft's LSP [0] that we can even use on other
editors (sublime text, neovim, etc.).

[0]: [https://langserver.org/](https://langserver.org/)

~~~
giancarlostoro
Good to know, and yeah, at least someone knows what I meant.

