We used this for a client game project - a Candy Crush clone, about 4 or 5 years ago successfully. The client wanted the game to run on browsers (HTML & Flash for older browsers), iOS and Android, with a fairly tight budget. Having done a lot of AS3, the learning curve was pretty low.
There were a reasonable number of specific things to learn about compilation, packaging and handling things like device rotation, viewport sizes, etc. along the way. But we had a cleanish single codebase for all targets.
Documentation and real world examples were fairly slim on the ground at that point, but it certainly worked and ran well to very well across all devices. It certainly offered a pretty consistent experience across all the targets and ran at a decent framerate on everything we tested against. We couldn't really find much to fault it on once we had everything up and running. I seem to remember compilation times being incredibly fast.
I'm kind of surprised it's still a thing - it brings back some good memories & makes me want to have a go with it again as it was an enjoyable way of working for that type of 2D game project.
I guess just because it seemed fairly niche, seemingly targeted mainly towards people making 2D games for cross platform use, around the same time things like Unity & UE became the hot new thing to be using for that type of game dev. People also seemed to look down on it's AS3 like syntax and there was a limited pool of people willing to commit large numbers of hours to working on it as part of their career path when Apple were bringing out new frameworks every year for doing things like AR, 3D, SceneKit, IAP, etc. It never seemed it could fully embrace the newer native abilities that everybody wanted to be working with while maintaining its ability to cross compile. I guess browser based gaming (Flash, Facebook games, etc.) kind of died at the same time as well.
We used to do lots of Flex development back then for various commercial projects, then Flash/AS3/Flex got all but abandoned overnight, becoming almost hated. We managed a large cross compiled (iOS/Android/Windows/OS X) AS3/Flex project with native hooks for various platforms up until mid last year, parts of the codebase were nearly 10 years old, when we finally managed to convince the client it would cheaper to re-write in a mix of HTML/JS/Electon/JS bridges than continue to battle the existing codebase. We rewrote it all in around two weeks, improved the UI and fixed long term numerous issues that had plagued us for at least a couple of years, mainly due to being reliant on closed source 3rd party Windows/Mac integrations/hooks that had been abandoned by the original developers and Adobe also largely abandoning the AS3 iOS/Android compiler.
Also, it didn't really seem to have a huge community and everything seemed to be in a transitory phase with things like Flash being pushed out by iOS native development, the huge improvements in HTML/JS/CSS, etc. Then tech like Swift, React, etc. came along it just seemed to get forgotten as a tool in our arsenal.
We certainly started focusing more on other new stacks/approaches around the same time.
Because in terms of game engines, new engines that get much more publicity, like godot engine, exist. And as Haxe supported Flash when I played with it, I as well thought it was superceded by newer engines.
Half a decade is a lot in human years, let alone IT-years.
Haxe is, or was, used extensively in developing for 'smart' devices, like TVs, I know that either the inventor, Nicolas, or one of the senior Haxe people, was working for Massive Interactive a few years ago doing just this.
I worked with them on that a few years back. I think they're still using haxe on some smart device projects but not all, sadly (easier to find devs with a typescript codebase..).
I don't think Nicolas worked with them, though. I'm one of Haxe contributors but I don't suppose you were thinking of me.
I used Haxe full time for several years for web development (even started a startup with it!)
It predated Typescript, so at the time the killer feature was being able to write type-safe JavaScript, and being able to share code with a backend which is potentially another language (like PHP).
These days I’m at a company with a lot of TS, and too many other languages (Elm, Ruby, Kotlin, Elixir...) so we’re not looking to add something like Haxe, but I often still miss the expressive type system, the really nice language server integrations, having the multiple output targets so it’s the same language everywhere, and the type safe macro system.
So I often use Haxe for hobby projects still, but then I miss things from the JS ecosystem. You have access to NPM but there’s no equivalent project to DefinitelyTyped. Some of the tools integrate well (webpack as an example), some don’t (Jest). React works, but the way JSX works doesn’t integrate as nicely with the language server. Etc
I also missed some modern es6 syntax. Haxe finally got arrow functions in v4. The thing I’m excited by in this release is module level fields - previously everything had to be in a class, now they don’t. Haxe was already good for writing functional style code. Now when you read the source code it’ll look like it and not have the “class” keyword when you don’t need it.
"there’s no equivalent project to DefinitelyTyped" - no, but these days you can auto-convert those TS type definitions to Haxe externs automatically! :)
For those not already familiar with Haxe perhaps the most interesting property is the huge variety of transpilation targets (1). I would not call the resulting code highly readable, but I don't know of anything else with this level of targetability.
C++, Lua, and JavaScript all have had improvements in their readability over the years. I don’t write much Haxe at all, but have followed it for a while. It’s such an ambitious project, even featuring over the years at least 2 different VMs.
Also, if you’re interested in OCaml, check out the source!
My introduction to Haxe was Haxeflixel (https://haxeflixel.com/), an Haxe game development library inspired by flixel (http://flixel.org/), an older AS3-based library which was pretty known in the late 00's in the indie games community.
As the top comment mentioned, I was particularly impressed by the ease of cross-platform development in an age where bigger tools like Unity were still picking up steam. Coming from Game Maker, Haxeflixel felt like the natural step forward. I enjoyed it so much I wrote a book about it: https://discover-haxeflixel.com/
The people behind it launched a fairly successful fundraiser a few years ago so I'm happy the main developer and contributors got something back for their open-source efforts. As far as I know the library is stable - I just about updated the book a few months ago to re-rewrite references to the Flash (RIP) and move people towards the html5 exporter instead.
I still think that in an age of 10GBs+ AAA game development framewords, Haxe and Haxefixel still have a place for your typical 2D / Pixel Art-ish arcade game, although more ambitious and successful games have definitely been made, like Defender's Quest (http://www.defendersquest.com/) from Lars Doucet's, a huge fan of the framework.
I just had a look at the free chapter of your book, the page layout looks very appealing and clean. Would you mind sharing the stack you used to typeset those pages? Is pandoc involved?
Haxe is my favorite programming language. Haxe's macro system is so incredibly powerful that after using it, it makes me cringe every time I have to work with templates in C++. Haxe macros are basically "template meta-programming", but with a lot more power and none of the hideous syntax and error messages. I think the closest parallel in the world of C++ is Circle (https://www.circle-lang.org/).
A Haxe macro is just regular Haxe code with the same syntax and same standard library, except it runs at compile time, and it can operate on the AST of your program. They're like shaders, but for your compiler.
One of the coolest demos of Haxe macros imo (even though it's dumb) is where you can add code completion to your IDE via a URL (https://code.haxe.org/category/macros/completion-from-url.ht...). It works because the macro generates static fields for a class using data it downloads from the URL, and because the Haxe compiler provides a completion server, any IDE with Haxe support will automatically pick up the new fields and present them in a standard completion pop-up/drop-down menu. Just imagine the things you could do with something like that!
Unfortunately, Haxe never seems to get the attention it deserves. The sad fact is that the vast majority of developers are never going to try a new language or technology on their own unless their employer tells them to, or there is some viral article that reaches everyone, and makes it seem like the second coming of Javascript. Additionally, the Haxe foundation never seemed to take much interest in promoting the language. They do have funding, and they organize events/meetups every year, so it doesn't seem like they're going away anytime soon.
Oh well, such is life. People might not think I'm cool when I tell them I know Haxe, but at least I have Haxe!
> A Haxe macro is just regular Haxe code with the same syntax and same standard library, except it runs at compile time, and it can operate on the AST of your program. They're like shaders, but for your compiler.
Scala macros are the same way (but with an obtuse API until Scala 3, which should be out soon after all the syntax bikeshedding is done). It's also one of the things I love about Scala, though I'd understand why others might disagree. Metaprogramming is fraught; even moreso when it's plain that it's a program that runs at compile time (which is also the case with C++ templates, to fewer complaints per-capita for reasons I don't understand)
Does anyone have any real world experiences with Haxe? I've been hearing about it for years and generally thought "wow, that's neat!" but that's been it. Does it actually achieve what it aims for?
I have used Haxe off and on nearly from the beginning. I still use it and was doing some coding earlier today in it.
Two points of friction around it that tend to show up are in tooling and debugging. Haxe is what I like to call "parasitic" in that it leverages existing stacks really easily, but then the tooling of those stacks doesn't always offer the affordances you want.
For example, when Flash was still a major target, Haxe did have some SWF generation functionality, but it didn't accommodate every type of asset equally well and there was a bit of a puzzle - not an insurmountable one, but bigger and more opaque than anyone would face from Adobe's tools - in getting the binding of the embedded asset accessible from your Haxe code. The puzzle persisted through a lot of the SWF features(things like networking sandboxes, which would be used if you wanted to e.g. embed ads in a game, were related to how the SWF was built and delivered) and could result in a lot of timewasting.
Likewise, while the language is extremely savvy about offering access to the low-level functions of different targets - eventually you do come to debugging the generated code. Not because the compiler has failed(it's very reliable) but because there is some kind of platform-specific issue to be solved. And again, it's going to be more opaque to debug that than "doing it native".
The upside of this is that you can choose your target for everyday debugging, and therefore minimize the suck. It can actually be very productive and painless. (Edit: and the language is really up to speed with the idioms in current PLs, so it's often the better choice for writing abstractions.)
A healthy way to apply Haxe is to identify the places where you can put the platform code behind an interface, code that natively, and then code to the interface in Haxe for the rest. That way, you get the fluidity of being able to switch targets and you aren't jumping between layers so often. But this does come with the cost of having to build up a useful interface and really "own your own stack". It's not just-works technology, although it can come close with some of the frameworks.
I implemented the BlockStudio visual programming language (authoring environment + runtime) in haxe [0].
I'm also migrating the website (currently Python) over to it -- I can share data type declarations between server and client-side code, which give me compile-time guarantees that my api calls and return values are not malformed.
A previous employer used it when they wanted to move away from ActionScript due to flash EOL approaching as the goal of transpiling to multiple platforms was appealing, performance was not the best however and they ended up moving towards a different approach. Still, by the time I joined a few primitive libs were maintained in Haxe because they were stable and there was no reason to migrate them, so I had to dabble with Haxe a few times at work, not saying it was terrible, but it was far less enjoyable then our much more robust TS setup, this is arguable tho as since it had been deprecated by the company it received fewer tooling support in house.
Yeah i have used it to make some, small but not trivial games. I really enjoy it. I mostly just target the HashLink vm as its met all of my needs.
The actual language is great. I am a long time ago former flash developer, and heaps.io and haxe has captured a lot of the enjoyment I used to have making games for newgrounds
I used it once years ago. A client wanted rotating ads in banners in Flash for a web site. I wanted to be able to reuse the code for JS. We negotiated the copyright staying with me for a discount on the feature. I did it in Haxe (then stylized as something like hAxE or HaXe or so) and compiled it to both targets. It's not a complex thing like Dead Cells, but it was a quick and easy language to pick up and use from zero prior experience with it.
I've not touched it in years, but if I ever do a side project it'll be one of the tools I'm likely to use.
Can someone explain me how debugging such a language works with so many cross-compilation targets? What if I want to set a breakpoint somewhere in the code,
a) what changes depending on the target (compiled code, interpreter, vm)
b) how debug adapters should work with all that zoo?
Or maybe there are no?
Or maybe a major question: how do you write a complicitaed piece of software in a "different" language with poor tool support? You rely on something else?
For 5 of the targets, debugging directly within the Haxe sources is supported with different VSCode debug adapters (well, JS just uses source maps). If your code is written in a target-agnostic way, you can even switch to a different target with better debugging support temporarily.
Other than that, if really you need to debug some target-specific issue on a target without debugging support, there's usually still the option of debugging the generated code.
oh, I see, thanks! Since I assume you're one of the devs, can you pinpoint also to a direct AST evaluator implementation? Either the obsolete --interp or the new "Eval" interpeter engine :)
I remember thinking that this was a MUCH better language than AS3 for Flash & Flex development. Now, 10 years later, I'm honestly surprised that it still exists and is being maintained.
I'm curious how popular it is at this point? Is there a big benefit over something like Typescript now?
The benefit is that the Haxe compiler can target many more languages than any Typescript compiler. I've never used it, but I've seen some presentations and AFAICT its features and relative maturity (particularly of the overall project and community; i.e. its brain trust) make it a useful piece of technology for some companies making real products. Version compatibility is spotty, but that seems to be because Haxe features and targets are largely demand-driven by whatever product someone is currently trying to design and ship.
For desktop game development it seems better. I don't know if you can use Typescript for GUI applications without Electron or something equivalent. There are some successful modern games that were developed using haxe[0].
There are Electron applications written in Haxe too (via the JS target and Node + Electron type definitions), such as these two level editors for games:
I have not used Haxe, but looked over at it while writing Typescript - one thing I noticed were macros, which could make writing high-performance Typescript/javascript much more bearable. For example iterator protocols in JavaScript almost necessarily allocate memory (especially for user-defined types), but manually writing a for loop does not (but is a bunch of copypasta for a complex data structure).
Haxe macros are very powerful, but not needed for that particular issue - the compiler supports inlining of methods and even constructors (which is useful for iterators in particular): https://haxe.org/manual/lf-inline-constructor.html
Sadly, technical greatness alone doesn’t make a good indicator for lifespan or widespread adoption. And maintaining a relevant evolution path of a programming language alive, with all the compiler tool chain, is a really huge challenge.
TypeScript makes a number of compromises to achieve optimal JS compatibility. Haxe doesn't have this goal since JS is just one of its many targets, and this shows in a number of design decisions (everything-is-an-expression, ADTs and pattern matching, etc).
I work for a company for a company where we are heavily invested in Haxe and have built our platform in it, which we use to create applications. Doing this allows us to target HTML/JS and Unity3D with the same code base for an application. I'm hoping we might eventually release the platform under some kind of open source license, when it matures a bit more.
However at the moment we are struggling a bit to find talented programmers, so if anyone is reading this - knows Haxe well, and wants to work in Copenhagen with a company whose mission is "helping to save more lives" (we take that very seriously and hold that above simply making money) then send me a message ;)
Those are good ideas also! I will probably look into that. I just love the people here on HN so I couldn't pass up the chance to shamelessly post the message here.
Sorry I didn't know if one could send PM's on HN. Send me an email on kristian.erikson@laerdal.com and I'll pass it on to the correct people inside our org. We do have a few remote workers already and I imagine the whole Covid/Corona situation is making us look into this even more :)
Flash/AS3/FAME/Flex is dead but HaXe is still alive. The power of open source.
Too bad it didn't caught on, otherwise those who bet their careers on it got lucky with tech that outlived most of what we had 10 years ago (in that domain).
I have been working with Haxe for over a decade now and the language has really gone from strength to strength in its community and in enterprise use. It's always gratifying to see it appear again, and I know Gama11 (OP) (and many others) have been putting in a lot of legwork for a long time.
Anyone know if there's a way to do sound synthesis on the Haxe platform? Obviously there's a way to do sample playback, and at least some the underlying platforms have ways to do it (web audio, core audio, whatever Flash got version 10), but it's never been clear to me when I check it out if there's an abstraction that can target multiple platforms.
I have a WebAudio implementation for the C++ target (so you can have single API for web and native builds), although it’s planned to be open sourced, it’s currently private but if this sounds useful I’m happy to try to get you a copy before then
Haxe is just great. The language, tooling and even docs has improved much over time, its joy to work with.
I've been using Haxe professionally to create html5 games for almost 6 years now. First started as hybrid solution to have both flash and canvas, nowadays fully webGL powered games with small/clean ES6 output.
I've been using Haxe for many applications; cli tools, generative art, websites, games, backends, tools etc.
Webdevs; There is a full-Haxe react alternative I've been using to create a website, which is called coconut.ui. Since its build with macros under the hood, it can have multiple outputs, which means you can output just its own renderer, but also react (+native), but you can use it to build reactive applications in other framework.
If you use lix (npm/yarn based) as dependency manager, you can require Haxe in CI, which also makes switching versions easily.
Since I've got current pet hobby regarding static compilation (Zig is good friend at this point, the cached static cross-platform output C compiles via musl is crazy good!) I had to look up if Haxe supports this, turns out yes* when targeting C++.
Haxe seems to punch way above its weight, nobody really has anything very mean to say about it and it seems to work great on a ton of different platforms. Supporting all those different targets seems like it should be a megaproject with mega funding and hype, very impressive to do it quietly like these guys have done.
I used it back in 2009 or so and remember the compile times being incredibly fast, it was a joy to use.
This looks pretty neat. How does this work, do you code and specify a target output? Curious if there is a link somewhere that shows the output files ...
I like learned on the front-page example a multi-state (?) switch statement. What is this called and any other languages support this?
It's called pattern matching. You see it a lot in functional languages, not so much in others. Haxe mostly borrowed it from ocaml.
> How does this work, do you code and specify a target output?
Indeed. You can specify multiple targets on multiple builds if your code is compatible with all of them (which happens without too much work when working with libs that do the abstraction for you, like openfl or heaps -- and yeah, that's mostly for games).
It's pattern matching, it's a feature of most functional languages (yes, Haxe is OO, but the language feels veeerrrrry familiar to someone who has used OCaml). Starting to become a more common feature as languages absorb and expose functional-style features (C#, Swift, Kotlin, Rust etc)
That's not pattern matching, it's just switching on arbitrary values. You can do the same thing in d, which doesn't have pattern matching. Pattern matching is something like this:
switch [playerA.move, playerB.move]
case [x, x]: Tied()
case [Rock, x]: Winner(if x == Scissors then playerA else playerB)
[playerA.move, playerB.move] is an array literal value, as are [Rock, Scissors] and the other controlling expressions. The switch simply performs a direct comparison between the two; there need be no destructuring for that to work.
I meant 'how would it work in a language without pattern matching?'
Because it seems to me that it won't. E.g. try this in JavaScript right now with a regular switch statement, it doesn't work. You need actual pattern matching.
It won't work in JS because arrays are compared by reference, so it would always fail to match (I think immutable data structures, at proposal stage 2, would provide one potential fix for this, otherwise need a workaround such as bitmasking the array before performing a match). It not working isn't simply that pattern matching isn't present in the language, per se.
The example is not just destructuring though. It's actually matching against a data constructor and in another branch binding a name to a value. Those are classic hallmarks of pattern matching.
I think it's just pattern matching - Rust example:
let a = "Rock";
let b = "Paper";
let result = match (a,b) {
("Scissors", "Paper") => "A wins",
("Paper", "Rock") => "A wins",
("Rock", "Scissors") => "A wins",
("Paper", "Scissors") => "B wins",
("Rock", "Paper") => "B wins",
("Scissors", "Rock") => "B wins",
_ => "Draw"
};
That's pattern-matching on a tuple, which is common in languages that support destructuring, like Clojure, Scala, OCaml, and other functional programming languages.
I heard some gamedev companies use Haxe to write the logic of the game so that they can transpile it to client side language and server side language. Doing this allows them to simulate the game on server side to check the client side state.
Haxe is truly fascinating and Neko is a great engine as far as I could test. But the language suffers from global scale adoption, not due for the quality but due to the lack of big names representing, I feel.
Fyi, at this point the Neko VM has more or less been replaced by its spiritual successor HashLink (used by games such as Northgard and Dead Cells). It achieves better performance by being a strictly typed VM. It also has better tooling (breakpoint debugging in VSCode, profiling).
I don't think ActionScript <> JavaScript is as important here as everything else about Haxe (full / safer static types, speed, multi-backend, pattern matching, etc.) and Typescript (gradual typing to support idiomatic JS code at the cost of being unsound by design).
If you applied Typescript's philosophy and design to AS instead of JS, you'd get something much closer to Typescript than to Haxe, is what I'm saying.
I've been using both professionally for a number of years, I prefer to use haxe when I can. Strengths of both need to be considered, to give an overview of why I prefer haxe:
TypeScript's main strength is its proximity and integration with js; it didn't seek to reimagine js, but build typing on top of it.
Haxe instead builds strictly typed ECMA language from a clean slate:
- Language features are simpler because it doesn't have to contend with legacy JS (importing a module is just `import X`, strings are always multi-line, `this` means current class etc)
- It's a hybrid functional language, so you can write haxe like you'd write TypeScript, but everything is also an expression, so you can use functional patterns:
// the switch statement is an expression and so evaluates to a value
var message = switch httpCode {
case 404: 'Not Found ($httpCode)';
case 200: 'Success ($httpCode);
case code if (code >= 500 && code < 600): 'Server Error';
default: 'Http Error $httpCode';
}
// even the for-loop is an expression
var array = [for (i in 0...10) i]; // array of Ints from 0 to 9
- Compile-time code execution removes the need for build tools – you can mark functions to execute at compile time, so you can do all your asset processing / DSLs / build-tool-fun as part of the regular compilation. (This is perhaps the biggest win over the traditional web stack for me; I _hate_ web build tools)
- Target other server backends like PHP or Python, which is handy if you're writing a web service and want to use libs from other ecosystems
- The compiler is many times faster
On downsides when compared with TypeScript:
- Is it can be harder to use js-centric libraries like Vue, which make use of JavaScript's `this` behavior in their API design (in contrast to libraries like three.js which are more traditional)
- Haxe does not consume .d.ts files directly but they can be converted to haxe files with the dts2hx tool. This works for many libraries, but isn't yet perfect. For complex libraries like React, it's best to use a hand written haxe-react project (e.g. https://github.com/kLabz/haxe-react)
- Haxe's type system is more strict than TypeScript's, in TypeScript you can perform complex type operations but to achieve the same in haxe you need to use compile-time macros. This is primarily an issue when using existing TypeScript libs which make use of advanced type expressions (which if too complex may become 'any' when translated to haxe)
The company I work for was using Haxe for many years. It was mainly used for a bit of interface code generation, and a cross platform end-to-end test player to test our SDK on AS2/AS3/iOS/HTML5 environments. A lot man hours were saved not have to duplicate those test code on every platform.
Flutter is framework, Haxe is language. There is different Haxe frameworks, but debugging/performance mostly depends on target you choose, and Haxe compiler is pretty good on byte/code generation.
haxe is whole programming language with its own ecosystem and several frameworks for many purposes, such as server side, front end, high performing games, unity engine or unreal bindings, etc. Flutter and Kivy are just other things.
There were a reasonable number of specific things to learn about compilation, packaging and handling things like device rotation, viewport sizes, etc. along the way. But we had a cleanish single codebase for all targets.
Documentation and real world examples were fairly slim on the ground at that point, but it certainly worked and ran well to very well across all devices. It certainly offered a pretty consistent experience across all the targets and ran at a decent framerate on everything we tested against. We couldn't really find much to fault it on once we had everything up and running. I seem to remember compilation times being incredibly fast.
I'm kind of surprised it's still a thing - it brings back some good memories & makes me want to have a go with it again as it was an enjoyable way of working for that type of 2D game project.