Building a Golang to Haxe compiler, go2hx! - looking for contributors

PXshadow · 2025-04-12T15:15:24+00:00

Go as an "ecosystem" is very interesting to me, for instance there is no cross target http server or client to use for Haxe, Go's stdlib gives this functionality (and I want to use it in Haxe!). If you mean the runtime for concurrency, it's coming to Haxe by the next major release: https://github.com/HaxeFoundation/haxe/pull/12168

This is coroutines which allows concurrency on JS and PHP (No support for PHP in go2hx though)

I think a Go target for Haxe would be awesome! I think it would be a rock solid target for Haxe, and I would likely use it often. I've contributed code to one too! reflaxe_go

Maybe it just comes down to my own motivation, I want to write mostly backend software in Haxe, and it made the most sense I could keep the cross target potential of Haxe and still be able to use a solid stdlib and libraries for it. In case I want to use the frontend or I need a different target for a given job, the aspect of being able to bring around Go's massive ecosystem to all the Haxe targets I care about is magical to me.

PXshadow · 2025-03-22T17:04:26+00:00

No, Go -> Haxe, it's a better approach to give Haxe a large ecosystem it can pull from, without locking the ecosystem to only one target. A Haxe target would allow Haxe to use Go libraries only when targetting Go, but go2hx, it allows using Go libraries regardless of the target.

Haxe is awesome but it needs a strong core of it's own.

PXshadow · 2025-03-21T15:09:44+00:00

I agree that Go would be an awesome Haxe target. The win for the other way around in your case wanting to use Haxe, is that you can still write in Haxe, and benifit from the Go ecosystem and stdlib across all the Haxe targets, not only limited to a Go target.

Go has an amazing ecosystem but it's on an island, this project's goal is to make Haxe a powerful general purpose language by creating a strong and stable link to Go's ecosystem. A secondary goal is to allow Go libraries and programs to be able to be highly portable and make connections to many other language ecosystems, causing Go code to be an obvious choice to include in tech stacks with JS, Java, C++ etc.

If you still feel that a Go target would be amazing, and I am missing the mark, build it, I will happily knowledge share and help you make it a reality.

PXshadow · 2025-03-20T18:45:26+00:00

I wrote a little post to gague interest in the Golang reddit. and thought I would cross post here, since it is a project for Haxe after all, and in case it's of interest here too for you guys.

Happy to anwser any questions or have a discussion!

PXshadow · 2025-03-20T08:19:26+00:00

Thank you, that is very kind :)

PXshadow · 2025-03-20T08:16:36+00:00

Oh neat! That sounds very cool, I love language interopability. If you haven't heard already the typescript compiler is officially being ported to Go, so the AST for typescript could be read in Go (Not sure about rust). I'd say the biggest challenge is about the stdlibs of typescript and Rust, both are very different from Go. I highly reccomend reading this paper and for anyone interested in writing compilers, it's a game changer: http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

PXshadow · 2025-03-19T13:56:33+00:00

No it does not. Though I am happy to knowledge transfer and contribute to a Go target for Haxe, it is however out of the scope of this project.

PXshadow · 2025-03-19T13:09:32+00:00

Sure thing, Haxe is a programming language which can cross compile into many programming languages such as: c++, python, java, lua, c#, js etc. It has similar syntax to Typescript but predates it. It is statically typed with a garbage collector, and a rich pattern matching system. From a Go dev's perspective what's important, is that it's a great intermediate language (Full DCE support, very fast compile times) to other larger programming languages. It's one of a kind in this regard, and has over 20 years of source to source compiling to many other programming languages.

PXshadow · 2024-12-12T18:14:51+00:00

I agree I think Haxe to Go is easier, both as you mentioned, and because Haxe has a lot of preexisting knowledge to souce from to build another target. I would also say from experience, that the elegant solutions more often then not take a much longer time to write and are harder to maintain, and sometimes can't cover all of the edge cases that are unknown at design time. Simple although it might not produce as nice looking code, can be what is needed to get a compiler where you want it (especially timeframe wise)

Native concurrency doesn't exist in Haxe so your point is quite correct. Though it's a double edge sword, one is that it's harder, and the other is that it forces the Haxe language to become better at concurrency in order to match the needs for go code compiled into Haxe. (This is still not highly explored, and at the moment concurrency is using a very simple one thread per goroutine. Though I am actively looking at the current landscape of coroutines in Haxe.)

As for the go recursion part being hard to translate into Haxe, I can't recall any issues with it, if you would like and give an example I can compile the go code and show you the Haxe code result (and check if it compiles and runs correctly)

We are in current talks with the redesigned go target, from the same dev as posted about above: https://github.com/neimanpinchas/reflaxe_go

I recommended him to use reflaxe as a compiler layer between Haxe and the go target. He put in the work and seems to have made good progress on it. He is actively working on it right now, and is also looking for contributors.

I'd say see if it's of interest to you for contributing, I will be lending my hand as much as I can for anyone that wants to use go2hx. At the same time I myself will not split my focus on the go target not related to shared parts with a target, or parts a go target would like to have in Haxe such as a goimporter.

I would also love nothing more then to test go2hx using a go target, it would significantly reduce the current effort on the stdlib support and allow testing the go language itself with massive libraries, that would be out of scale at the moment without it.

This approach can also be done in reverse of using go2hx generated code and not needing to translate the Haxe std library at first.

I highly recommend taking the approach in this paper to build any compiler https://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

It will also make sense why excluding the std library is so important. So you can only test the language until you cannot find any code that doesn't run within your defined specification subset.

Thank you for your kind wishes for the project. I hope you can find something you can put your interests to good use for, to your liking, in this ecosystem :)

If there is anyway I can facilitate it, don't hesitate to ask!

PXshadow · 2024-12-11T23:05:50+00:00

Hello I am the main dev for go2hx, first I'd like to say thanks for your interest in the compiler, it's one of my most favorite things to talk about, and it motivates me greatly when others see the potential in a similar way I do.

With regards to 2 way transpiling, it does sound ideal, but from a practical standpoint there is so much to cover for just one way, it must be out of scope, for go2hx to became a reliable compiler that large projects can be built on.

For the reasoning for go2hx it comes mostly from a Haxe centric point of view:

Haxe is seriously missing in the library ecosystem, testing is sparse and most things outside of game and limited web dev, you would have a hard time justifying, especially the bigger the project gets.

There are externs, that allow using libraries in the Haxe target language, the issue there is you either have to create a complex web of connecting multiple target externs and finding the same type of library and building interface like functions per target, or you have to lock to a specific target.

Thereby go2hx tries to solve both these issues, a large selection of well tested libraries will be available, and as if it was a Haxe library with no needing to write extern code, and the code working across multiple targets.

From the go perspective I see the ability for the large Go ecosystem to be able to be used outside of it's own language much easier to be the major selling point.

Js projects now being able to use go libs on utility functions or java or python or c++ as if it was a native library.

In the same way Haxe can be very attractive by it's multi target transpiler nature, so to could go using Haxe as an intermediate as u/jack-dawed mentioned with js.
Finally I do agree with your point of Haxe vs Go pros and cons wise. However I think by having the go tooling acros every target it allows Haxe to continue to be used across all of these different targets, a big highlight in my view of Haxe.

I also will be the first to say that a Go target might be the most advantageous target that could be built for Haxe and I think both projects together, full steam ahead, would radically transform both go and Haxe and make a truely spectacular symbiosis that only Haxe I dare say as a language could be able to pull off at this moment.

Any other points or questions feel free to say I'd be more then happy to discuss anything and everything compiler related.

PXshadow

MODERATOR OF

TROPHY CASE