I was (and still am, in some ways) against the idea of learning one language and trying to use it everywhere. But nowadays, there are so many transpilation and adapter systems going on that... everything is a bit fuzzy.
That made me remember Haxe. Their goal all along was to have one unified language to deploy anywhere.
Does anyone here use Haxe regularly? In production? I'd love to hear about your experiences and what you've used it in-place of.
> When I finally committed to this port my first decision was to rewrite the game in C#/Unity. After Obra Dinn I’m a solid fan of Unity – the editor, the entity/component design, the build system, the ubiquity, just about everything.
> I made it a few days into rewriting before finding that although I like C#, I like Haxe more. [...] Still it’s hard to overstate how appropriate Unity is for someone in my position: a solo developer targeting multiple platforms and desperate for a popular, proven, and well-supported engine and build system.
> Fortunately, Haxe is a transpiled language, meaning that you write in one language (Haxe) and it gets converted to another language (Javascript, PHP, Python, C++, C#, Lua, etc) before being compiled/interpreted for whatever target you’ve got. So it’s possible to write code in Haxe and have it transpiled to C# that can be loaded and compiled in Unity. Which is how I decided to roll this.
From "Cramming 'Papers, Please' Onto Phones" (last year).
Original post: <https://dukope.com/devlogs/papers-please/mobile/>
HN comments: <https://news.ycombinator.com/item?id=32371423>
Haxe was never great, but it was a bit more efficient and productive than using the GWT-based PlayN (formerly Fourplay). The language itself was just not quite right and felt like a harder version of Java or JavaScript.
It's not really a problem anymore, but compiling to ActuonScript used to be pretty buggy. Now that Flash is long dead, it's possible that the cross-compilation problems might be lessened.
They also may have added some additional features making it less painful, but I'm not convinced.
Send me an email and I'll fire off a few things.
I've also written Maven plugins - and later when I ditched Maven, Bazel rules - to incorporate Haxe projects into our build systems that work pretty well. This makes it pretty seamless to incorporate say a Haxe built Java library into a project, and the same utilities in Javascript - including debugging in Eclipse or the browser.
It's not all sunshine though, I find that Haxe-compiled Python code tends to be underperformant and needs a lot of love to become as performant as, for example, the equivalent Java code. And it is true that the community is smaller, so it can be hard sometimes to get answers to questions. But it's still fun to write and work with, and I definitely see myself continuing to use it in the future.
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.
[0] https://ceramic-engine.com/ [1] https://github.com/haxeui/haxeui-core
I don't know any other companies who are releasing games in Haxe today.
I've remember going through quite a few different game engines (Godot, Unity, Defold, etc.) but HaxeFlixel had the most "natural" feel for me to code in, which is largely due to Haxe itself.
At one point around 2014 I was looking for alternatives and tried Haxe with OpenFL. I loved the language but the ecosystem was super fractured. I remember something was breaking on the latest version of OpenFL and the cause was in some intermediary layer to make the whole thing work (Lime IIRC).
I've found tons of resources and cool people in the Godot environment that I've worked with. I'm taking a break on the game to develop new features for an addon we use in-game with the maintainer on things, which is not something you get as often with a more seldomly used platform. All to say, I'm satisfied with our decision.
Also OpenFL was missing some Flash features the project relied on and I had to spend a lot of time on a fork of their repos patching them in.
[1] https://github.com/HaxeFoundation/hxcpp/graphs/contributors
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.
[1] http://blog.databigbang.com/searching-for-substrings-in-stre...
- [1] https://jkbgames.com/w/index.php/MegaMan_X:_Corrupted_Wiki
I mainly used it because it brought some sanity to the whole Javascript landscape, especially at the time where many frontend libraries were pretty immature.
Never really used it for anything because as a Javascript transpiler though.
It doesn't provide a consistent enough api across all of the language backends. For example, the tink http framework only targets node and php.
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/
Compiler ergonomics are important for me these days.
