Probably one of the toughest part of maintaining GopherJS is that you have to run pretty fast just to stay in one place... There is a new Go release every 6 months and if it includes new language features, we have to find a way to support them. And only then we may have a bit of time to improve on the project itself, which is kind of stressful.

For the past 4 month I've been plugging away on generics support and I think there's only one major unimplemented feature. And a fair amount of bugs to fix. And by the time I'm done, adding Go 1.19 and 1.20 support will be due...

A funny thing about GopherJS that took me a while to figure out: struct data is actually stored in what is technically a runtime representation of a pointer-to-struct type, and the struct object itself almost never exists 😲

You'd say, but wait, no way it works without structs, surely they do exist and are represented by a plain old JavaScript object. Well, sort of. In reality, there is a pointer to a struct type that is represented by a JavaScript object. So when you write something like this:

type S struct { f int }
s := S{} // ← non-pointer type!
ptr := &s
reflect.TypeOf(s)

...it translates into something similar to:

var S = $newType(...., function() { this.f = 0 })
var s = new S.ptr()  // ← actually uses pointer constructor!
var ptr = s; // ← noop, it's already kind of a pointer.
reflect.TypeOf(new S(s))  // ← adds a wrapper with the correct type information when interfaces get involved.

This is counter-intuitive, but also makes sense because JavaScript's pass-by-reference semantics for objects is a lot like a pointer in Go, and GopherJS actually has to take extra steps to emulate value type semantics on top of it.

Before I became a GopherJS maintainer I had no idea how incredible of an achievement that would be: https://mastodon.social/@andrewrk/109621905821062620

Growing an active contributor community is hard. Even harder when it comes to folks willing to do the unfancy, grindy work such as triaging old issues — very few people consider it an enjoyable leisure activity, or are willing to do it regardless of not being paid. So hats off to the Zig authors for getting there, I'm sure it required a lot of persistence.

As for GopherJS, I am truly delighted that virtually all changes that went into 1.18.0-beta2 release came from contributors outside of the core maintainer group. Many of them are non-trivial too. We are still struggling to find volunteers for recurring tasks such as new Go version support, but hey, hopefully we'll get there.