6 ms·

fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading https://en.wiki

fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading 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 away and we still arent back to where we were 30+ y ago. 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. (consider also, https://github.com/tsoding/musializer https://github.com/tsoding/musializer which has live rebuild via the nobuild system in nob.c)

agentultra 3y ago
I was also suspicious but I think this system does have advantages over the OS interfaces for this: incremental compilation and binary patching. If this goes down to the function or block level definitions and is fast that's pretty sweet. The only time I've enjoyed that kind of DX is with Common Lisp/CLOS. Update: there's a "deep dive" power-point that goes into a bit more detail: https://liveplusplus.tech/downloads/THQ_Nordic_Dev_Summit_2023_Live++_Behind_the_Scenes.pptx https://liveplusplus.tech/downloads/THQ_Nordic_Dev_Summit_20...
benwaffle 3y ago
> fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking & reforking). Can you expand on this?
- mjburgess 3y ago
  https://en.wikipedia.org/wiki/Dynamic_loading https://en.wikipedia.org/wiki/Dynamic_loading
  - orf 3y ago
    This doesn’t answer the question, and doesn’t really help with hot reloading at all outside of the most basic examples.
foooorsyth 3y ago
>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.
- mjburgess 3y ago
  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?!)
- deleted 3y ago
  [deleted]
cangeroo 3y ago
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.
- mjburgess 3y ago
  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.
  - norir 3y ago
    I feel like to some extent the problem here is the dynamic linking model that is almost universally used. If programs were designed from the perspective of the linker, then the linker could maintain a graph of function dependencies and have a cascading invalidation upon update. It is hard to retrofit this onto a project that is already a standard make based project.
  - cangeroo 3y ago
    Yes, but: Components depend on other components, and they all have to support hot reloading. And what about side effects? For example, an open network connection, or a window. You could store the state (handles etc.), but what about callbacks during the reloading phase? They'd have to block and wait. Ultimately, what you need is a message passing architecture that supports all this. Smalltalk. Alan Kay has been a vocal critic of our modern architecture. See his talk "Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet". But that architecture is computationally inefficient. I suspect the problem is that computers weren't fast enough for the last 30 years. So we focused on performant computing. We still do that, with high fps gaming. And adding better quality graphics. Soon we'll have Apple Vision Pro with a 4k display for each eye. My personal hope is that WebAssembly and the Component Model will drastically change things, by introducing API virtualization and effectively decoupled modules, but this will require that tree-shaking/deadcode removal is disabled.
cryptonector 3y ago
fork() doesn't hot reload much of anything. exec() doesn't hot reload either. Dynamic loading doesn't hot reload either, more like hot load. Debuggers might hot-patch code to insert breakpoints, but that's not the same thing as replacing running code. Sure, the debugger might execute scripts you associate with breakpoints, but that's also not exactly the same thing as replacing the running code. Mind you, debuggers do have to make sure that such hot-patching is atomic, or they have to stop all threads. Hot reloading has a ton of considerations: - threading -- you need to quiesce all threads at points where they are not executing the code to be reloaded _or_ you need to load the new code and hot-patch either calls to old code and/or old code function entrypoints to jump to the new code, but if the latter then you need to make sure it's ok to have a mix of threads executing old code while the new code comes online - data structure compatibility -- if structures have changed you may not be able to hot-reload, but you need to at least be able to detect incompatible changes, and at best you need to plan how the hot-reloaded code will upgrade extant data structures on the fly - and more Sure, if you atomically hot-patch all the calls to old code or old code entry points, then threading issues on the side of the hot-reloading library go away, but you still have to think about how old and new code running concurrently will deal with each other. Now, I don't know that much about this subject, and I've seen how old Lisp and Smalltalk systems could hot-patch/reload all the live long day with no problems, but I suspect all the systems where it was ever easy were a) single-threaded, b) written in high-level languages, c) still had some reloading considerations for the authors of the code being reloaded.
- macintux 3y ago
  > ... a) single-threaded Well, one counter-example: Erlang. But Erlang is typically the exception to any rule.
  - cryptonector 3y ago
    Shared-nothing threading is definitely easier to deal with in hot-reloading, and I should have thought to mention that.
