Go2hx Work in Progress

Showcase
21

New month, new update video!

3 Likes
22

go2hx post reflection

Itā€™s been many years since the start of the project. I wanted to give a small reflection on the mistakes made along the way, where itā€™s ended up and what the future may have in store.

Mistakes

  • Too many features, bells, whistles and pre-optimization. A project like this is so hard to not do this on, unless youā€™ve had to learn the lesson the hard way, even if my past self read this Iā€™d do it again, so learn fast, make mistakes and hopefully have someone wiser focus on the concrete mission and ignore everything else.
  • Haxe has haxe.io.Bytes, haxe.ds.Vector, Array, haxe.Rest if you ever need to create custom data types and change between any of these types, do yourself a favor and just pick Array, so much extra code and headaches were caused swapping between these types.
  • Tight iteration cycle is so vital to a project, itā€™s worth the effort to evaluate why itā€™s slow and remedy it as soon as possible. In go2hxā€™s case, it was a 45min CI, more then a minute to compile large packages like net/http and it should have been fixed as soon as it was known.
  • Under plan, over engineer, simplicity wins out in the long run, I spent a lot of time in the start writing lots of code not knowing what the solution would be, I would eventually by trial and error discover it, but the resulting code would be hideous. Now I plan out a given feature and how it should look design wise before I code it up, when I code it, I constantly clean it up, while testing to make sure it matches the exact behavior I want. It takes at least 2x as long, but it pays off in the long run.
  • Haxe macros are glorious but also are black boxes and should only be relied on for small improvements (from expr macros for example), large scale init or build macros are asking for trouble. Trust me I built an entire type system with init macros, I know the power, but I also know how much of a nightmare it was to yank it out and how much simpler it got, once I was rid of it.
  • Dogfooding was talked a lot about in the project but was hardly done, this left the interoperability of Haxe and Go code as an after thought and the dev experience in a rough spot. A feature such as interoperability must be prioritized and actively used in the project. The best way for others to use your project is for it to be so good that they want to tell others about it.
  • Caring about the time it took and the ideals. At the end of the day itā€™s the projectā€™s design and current use that really matters. Show real use cases, use it yourself, and donā€™t be dishonest with yourself of the current stage.
  • Building Solo, if you want to create a project that grows into a community, then you should be thinking how to attract talent and make it worthwhile for them to take ownership and build cool things with you, giving up a level of control, in particular on ā€œno questions askedā€ decision making is required.
  • Under ambitious, go2hx had an ambitious vision but it didnā€™t match in many of the decisions. For example the Go version was locked for 3 years, target testing was scaled back, interoperability was open ended and left for future ā€œtestersā€. These decisions made sense with the constraints, but I didnā€™t question why those constraints had to exist in the first place.
  • Future planning, I spent way too much time future planning of what Go libraries I would compile, and what systems I would eventually integrate, and if there was interest in X Go library. It was a time sink and made the development much slower. This phenomenon seems the same to me as creating a list of future books to readā€¦ it will take 2 weeks to finish the one you have, you donā€™t need to spend 2 hours creating a book list when you might be interested in a book not on the book list after finishing the current one. Being adaptable and at the same time steadfast is vital.

I hope the above is not too off topic, I think as a community we are inclined to chase compilers and really hard daunting problems. I hope my mistakes shared openly might nudge one or two of you, to join up with others, ambitiously, over plan and under engineer the next great Haxe project (while using it yourselves).

I went from 0 understanding of compilers when I started this project to standing here with just a little more. Iā€™ve met unbelievably talented developers here, and itā€™s been such a joy, to share, build and hear all the awesome changes in this quite tight nit community.

Iā€™d also like to thank Elliott Stoneham, who I never wouldā€™ve gotten this far without his constant unwavering support week in and week out. Itā€™s been an honor to follow in his footsteps and I stand on his outstanding work alongside the Haxe contributors and library maintainers.

Where it ended up

The Go standard library net/http being used to run a web server in Haxe on hashlink. (also supports SSL)

Possible future

Whatever I do in the future, I want to build with others. Haxe is rare that it has such an open community with at the same time such dense talent. Iā€™d like to leverage that, and work on something together that fundamentally makes Haxe more awesome to use.

14 Likes
23

FWIW, I would think that a Go backend (even a macro powered custom target) might be a better approach here, assuming you can find a neat way to embed Go semantics into Haxe.

There are two advantages to this:

  1. Thereā€™s an additional Haxe backend \o/
  2. You can use Go tooling to get this done, which I guess gives you a number of options:
    1. Write Haxe to generate Go code that essentially works like gopherjs (using go/parser, go/token and go/types and what not to deal with Go). Takes in Go code, spits out Haxe - could initially just start with generating externs, later generate code.
    2. Write Haxe to generate Go code that you would integrate with the compiler more directly (the most hamfisted version would be to just fork).

Dunno. Maybe Iā€™m just being naive here, but it sounds less ambitious than having to reimplement half the Go compiler in Haxe.

In any case, really nice project. Youā€™ve accomplished much :wink:

4 Likes