Hacker News Reader

Comment by dyarosla | Hacker News Reader

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/

View on HN

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

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

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.

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.

> 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.

One could reasonably use llvm for the backend (assuming <cough> they had an actual reference grammar for the language</cough>) and then you'd have the same problem, the output would just be some unreadable intermediate language that is far from transparent to the average user.

The manual doesn't really go into enough detail to imply you'd need to fiddle with the outputted code but I'd imagine any case would be a bug rather than a feature.

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.

> Where are the docs lacking?

One thing that gets me is that the Input/Output section of the official manual [0] has gone unwritten for quite a while, now. [1]

[0] https://haxe.org/manual/std.html

[1] https://github.com/HaxeFoundation/HaxeManual/issues/16

I'm shuddering over the thought of porting and maintaining the scala and js code. Are you using Scala.js?

Scala has many problems as well, but I’d say at least two orders of magnitude fewer than what we encountered in haxe. Scala was chosen for various business compromise reasons, not any particular preference for Scala.

That would surely help if you could tell us what Haxe specific problems you had.

hmm, there are #if js/#elseif flash blocks in the drawing example using canvas - does that mean the basic drawing is not cross-platform?

Drawing is done in several different ways on many different platforms- sometimes a single platform has multiple options.

Some libraries that work on top of Haxe can give you a standard API that’ll let you not have to conditional compile (OpenFL, NME), but in general there’s a lot of trade offs that need to be considered at a platform level for drawing that conditional paths for drawing aren’t too uncommon.

Reply on news.ycombinator.com