Replace CGO with PureGo and/or an embedded C compiler

[markusbkk]

Just an idea but have you considered switching to Ebiten's PureGo or even shipping something like tinycc?

I only did a proof-of-concept about a year ago but from my cursory inspection building tinycc as a shared object and dynamically calling it through PureGo was blazingly fast in comparison to CGO.

Admittedly, I have no point of reference as to how this combo would perform for larger projects with lots of multiplatform dependencies (tinycc on its own is definitely up to that task, as witnessed by CToy)

[200sc]

A few thoughts:

a. The value add would be mostly for OSX, trusting it works, as that's the only current platform that relies on objective C code.
b. I doubt we would want to ship a compiler, regardless which one, as OSX has a built in C compiler. If you're cross compiling, there's more questions raised by that in terms of how to cross compile / compatibility of compilers, etc. I don't know, but it seems like the end output of that line of work would involve more steps than one currently needs to take to build a project.
c. As ebiten uses it's purego library, and oak and ebiten are both game engines, bringing in ebiten's pure go would make oak more like ebiten. This might be OK, but at the same time it reduces variability in what's out there for use. If oak ends up being very similar to ebiten, and someone wants to weigh which engine to use, they'll use ebiten over oak because it has more numerous maintainers working on it more often.

Fundamentally this is why we have historically not read any ebiten code, or code from any other Go game engine; I'm sure there are lots of great ideas that oak could adapt, but we don't want to just end up building a copy of an existing library.

d. As a minor point, oak tries to minimize dependencies as much as possible.

That said, oak's drivers are extensible, and anyone motivated could build variant drivers using either of these methods, and we'd be more than happy to link to them as alternatives to those built in.

[markusbkk]

b. I doubt we would want to ship a compiler, regardless which one, as OSX has a built in C compiler. If you're cross compiling, there's more questions raised by that in terms of how to cross compile / compatibility of compilers, etc. I don't know, but it seems like the end output of that line of work would involve more steps than one currently needs to take to build a project.

Well. The beauty of (lib)tcc is that it includes JIT functionality as well as optional overflow/memory protections.
It wouldn't be an additional step as long as you shipped the linked library with the rest of the code (I know, that's not an easy ask depending on how many different architectures and OS' you want to support using that strategy).