Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C and C++ Hot-Reload/Live Coding

liveplusplus.tech

Post reply on HN
Print view View original

21–30 of 102 posts

Re: C and C++ Hot-Reload/Live Coding

#21

Post by cangeroo »

mjburgess wrote: post #6

fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading ). It's a sign of how bad developer tooling has been that live reload is sold as an add-on feature. DX seems always to see-saw between bill gate's c. 1990 demo of VB, and the compile-time speeds of a N' Wirth. At a guess, when the internet happened, all DX had to be thrown a…

One problem is that modern software architectures are highly coupled and stateful, such that it isn't possible to hot reload a component. It would require the host (e.g. when using a DLL) to detect a change, save state, unload, reload, load state. Multi-threading may also make things more difficult, requiring more synchronization during changes.

I agree with your sentiment, but it's really hard to communicate it to the younger generations. I suppose it comes off as being negative, but it's really just melancholia over the loss of something that was fun, simple, and powerful.

Re: C and C++ Hot-Reload/Live Coding

#22

Post by hyperhopper »

vodou wrote: post #20

Maybe I'm just old and grumpy, but the subscription business model just puts me off. Nowadays when I read about some development tool (or just any product), I start with the price page. If there are only subscriptions available I stop reading and go on with my life.

No, totally reasonable not wanting to spend your whole life financially beholden to everybody you've ever done business with. "you will own nothing and be happy" is sadly becoming true, as you have pretty much no Rights for any digital and more of the world is becoming digital.

When people ask why I don't like copilot and want a worse alternative when copilot "pays for itself", it's not because I don't want to pay, I just want to buy something and have it.

Re: C and C++ Hot-Reload/Live Coding

#23

Post by jasonlotito »

kleiba wrote: post #18

