Ask HN: Does anyone here use Haxe?

A few years later I tried to rebuild an old project running openfl 3.0 and failed miserably. I ended up building a docker running an old base image to get it working. That made me realize that the haxe community toolchain also evolves quickly in a non-compatible way.

The TypeScript ecosystem already way too large and way too fast. It's hard to follow both. It's also harder to find collaborators / hires.

In a fantasy world a megacorp would pick up haxe as a main driver and pump money into the ecosystem and make lots of people haxers.

Haxe was created by Nicolas Cannasse, also known as warp. He was a software developer at french game studio Motion-Twin in the 2000's. At the time they were producing web games using PHP and Flash. This required some shared logic both in the client and server; which caused some duplication. As any engineer in his situation, he decided to solve this with his own compiler. :D

One of the earliest languages he created was Motion Script, a an AS inspired language compiling to the AVM1 bytecode (SWF). You can see some examples in their 2006 game Hammerfest [0]. Haxe is a successor language with the promise of being compatible with many platforms. It's pretty remarkable in this way as one of the first languages offering expansive target of multiple _platforms_. Not just CPU architectures or OSes, or languages with a dedicated VM. Haxe was pretty successful, and and all Motion-Twin games since around 2008 used this language. It's used even today with their latest releases such as Dead Cells. Warp left Motion-Twin to create his own studio Shiro Games and is also obviously still using his language: Evoland, Northguard, Dune spice wars all use it.

From my side, I'm working on Eternaltwin [1], a project to preserve Motion-Twin's web games. Games that were more reliant on the server side were migrated to regular JS; but client heavy games such as Hammerfest, AlphaBounce, their Kadokado games, Fever, etc. use Haxe.

We use Haxe as a way to migrate off Flash. In particular, we had many user-made content using Flash. In the last five years, we migrated almost all of it to Haxe while still compiling to Flash 8; and we are now preparing to target HTML5 - but it requires removing all the Flash specific-bits. Doing it in two steps allows to perform the migration incrementally. It also requires use to move to more recent versions of Haxe. Due to the specifics of our project, we're stuck using Haxe 3.1 (to target Flash 8), we even sent a few bugfixes to this old version to ensure it keeps compiling today...

Regarding Haxe itself, I'd say that it's a very impressive language and probably a very solid choice if you are creating a video game and need to target multiple targets. It's good for final applications. However, I feel that it falls short as a language for libraries. It felt very well suited for me to implement schema validation and client libraries. Write them once in Haxe and export for Node, the JVM, Python, PHP, etc. in one go. To support all those targets, it needs to bring its own compat layer that makes it less ergonomic to use Haxe libs from target-native code. It also requires a lot of macros; which tend to be less well supported by editors. Regarding tooling, their package manager improved a lot I feel and now supports project-local dependencies with lock files and they have a nice builtin doc generator.

Regarding integration, there are still some slight oddities; like _requiring_ an env variable to find the standard lib.

To sum it up; it's a pretty nice language, but I feel like it's also showing its age (it still feels very attached to older OOP styles found in Java or AS3).

[0]: https://github.com/motion-twin/hammerfest/blob/master/class/... [1]: https://eternaltwin.org/

I've found Haxe to be pretty pleasant in this situation. The only areas I really needed a library were around graphics and input, and Heaps looked more interesting to me than the JS alternatives I looked at.

The language itself feels like a pleasant mush of all the Java-y OO languages, but without the entire kitchen sink included. You've got all the polymorphism and generic typing stuff you'd expect from a java clone, plus algebraic data types, plus the ability to drop to dynamic duck-typing if you have to. And the type inference has worked pretty well for me. Oh, it also has a macro system I've never needed to use.

The tooling situation is good but not great. The compiler's messages have generally been clear. I am using vim + universal ctags for development, and it is fine but not as deluxe as a working LSP. I didn't have any luck getting Haxe's LSP working with vim, but I assume a VS Code based setup is more of a happy path and would have better luck.

Output-wise, the JS it generates seems fine. For my particular use case I care more about the readability and debuggability of the generated JS rather than the size. It has not been a problem to understand where an issue is coming from while looking at the generated JS.

Performance wise, the only issues I've had were caused by my own foolishness in making thousands of draw calls instead of batching things. Other than bugs I haven't seen any performance problems.

When it comes to libraries, you have to contend with both the relatively small size of the community, as well as the difficulty of writing a library that actually supports all of Haxe's compile targets. Haxe errs on the side of pragmatism instead of identical behavior on all of its supported platforms. So often you'll find nasty platform-specific logic in the heart of libraries, and if your target isn't supported then you have to dive in and fix it yourself. It is not a good language for grabbing a few things off of npm or cargo and slapping them together.