Take a look at Nim and Nimler if C and linking seems too intimidating. Nim is much easier to learn than Rust but still provides memory safety by default. It’s become my default for NIF’s since it’s new GC plays well with BEAM. Glfw might require some fiddling with linking but the forums are helpful.

Edit: actually the nimler docs is probably better than its github: Getting started - nimler

Plus, Nim has been used in a few moderate sized games. There’s decent OpenGL libraries like NimGL or nim glfw. Or a cool looking 2d library, pixie.

Happy hacking!

P.S. If you use long running NIF’s they’ll need to be marked as “dirty nifs”. Also I wouldn’t worry upfront about killing beam, it’s just that we get used to the beam rarely ever dying. It sounds like you’re interested in local ui stuff anyway.

yielding currently works as of 0.7.2, . the api changes are between 0.7.0 and 0.7.1, and the updated niceties coming in 0.8.0 are separate things. I don’t expect the yielding API to change moving forward, except to support interrupting threaded nifs too. If you’re curious as to how it works:

The entrypoint functions start at line 105, the async function is line 159

Ability to seamlessly swap between yielding, sync, and threaded depends on the fact that zig has colorless async functions.

beam.yield function is here: zigler/beam.zig at master · ityonemo/zigler · GitHub

tl;dr - launcher function sets up a frame (heap-allocated memory space for an async function + its stack) inside of a BEAM resource, then it launches the function, inside of an event loop, watching for the 1 ms time limit to elapse. If you get close to exhausting the event loop’s 1ms requirement, intead of resuming the async function, it calls the BEAM nif ABI “reschedule a tail-call” function, passing the resource along as an artifact. On reentry, it accesses the resource and obtains the frame pointer and is able to resume the async function. If you kill the parent process, it triggers garbage collection of the resource, which is set up with a hook to resume at the beam.yield point, except signalling an error, which triggers any defer statements in the zig as usual.

Also importantly, strategic use of threadlocal variables are necessary to allow for ‘global’ information exchange.

Fair. As a preliminary spoiler alert: in C it’s trivial to allocate a memory buffer of 10 bytes and then try to get a value from the 11th element. This, oversimplified, has been the reason for most of the security fiascos in the last several years.

Rust prevents those.

Just FYI you do have full access to OpenGL from elixir already today. Have a look at the wings3d project. It’s an OpenGL based 3d modeller written in Erlang http://www.wings3d.com/

Source code: GitHub - dgud/wings: Wings3D is an advanced sub-division 3D modeller.

I had looked at wings (was surprised the forum still seems to be active), and also scenic that uses GLFW too, but got a bit overwhelmed on how to start/work the c part like from easy mode and build from there as that’s how I learn better. I will certainly look into them for inspiration.