The project would do well to be multiplatform - mobile and web. The obvious choice was flutter and I have enjoyed working with it before.

However, as I’m currently in love with zig, I wanted to work with that instead.

Libraries

Graphics

I’ve been playing with raylib and that was my initial instinct. However, raylib does not support iOs and has issues with wasm

I considered a few options, including

• sdl, which looked great but was perhaps a little too low level for me.
• jok - does not support mobile and possibly has a little more than I needed.

In the end, I decided to go with sokol and sokol-zig.

While a little more lower level than raylib, it has:

• a modern clean api
• first class mobile support
• first class wasm support

UI

I’ve been working with dvui a lot recently. Unfortunately, it doesn’t support sokol. imgui is a better option.

There is even a template project that I could start from.

WASM first

To keep things straightforward, I decided to start with wasm. If I make the site mobile friendly, I could see how it goes and see if it needs a mobile version.

I will need some shared data storage and have been considering supabase, which has javascript libs. By using wasm, I can effectively shim in js functions to handle that instead of having to write bare rest calls from zig.

Structuring the project

Is this a zig project with a web component, vice versa or indeed two independent parts that work together.

I did a fair amount of web searching to see if there was some guidance I could I find for a good way to structure a relatively straightforward zig+js project.

I could not find one. In the end, I decided to keep it fairly straightforward.

Frontend

After a bit of research, and realising that I will probably need a little bit of supporting content around shine, I decided to go with lume

I used the simple-blog theme as a template to start from. I could have just pulled the template in but I wanted a custom homepage.

When I tried to add an index.md, it complained about two files wanting to write index.html. From what I could find, the easiest way to override the homepage was to just pick up the theme and edit it - which was easy enough.

WASM => frontend

I didn’t want to copy over the wasm and the js file every time, so I added a couple of steps to build.zig right after the link_step (also included below)

These steps will copy across the wasm and the js file across to static/shine. I wanted to put the js in src/js and the wasm in the static dir. However, the js file expects the wasm in the same dir. I tried overriding locateFile but it didn’t work.(you can use a different location by overriding locateFile)

I was able to get lume to process the javascript file by adding it.

Conclusion

With all of these set up, I was able to run:

in one window. This command will rebuild wasm and provide it to lume whenever the zig code changes.

Running this in another window will mean that lume will rebuild on any changes, including a new wasm file and redeploy. The redeploy will trigger an auto-reload of the page as well if I have it in a browser.

I now effectively have automated reload with changes if I make changes in either zig or the frontend.

I don’t have hot reload - but this is pretty good for now.

My youngest uncle was a Computing Studies teacher at a local college. He also taught private classes at home. I couldn’t get enough.

I don’t know what most ten-year-olds dream about, but my dream was to learn C. I saved ₹300 - a lot of money in 1994 - to buy a book called Encyclopedia C. I read it cover to cover, understood maybe 10% of it, and reread it years later to pick up more.

But I never actually programmed in C.

The Long Detour

Life took me through a range of other languages instead: Prolog (strangely, what my school machines had), Visual Basic, ASP, PHP, Java, Python, JavaScript, Go, Rust. I tinkered with C++ when messing with game engines, but never quite got around to C.

Some of the early fears carried through - memory management was intimidating: malloc, free, and in C++, new and delete.

Over time, I began to overcome the fear of systems languages - first through Java, then Go. But I never revisited C, and I never quite got over the fear of manual memory management.

In hindsight, these concepts weren’t really designed for a ten-year-old to grasp. It makes sense that they felt out of reach.

Allocator Confusion

Zig had me curious for a while, and some recent health issues gave me the space to explore it. I’ve been building a small game in Zig, and it’s been feeding that original desire to learn C - just with a bit more clarity.

I was still intimidated by memory allocation though, and went as far as I could without using an allocator.

Eventually, I had to use one. I understood the convention of init and deinit, and the idea of allocators in general.

But I was confused about how deinit worked in the context of ArenaAllocator.

A little learning is a dangerous thing

– Alexander Pope

If the arena frees memory for you, wouldn’t calling deinit on individual objects inside it risk double-freeing?

If I skip calling deinit on a struct that normally needs it, will I miss other cleanup tasks?

And does this mean the arena allocator isn’t a true drop-in replacement if I have to skip deinit?

At the time, the answer wasn’t clear - and I couldn’t find documentation that resolved it.

Clarity

Thankfully, the super friendly folk at Ziggit helped clarify things.

ArenaAllocator handles it

ArenaAllocator is a drop-in replacement for other allocators. If you deinit objects using memory from the arena, and those objects try to free that memory, the operation is effectively (though not exactly) a no-op. There’s no risk of double-free.

It’s always safe to free / destroy memory from an arena, as long as you treat it as freed of course. But it won’t actually be released until the arena is deinit’ed.

– mnemnion

Even if some memory is freed manually before the arena is cleared, it’s handled safely.

I was overthinking it.

deinit should still be called

deinit exists for cleanup logic - not just memory. It should always be called where appropriate, regardless of the allocator. That part doesn’t change.

Further learning

Zig also encourages a light touch. One of the impacts of this is that the object itself should not hold on to the allocator in the init and use it in deinit. It could, but the better way would be to accept the allocator in both the init and the deinit.

This convention is further reinforced by zig deprecating the managed variants of collections

Thanks

In many ways, this was about cleaning up more than just memory.

Special thanks to the helpful folks at ziggit.dev.

References

• Full discussion on ziggit.dev
• Implementation of ArenaAllocator