Hot code swapping will be huge for gamedev. The idea that Zig will basically support it by default with a compiler flag is wild. Try doing that, clang.

Totally agree with that - although even right now zig is excellent for gamedev, considering it's performant, uses LLVM (in release modes), can compile REALLY FAST (in debug mode), it has near-seamless C integration, and the language itself is really pleasant to use (my opinion).

Is Zig actually being used for real game dev already?

here's one: https://store.steampowered.com/app/2156410/Konkan_Coast_Pira...

Visual C++ and tools like Live++ have been doing it for years.

Maybe people should occasionally move away from their UNIX and vi ways.

>Maybe people should occasionally move away from their UNIX and vi ways.

Maybe when something better comes up, but since you never invested one single minute on improving Inferno we have to wait for another Hero ;)

Yes, at a huge cost. That only works on Microsoft platforms.

MSVC++ is a nice compiler, sure, but it's not GCC or Clang. It's very easy to have a great feature set when you purposefully cut down your features to the bare minimum. It's like a high-end restaurant. The menu is concise and small and high quality, but what if I'm allergic to shellfish?

GCC and Clang have completely different goals, and they're much more ambitious. The upside of that is that they work on a lot of different platforms. The downside is that the quality of features may be lower, or some features may be missing.

I ended up switching from Zig to C# for a tiny game project because C# already supports cross-platform hot reload by default. (It’s just `dotnet watch`.) Coupled with cross-compilation, AOT compilation and pretty good C interop, C# has been great so far.

Why more games aren’t being developed in lisp is… perhaps not beyond me, but game development missed a turn a couple times.

That is basically what they do when using Lua, Python, C#, Java, but with less parenthesis, which apparently are too scary for some folks, moving from print(x) to (print x).

There was a famous game with Lisp scripting, Abuse, and Naughty Dog used to have Game Oriented Assembly Lisp.

I had exactly the same title in mind, remember my very young self being in shock when I learned that it was lisp. If you didn't look under the hood you'd never be able to tell, it just worked.

This is already such a huge achievement, yet as the devlog notes, there is plenty more to come! The idea of a compiler modifying only the parts of a binary that it needs to during compilation is simultaneously refreshing and totally wild, yet now squarely within reach of the Zig project. Exciting times ahead.

Ultimately, this will be determined by the scope of the project, and depends on whether you count using an existing C library as part of the Zig ecosystem.

If you want Zig libraries that don't call any C/C++ code whatsoever, then you're going to have a hard time (as of 2025). There's not, e.g, something as mature and tested as glfw in pure Zig. There is work being done to make pure Zig libraries for gamedev however, see for example Mach: https://machengine.org/

If you're happy to use C libraries though (as I am), then things are generally fine. Many of the most popular gamedev C/C++ libraries have already had their build systems converted into Zig (e.g. Raylib) and so can easily be added to a project without having to do any work in the build system.

For C libraries that aren't already packaged, or if you want to maintain full control of the build yourself, packaging libraries with the Zig build system isn't too bad, but it's still a lot of work. (E.g. Ghostty maintains its own build files for its packages; as a result there is a lot of Ghostty build system code: https://github.com/ghostty-org/ghostty/tree/main/pkg )

My game has a bunch of strings, and my string code currently looks very different to this! For example, copying two lines from source:

  var buffer : [64] u8 = undefined;
  const level_name_cstring : stringnt = std.fmt.bufPrintZ(&buffer, "{}. {s}", .{icon_index + 1, level_name}) catch unreachable;

(Make the string "10. Fortress" from the int 10 and "Fortress")

The reason is, most of the strings in my game are bounded, and actually, known ahead of time. None of the levels have names that approach anything as long as 64 bytes, so I can actually do a fair bit of string manipulation on the stack before needing to use / save it to an allocator. (At least for now before localization XD)

So it depends on the use case. Sure, string manipulation in general can be tiresome in Zig, but in many cases it's also simple.

Isn't `unreachable` in Zig like in C? So very bad things can happen if you overflow.

This sort of code makes me nervous about Zig.

In safe build modes (ReleaseSafe or Debug) it's an immediate panic, equivalent to calling `.unwrap()` on a None in Rust. In unsafe build modes it's undefined behavior.

Well exactly.

For my (relatively simple) use cases, I've had a significantly better time using comptime than templates; the syntax and the quality of the error messages are a lot simpler in Zig. While I've never attempted to do anything super fancy with templates in C/C++, my gut feeling is that comptime can provide most, if not all, of functionality that templates provide. (But C/C++ template experts please chime in if this is not the case.)

Former Cpp dev here. If I never have to debug a template barf it'll be too soon. By the end of my time in C/Cpp land I'd written more C than anything, with occasional "structs with con/de-structors". Happily the next gen of systems languages fit about in that niche already!

You're welcome! My experience with the breaking changes in Zig has not been bad at all. For brevity in the blog I didn't get into what I had to do to get things working again, but the process itself was straightforwards. Sometimes the names of some standard library functions had changed, sometimes it was some extra fields in the build system. Whatever the case, the changes were almost always documented in the release notes anyway, so after reading the release notes I basically knew the (small) amount of work I had ahead of me.