https://hachyderm.io/@Mara/111357549294998960 gave me a good chuckle.

It also reminded me of a thing that I never really considered until I started contributing to : a += b and a = a + b are not semantically equivalent statements. In the former a is evaluated only once, and in the latter twice. That doesn't matter when a is just a variable, but if it includes a function call with side effects the double evaluation may cause all sorts of havoc.

in reply to this object

Also, it's written in Go and . One of those days I should try and compile it with . I know that around Go 1.11 days Ebitengine actually used to support GopherJS, but when GopherJS development fell behind, the support was dropped. Might be cool to bring it back.

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.