Live data from Hacker News

Haxe 4.2

community.haxe.org

51–60 of 105 posts

Re: Haxe 4.2

#51
post #49

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…

"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

#52

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

Ah, so it is[0]. The GP's example doesn't require pattern matching though; as I mentioned, it would work in a language lacking it.

0. https://haxe.org/manual/lf-pattern-matching-structure.html

Re: Haxe 4.2

#53
post #51
post #49

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…

"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

Oh I’ve got to give that a go!

Re: Haxe 4.2

#55

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?

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/

> - Dead Cells

One of the creators of Dead Cells made a level editor called "LDtk" that has a Haxe API as well

Re: Haxe 4.2

#56

looks better than typescript at first glance

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

#57

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?

ArmorPaint, and it has a beautiful UI

Re: Haxe 4.2

#58

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.

Re: Haxe 4.2

#59
post #10

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

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.

Re: Haxe 4.2

#60

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, view…

You mention only good things about Haxe. Why would you expect it to be gone by now?
Post reply on HN