Go2hx Work in Progress


A Go to Haxe transpiler and spiritual sucessor to the Tardisgo project with notable design improvements.


  • AST instead of SSA types that allows much nicer looking final generated code, and less overhead.
  • Haxe focused/maintained, example: low level parts of the Go’s standard library is being written by hand, in Haxe (os,fmt,math etc)
  • Haxe has improved immensly since 2016, specfically for this project: unicode support, rest arguments, module level functions etc.
  • Language features in Go and not in Haxe are supported via macros such as multireturns, defers, gotos, pointers etc.

Current state:

  • Can generate all expressions/statements, except one’s releating to goroutines
  • Able to run simple scripts that use parts of the standard library that are written.
  • About 8% of the low level std is written in Haxe now.
  • Macro language features, most are working and some need improvements.
  • Very much a work in progress and still requires much more tests to pass before it can begin taking shots at full Go libraries.


  • 20 times the amount of Haxe libraries across all Haxe targets.
  • Make Haxe much more competitive as a server sided language.
  • Clean and fast exucting generated code.
  • full acess to the Golangs test suite, thereby transpile the tests and test them in Haxe
  • Ease of use following dts2hx’s example.

So you may be asking what does the code generation look like? Something like this:

Most of the remaining work will be in Haxe either by writing parts of Go’s standard library, or tweaking and working on macros,

If that sounds interesting to you I’m very much looking for devs to work with this on, feel free to contact me (here/discord/etc).

Super big shout out to the Haxe compiler team, this project could not have been possible to make a year ago and am fully indebeted by the amazing strides you guys have taken.

Cheers and to a year of Haxe in 2021


Whoa, this is very impressive! Definitely going to check this out!

1 Like

Have you compared output code size and performance to gopherjs?

1 Like

Thank you so much! I have done comparison of output size for gopherjs vs go2hx, it’s pretty striking how insanely massive gopherjs here is the output:

  • gopherjs: 1080 kb, 20k loc
  • go2hx: 4kb, 158 loc

This is what Gopherjs wrote on code size here:
" Why is GopherJS generated code so big?

GopherJS reimpliments most of the Go runtime in Javascript, so that’s a start. A lot of things import the fmt and reflect packages, which represents a sizable chunk of code. In general, GopherJS code is so large for reasons similar to the reason Go executables are so large: they’re statically linked. In the Go case, literally; in the GopherJS case, metaphorically speaking, but the idea is similar."

Haxe’s DCE seems much stronger then gopherjs’s and the design diffrence of writing the low level part of Go’s std greatly minimizes the code size as well. I have not dealt with inputted go code using reflect yet so that may throw a wrench in DCE, however I’m sure macros can fill the gaps and explicity set to keep fields and classes.

As for performance, I have not tested it out against gopherjs yet, if you have any benchmark tests let me know. I think gopherjs will be more comparable performance wise the more mature go2hx gets, such as comparing coroutines, http requests, json encoding etc.


Cool stuff! It would also be nice to have golang as a haxe target:)

1 Like

It would be nice to have a golang target I agree. Go’s assembly table generation is very neat and it would be amazing to easily produce one file executables for Haxe on all operating systems.The down side with only doing that approach is target locking the libraries to Go, and having a target that doesnt have that great of a c bindings system performance wise, witch would hinder thing such as haxe’s future use of libuv. If there’s anything else I’m missing let me know :slight_smile:

this is transpiler haxe to go
or go to haxe?

The latter, it converts the go programming language into haxe code.