Gama11 · HackerTrans

Gama11

no profile record

Submissions

Haxe 4.2

community.haxe.org

279 pointsby Gama115 tahun yang lalu102 comments

Haxe 4.1.0 is released – JVM target, improved exception handling, TRE

9 pointsby Gama116 tahun yang lalu0 comments

Introduction to the technology stack used at Shiro Games (Evoland, Northgard)

2 pointsby Gama116 tahun yang lalu0 comments

Flash in 2020 (and Beyond)

community.openfl.org

22 pointsby Gama116 tahun yang lalu1 comments

10 years of evolution together with Haxe

2 pointsby Gama117 tahun yang lalu0 comments

Haxe Review: Haxe 4 Features and Strengths

7 pointsby Gama117 tahun yang lalu0 comments

Getting Started with Haxe

jeremymorgan.com

1 pointsby Gama117 tahun yang lalu0 comments

comments

5 tahun yang laludiscuss

I work with Kotlin at my day job but am also active in the Haxe open source community. I really like both languages, and I don't think that Kotlin is objectively better than Haxe.

In practice, there are things about Haxe I miss in Kotlin, but also things about Kotlin I miss in Haxe. Just to name a few examples:

- I'm missing Haxe's pattern matching and macros in Kotlin

- I'm missing Kotlin's level of IDE support and robust null safety (with ?: and ?. operators) in Haxe

(Haxe does have experimental opt-in null safety, but it doesn't seem production-ready yet)

5 tahun yang laludiscuss

"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

5 tahun yang laludiscuss

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

5 tahun yang laludiscuss

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

5 tahun yang laludiscuss

The eval implementation is found here (evalMain.ml is the entry point):

https://github.com/HaxeFoundation/haxe/tree/development/src/...

5 tahun yang laludiscuss

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.

5 tahun yang laludiscuss

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/

5 tahun yang laludiscuss

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

5 tahun yang laludiscuss

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/

7 tahun yang laludiscuss

That is a good point, a mention on the Neko website would make sense.

7 tahun yang laludiscuss

No worries, just wanted to clear up the misconception. :)

7 tahun yang laludiscuss

The "HashLink in-depth" blog post talks about this, an excerpt:

> [...] Neko is very slow. The main reason for this is that it's dynamically typed. So every "value" in the VM can be either an Int, a Float, a Bool, some Bytes, an Array, a Function or Object, etc. And because this value needs to be recognized at run-time, its type together with its data need to be stored in the memory. [...]

https://haxe.org/blog/hashlink-indepth/

7 tahun yang laludiscuss

There's actually VSCode debuggers for a lot of Haxe targets by now: HashLink, JavaScript [1], C++ (HXCPP), Eval (the compiler's macro interpreter) and Flash. See https://github.com/vshaxe/vshaxe/wiki/Debugging.

[1] Though in JavaScript's case, there isn't really anything Haxe-specific about it, it just uses sourcemaps generated by the compiler like other languages compiling to JS.

7 tahun yang laludiscuss

Haxe is hardly a "scripting language", at least according to my definition of that term. It's a strictly typed high-level language with a proper optimizing compiler. Depending on the target it produces either bytecode (Neko, HashLink, Flash and recently JVM) or source code (C++, JavaScript, Python, Lua, C#, Java, PHP).

See https://haxe.org/documentation/introduction/compiler-targets... for a full list of targets.

7 tahun yang laludiscuss

Haxe's JavaScript target works great in combination with Node as well though. :) (https://github.com/HaxeFoundation/hxnodejs)

For instance, the Haxe VSCode extension itself is a Node project written in Haxe.

7 tahun yang laludiscuss

Neko isn't that fast, since the bytecode is dynamically typed. That combined with the fact that it's not really actively developed anymore, you'd probably be better off checking out its successor called "HashLink" instead (see comment thread above).

Btw, a JVM target (generating JVM bytecode directly) was recently merged into the Haxe compiler. Previously there was already a target that generates Java source code, but that had some issues like slowing down compile times with the native Java compilation step that needed to be done.

7 tahun yang laludiscuss

I'm also surprised that Neko has been posted here rather than HashLink, which is much more impressive:

- unlike Neko, the bytecode is strictly typed, allowing it to be much faster

- there are two different ways to use it:

  - HL/JIT, compiling to bytecode and using the VM

  - HL/C, compiling to raw C code to gain an extra bit of performance and allow it to run on devices that don't allow JIT (mobile / consoles)

- the successful indie games Northgard (by the Haxe / HashLink creator himself) and Dead Cells use HashLink as their runtime

- there is a VSCode breakpoint debugger for it (https://marketplace.visualstudio.com/items?itemName=HaxeFoun...)

- in the future, support for hot-reloading bytecode is coming (https://github.com/HaxeFoundation/hashlink/issues/145)