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 t…
Haxe 4.2
51–60 of 105 posts
Re: Haxe 4.2
#52Earlier quoted context omitted.
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)
It is pattern matching, the semantics are an OCaml/ML family `match` expression.
0. https://haxe.org/manual/lf-pattern-matching-structure.html
Re: Haxe 4.2
#53I 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 t…
"there’s no equivalent project to DefinitelyTyped" - no, but these days you can auto-convert those TS type definitions to Haxe externs automatically! :) https://github.com/haxiomic/dts2hx
Re: Haxe 4.2
#54Re: Haxe 4.2
#55Does 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?
The showcase page for games [0] is extremely impressive you got some really major indie titles there e.g. - Papers Please - Dead Cells - Northgard - Rymdkapsel - Evoland [0] https://haxe.org/use-cases/games/
One of the creators of Dead Cells made a level editor called "LDtk" that has a Haxe API as well
Re: Haxe 4.2
#56looks better than typescript at first glance
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
- 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)- Smaller code output, haxe performs static analysis optimizations and dead-code elimination (see this example https://try.haxe.org/#4Baa5, taken further here: https://github.com/haxiomic/vector-math)
- 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)
Re: Haxe 4.2
#57Does 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?
Re: Haxe 4.2
#58Does 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?
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.
Re: Haxe 4.2
#59looks better than typescript at first glance
Well yes but it's not the same thing at all. Ecma / JavaScript -> Typescript Ecma / ActionScript -> Haxe 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.
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.
Re: Haxe 4.2
#60We 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, view…