One of the many yaks! In this case taking memory mapped Vulkan buffers and unsafeing them to various Go arrays and whatnot. I have a gapbuffer implementation on top of this, and then a truly evil "gaptree" implementation that uses gapbuffers to represent a tree data structure.

Do you need to work around Go's escape analysis much? I was under the impression that it's good but not perfect, leading to some heap allocation of variables that wouldn't necessarily need it if they were on C/C++.

I think "good but not perfect" describes my experience here as well. I've certainly needed to rework some bits of code that were allocating when I didn't expect them to, but so far, this has not become too onerous (yet).

The "write a little bit of code, then test it to see if it allocates" approach has been very useful. That way I don't get too far out on a limb with a bunch of allocating code and no easy way to clean things up.

It's actually easier than you might think: Go has most of the capabilities of C, including calling C APIs like malloc/free etc and casting them to Go data types. Of course (like C) writing code in that way won't be particularly convenient or memory safe.

Well, yes and no. My concern was the fact that Go's escape analysis isn't always correct (although it's quite good), leading to variables that would be stack allocated in C/C++, being heap allocated in Go.