Zig: hot code swapping

[andrewrk]

• Have the compiler run continuously, watching the file system for source
  changes and automatically perform multithreaded compilation to build projects
  quickly.
• Hot code swapping. When integrated with the previous feature, you could
  press "save" in your editor and see the change immediately in your running
  software.

Of course this only works for some kinds of changes - obviously if you make changes to your initialization code, you won't see a difference. But it would probably work at the function level, so you could swap out any individual function for a new one.

[PavelVozenilek]

This feature (automatic rebuild in background & hot code swapping) is available for C++ in Projucer IDE, built upon LLVM infrastructure.

Old demo 1, old demo 2, few implementation details.

Be aware that it took several years to implement and the implementor said that "it was the most complicated thing I ever did".

[0joshuaolson1]

@PavelVozenilek The Projucer link has died, sadly.

[PavelVozenilek]

Information from the dead link is probably here:
https://forum.juce.com/t/demo-screencast-of-the-projucer/9218
and here:
http://web.archive.org/web/20130808104856/http://rawmaterialsoftware.com/viewtopic.php?f=2&t=9794

[ccll]

I always wonder how should hot-swap deal with data (data structure layout and long-lived in-memory state), it seems rather difficult compared to hot-swap stateless code (like a pure function).
In some languages which support closure, it's even more complicated.
Are there any articles on this subject?

[isaachier]

@ccll that is the biggest issue. Doing it in C/C++ is currently possible using a dynamically loaded library. See this blog post on the topic.

[themagnet]

here https://molecular-matters.com/products_livepp.html is a commercial product which realizes hot-reload for c/c++ projects

[jaccarmac]

I wonder if looking at the way Common Lisp deals with these things would be useful at all. Sure, CL has a fatter runtime than Zig at the binary level, but:

1. If there is a watcher like @andrewrk hints we could possibly have it keep track of the old structure of the code it is watching.
2. CL contains a full-blown object system and is able to manage updating all live instances of a CLOS class. Updating structs would be comparatively simpler, size changes might be the hardest part to deal with?

[ccll]

@isaachier Thanks, that article is very helpful!
I can see it passes a DLL-specific 'game_state' around, but what if the layout of 'game_state' got changed between reloads? I can imagine there will be lots of crashes/segfaults/misbehavior.

Now i've integrated C live coding successfully with libtcc, which hot-swap pure code flawlessly.

About the state transition, I can think of a solution which serialize the state out (to a layout-agnostic format), allocate new state, then serialize in. It should work, but involves a lot of manual implementation of serializing code and is not very generic/automatic.

[pgruenbacher]

https://github.com/nim-lang/Nim/issues/8927
Nim seems to have this implemented as a reference.

[pixelherodev]

Regarding code swapping in C, see https://github.com/fungos/cr

[cshenton]

This would be a killer feature for me in game dev. Commercial game engines (Unity/Unreal) tend to implement their own hotswapping layers for engine code or rely on scripting languages to get iteration times down.

To have this supported at the language level would definitely reinforce the "so productive you have to use it" narrative for zig in games.

[Alkeryn]

@cshenton
One of the possible thing you can already do in C and C++ and probably in zig as well is have most of your core logic into a dll / so file and having the program check for it and reload it on change in the debug builds.

It isn't "native" hot code reloading supported into the language, but it allow for a similar workflow
as an example : https://youtu.be/LNRfbZlppLo?t=60

altough it isn't the same as if it was builtin and it would be great if it was, you might find it useful !

Hoping this wasn't a necrobump.