[HN Gopher] Haxe 4.2
___________________________________________________________________
Haxe 4.2
Author : Gama11
Score : 103 points
Date : 2021-02-09 21:02 UTC (1 hours ago)
(HTM) web link (community.haxe.org)
(TXT) w3m dump (community.haxe.org)
| ncmncm wrote:
| I can't tell from the project page whether this is an obligate-GC
| language.
| Gama11 wrote:
| It is. On targets such as C++ where there's no native GC, Haxe
| brings its own (via hxcpp in this case:
| https://github.com/HaxeFoundation/hxcpp).
| tracker1 wrote:
| IIRC, Haxe is kind of a meta language that transpiles through
| different language/targets. IIRC, mostly GC, yes.
| myth_drannon wrote:
| 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).
| artemonster wrote:
| 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?
| Gama11 wrote:
| 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.
|
| https://github.com/vshaxe/vshaxe/wiki/Debugging
|
| 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.
| artemonster wrote:
| 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 :)
| Gama11 wrote:
| The eval implementation is found here (evalMain.ml is the
| entry point):
|
| https://github.com/HaxeFoundation/haxe/tree/development/src
| /...
| ohazi wrote:
| Apparently I've been confusing Haxe with Facebook's Hack/HHVM for
| years, and just assumed it wasn't something I'd be interested in.
|
| But this... actually looks pretty neat!
| jsight wrote:
| 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?
| wahern wrote:
| 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.
| pjmlp wrote:
| Multiple compiler backends.
| dummy_physicist wrote:
| 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].
|
| [0] https://haxe.org/use-cases/games/
| Gama11 wrote:
| 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:
|
| - LDtk: https://ldtk.io/
|
| - Ogmo 3: https://ogmo-editor-3.github.io/
| joppy wrote:
| 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).
| Gama11 wrote:
| 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).
| christoph wrote:
| 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.
| [deleted]
| Kapitan_Bomba wrote:
| looks better than typescript at first glance
| keyle wrote:
| 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.
| Gama11 wrote:
| 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).
|
| https://hashlink.haxe.org/
| colechristensen wrote:
| 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?
| user1234567890 wrote:
| 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
| mrisoli wrote:
| 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.
| johnfn wrote:
| It's been used to make a number of popular games - Dead Cells
| and Northgard come to mind, and I think there is a decent
| number more.
| conanbatt wrote:
| Dead Cells was made on Haxe? Wow
| larsiusprime wrote:
| Also BrawlHalla on consoles
| pier25 wrote:
| Papers Please too.
| wishinghand wrote:
| I don't know about your latter question but the devs who made
| the game Dead Cells used Haxe for it.
| ljm wrote:
| Those devs have gone on to write a good series of tutorials
| and a pretty swish 2D level editor https://ldtk.io/
| k_ wrote:
| Some not-so-tiny games as cited in sibling comments. Also some
| web applications; I've been pushing some to production for 6
| years now.
|
| Other random uses:
|
| - lua target for a pokemon game, probably for scripting (no
| word from devs, just saw the licences)
|
| - a video player made by feds to catch pedocriminals a couple
| years ago
|
| - livejasmin (warning: NSFW!) is using it for its frontend (via
| docler holding) on a top 50 website
| 01100011 wrote:
| TiVo used it to reimplement their UI after moving away from
| Flash. No experience programming it, but it seems like a mature
| product.
| disqard wrote:
| 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.
|
| [0] https://www.blockstud.io
| xyproto wrote:
| Haxe 4.2 is available in Arch Linux now.
| harporoeder wrote:
| 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.
|
| 1: https://haxe.org/documentation/introduction/compiler-
| targets...
| jzer0cool wrote:
| 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?
|
| switch [playerA.move, playerB.move] { case [Rock, Scissors] |
| [Paper, Rock] | [Scissors, Paper]: Winner(playerA);
|
| ...
| k1t wrote:
| 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" };
| kornish wrote:
| That's pattern-matching on a tuple, which is common in
| languages that support destructuring, like Clojure, Scala,
| OCaml, and other functional programming languages.
| involans wrote:
| This is pattern matching. Support for this exists in Haskell,
| Scala, and now even Ruby and soon Python.
| k_ wrote:
| 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).
| RobertKerans wrote:
| 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)
| moonchild wrote:
| 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)
| RobertKerans wrote:
| It is pattern matching, the semantics are an OCaml/ML family
| `match` expression.
| johnday wrote:
| 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.
___________________________________________________________________
(page generated 2021-02-09 23:00 UTC)