In one of the earlier episodes of the Handmade Hero series, Casey Muratori writes a hot-reloading functionality for C from scratch in about an hour (while giving detailed explanations of what he's doing). The following two episodes then improve upon the initial results. https://www.youtube.com/watch?v=WMSBRk5WG58

I was thinking the same thing when I saw this. Thanks for finding the video! His early stuff is especially good.

Re: C and C++ Hot-Reload/Live Coding

#24

Post by mananaysiempre »

kleiba wrote: post #18

In one of the earlier episodes of the Handmade Hero series, Casey Muratori writes a hot-reloading functionality for C from scratch in about an hour (while giving detailed explanations of what he's doing). The following two episodes then improve upon the initial results. https://www.youtube.com/watch?v=WMSBRk5WG58

On one hand, I appreciate Muratori showing that loading code into your program dynamically isn’t actually difficult. On the other, the hard part of general hot reloading on systems that have tried it (from Smalltalk to VC++ Edit-and-Continue) is migrating obsolete state—or at least reliably telling the user when you can’t, so as to avoid leaving them to debug a mad world that could never be encountered in a fresh run. As far as I remember, Muratori basically does not touch on that at all.

Re: C and C++ Hot-Reload/Live Coding

#25

Post by mjburgess »

foooorsyth wrote: post #19
mjburgess wrote: post #6

fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading ). It's a sign of how bad developer tooling has been that live reload is sold as an add-on feature. DX seems always to see-saw between bill gate's c. 1990 demo of VB, and the compile-time speeds of a N' Wirth. At a guess, when the internet happened, all DX had to be thrown a…

>I support being paid for your work, but live reload is a fairly trivial thing to write for yourself -- I spent one day this gone weekend writing a debugger in C which does it. Major Dropbox “who would pay for this over just using rsync?” vibes here. Never change, HN.

unlike the dropbox case, my point isnt, "oh go and do it yourself" -- my point is why-t-f doesnt gcc/clang, etc have a obv-build-tool --live-rebuild option?

Or, more alarmingly, why are things like jrebel fawned over? Rather than, say, it being an embarrassment that java dx is worse than programming dx 30-40 years ago?

Why isn't the basic thing all OS do, ie., live reloading of code, a day-to-day essential element of all development?

I really don't know. But to be clear, it was 50+ yr ago, 40+ yr ago, 30+ yr ago --- and as of today, it's $100/yr subscription (lol?!)

Re: C and C++ Hot-Reload/Live Coding

#26

Post by mananaysiempre »

hyperhopper wrote: post #22
vodou wrote: post #20

Maybe I'm just old and grumpy, but the subscription business model just puts me off. Nowadays when I read about some development tool (or just any product), I start with the price page. If there are only subscriptions available I stop reading and go on with my life.

No, totally reasonable not wanting to spend your whole life financially beholden to everybody you've ever done business with. "you will own nothing and be happy" is sadly becoming true, as you have pretty much no Rights for any digital and more of the world is becoming digital. When people ask why I don't like copilot and want a worse alternative when copilot "pays for itself", it's not because I don't want to pay, I…

> I don't like copilot and want a worse alternative [that can be used in perpetuity]

There’s replit-code[1], which is pretty much that I think.

[1] https://huggingface.co/replit/replit-code-v1_5-3b/

Re: C and C++ Hot-Reload/Live Coding

#27

Post by el_oni »

mananaysiempre wrote: post #24
kleiba wrote: post #18

In one of the earlier episodes of the Handmade Hero series, Casey Muratori writes a hot-reloading functionality for C from scratch in about an hour (while giving detailed explanations of what he's doing). The following two episodes then improve upon the initial results. https://www.youtube.com/watch?v=WMSBRk5WG58

On one hand, I appreciate Muratori showing that loading code into your program dynamically isn’t actually difficult. On the other, the hard part of general hot reloading on systems that have tried it (from Smalltalk to VC++ Edit-and-Continue) is migrating obsolete state—or at least reliably telling the user when you can’t, so as to avoid leaving them to debug a mad world that could never be encountered in a fresh run…

There is a tsoding daily video with hot code reloading in C [0].

He dicusses techniques for this. one of which is a "migration" approach, similar to database migrations. Where, for example, you have a version number in your struct. and a function for migrating from an old version to a new version. I don't think he implements it in that video though.

[0] https://www.youtube.com/watch?v=Y57ruDOwH1g&t=15s

Re: C and C++ Hot-Reload/Live Coding

#28

Post by mjburgess »

cangeroo wrote: post #21
mjburgess wrote: post #6

fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading ). It's a sign of how bad developer tooling has been that live reload is sold as an add-on feature. DX seems always to see-saw between bill gate's c. 1990 demo of VB, and the compile-time speeds of a N' Wirth. At a guess, when the internet happened, all DX had to be thrown a…

One problem is that modern software architectures are highly coupled and stateful, such that it isn't possible to hot reload a component. It would require the host (e.g. when using a DLL) to detect a change, save state, unload, reload, load state. Multi-threading may also make things more difficult, requiring more synchronization during changes. I agree with your sentiment, but it's really hard to communicate it to t…

well, i think the issue is as least as much that the developers who create these architectures do not start from this pov ---

consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms.

This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_state()?

Only that it would need to be actively maintained and developed -- that is, it would obligate developers to tend to their own ability to work.

What i think here is lost is not, somehow a simple system which can be magic, but the concern of developers to maintain such systems.

Why? Certainly, many reasons. But my comment here today is more to frame the issue: this 'feature' can, and should, be part of ordinary development. It isnt that hard.

Even if save_frame() is no longer a register copy, but somehow, an obscene json serialisation process.

Re: C and C++ Hot-Reload/Live Coding

#29

Post by adra »

throwup238 wrote: post #17
reactordev wrote: post #12

Earlier quoted context omitted.

This is how RunUO/ServeUO was designed as well. I'm pretty sure it's a common design practice that came from muds. The server is only responsible for network and communications - everything is then orchestrated through plugins/scripts/systems that can be compiled and reloaded while the server is running. The more modern way is now to separate your "server" from your "modules" in distributed-systems architecture (just…

> Doing it in C/C++ land is heroic. Not to diminish the accomplishment or anything but is it that much easier in C# and Java? It was always really easy to use the libloaderapi in Windows. Throw a vtable on it and baby, you got a stew going!

At least for java, you can spin out a new class loader which intercepts all class loading tasks and basically shim the dynamic module from the permanent runtime platform very trivially. For unloading, you'll likely need conventions on how to shut it down cleanly to not leave a ton of garbage around. Want a new version? Spin up a new class loader, rinse and repeat. If you need stateful between versions, you clearly need to mindfully build a facade for that outside of the dynamic parts. This is all not hard, but not introductory either. That said, I basically wrote similar DLL loaders in my first year writing c so many decades ago, so shrugs.

Re: C and C++ Hot-Reload/Live Coding

#30

Post by miniupuchaty »

It's pretty good. Epic added it as part of Unreal Engine to replace their previous hot reload system, which was more similar to the alternatives that people are mentioning here. That previous hot-reload didn't work as well as live coding, was less stable.

Simple dll reloading can work great if you separate state from logic, like shown in handmade hero. If you cannot enforce that then live++ is a good alternative.

Too bad there's no linux support.

Post reply on HN