- therealcamino 3y ago

agentultra 3y ago

I was also suspicious but I think this system does have advantages over the OS interfaces for this: incremental compilation and binary patching. If this goes down to the function or block level definitions and is fast that's pretty sweet. The only time I've enjoyed that kind of DX is with Common Lisp/CLOS. Update: there's a "deep dive" power-point that goes into a bit more detail: https://liveplusplus.tech/downloads/THQ_Nordic_Dev_Summit_2023_Live++_Behind_the_Scenes.pptx https://liveplusplus.tech/downloads/THQ_Nordic_Dev_Summit_20...

benwaffle 3y ago

> fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking & reforking). Can you expand on this?

mjburgess 3y ago
https://en.wikipedia.org/wiki/Dynamic_loading https://en.wikipedia.org/wiki/Dynamic_loading
- orf 3y ago
  This doesn’t answer the question, and doesn’t really help with hot reloading at all outside of the most basic examples.

foooorsyth 3y ago

>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.

mjburgess 3y ago
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?!)
deleted 3y ago
[deleted]

cangeroo 3y ago

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.

mjburgess 3y ago
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.
- norir 3y ago
  I feel like to some extent the problem here is the dynamic linking model that is almost universally used. If programs were designed from the perspective of the linker, then the linker could maintain a graph of function dependencies and have a cascading invalidation upon update. It is hard to retrofit this onto a project that is already a standard make based project.
- cangeroo 3y ago
  Yes, but: Components depend on other components, and they all have to support hot reloading. And what about side effects? For example, an open network connection, or a window. You could store the state (handles etc.), but what about callbacks during the reloading phase? They'd have to block and wait. Ultimately, what you need is a message passing architecture that supports all this. Smalltalk. Alan Kay has been a vocal critic of our modern architecture. See his talk "Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet". But that architecture is computationally inefficient. I suspect the problem is that computers weren't fast enough for the last 30 years. So we focused on performant computing. We still do that, with high fps gaming. And adding better quality graphics. Soon we'll have Apple Vision Pro with a 4k display for each eye. My personal hope is that WebAssembly and the Component Model will drastically change things, by introducing API virtualization and effectively decoupled modules, but this will require that tree-shaking/deadcode removal is disabled.

cryptonector 3y ago

fork() doesn't hot reload much of anything. exec() doesn't hot reload either. Dynamic loading doesn't hot reload either, more like hot load. Debuggers might hot-patch code to insert breakpoints, but that's not the same thing as replacing running code. Sure, the debugger might execute scripts you associate with breakpoints, but that's also not exactly the same thing as replacing the running code. Mind you, debuggers do have to make sure that such hot-patching is atomic, or they have to stop all threads. Hot reloading has a ton of considerations: - threading -- you need to quiesce all threads at points where they are not executing the code to be reloaded _or_ you need to load the new code and hot-patch either calls to old code and/or old code function entrypoints to jump to the new code, but if the latter then you need to make sure it's ok to have a mix of threads executing old code while the new code comes online - data structure compatibility -- if structures have changed you may not be able to hot-reload, but you need to at least be able to detect incompatible changes, and at best you need to plan how the hot-reloaded code will upgrade extant data structures on the fly - and more Sure, if you atomically hot-patch all the calls to old code or old code entry points, then threading issues on the side of the hot-reloading library go away, but you still have to think about how old and new code running concurrently will deal with each other. Now, I don't know that much about this subject, and I've seen how old Lisp and Smalltalk systems could hot-patch/reload all the live long day with no problems, but I suspect all the systems where it was ever easy were a) single-threaded, b) written in high-level languages, c) still had some reloading considerations for the authors of the code being reloaded.

macintux 3y ago
> ... a) single-threaded Well, one counter-example: Erlang. But Erlang is typically the exception to any rule.
- cryptonector 3y ago
  Shared-nothing threading is definitely easier to deal with in hot-reloading, and I should have thought to mention that.
therealcamino 3y ago