Gama11's comments

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)

"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

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

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

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

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

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.

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/

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

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/

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

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

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/

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.

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.

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.

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.

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)