5 ms·

Nobody intended to give an answer to an unsolvable problem, but to solve practical problems. If you redesign data structures, most likely you'll have to restart

Nobody intended to give an answer to an unsolvable problem, but to solve practical problems. If you redesign data structures, most likely you'll have to restart the program. So what?

williamcotton 4y ago
I agree, this is still very useful in something like game development where you want to maintain state and you’re well beyond the point in development where you’re changing data types!
xxpor 4y ago
That's simply unacceptable for some systems, like if you're actively routing phone calls.
- jstimpfle 4y ago
  It's acceptable (and required) for others. Which is my point.
- deleted 4y ago
  [deleted]
- ithinkso 4y ago
  If a restart is unacceptable then live-patching a data structure change at runtime requires a #YOLO approach to developement and ice in your veins
  - xxpor 4y ago
    Well, I can't say too much, but it's not as bad as you might think. It's extremely annoying, but doable. It's really not that different from doing a DB table update.
  - macintux 4y ago
    Depends on the platform. Erlang was specifically designed around telecom systems that needed maximal uptime, and the language and runtime collaborate to support hot patching with a distinctly non-YOLO approach.
    - ithinkso 4y ago
      Interesting, Erlang comes up here on HN rather frequently but I haven't really looked into it. I think I should though, any resources you can specifically recommend?
      - macintux 4y ago
        Funny you should ask… I haven’t checked these links in quite some time: https://gist.github.com/macintux/6349828 https://gist.github.com/macintux/6349828 And if you don’t mind videos, here’s my talk from Midwest.io (RIP) on the philosophy behind Erlang & its VM: https://youtu.be/E18shi1qIHU https://youtu.be/E18shi1qIHU
    - foldr 4y ago
      Live patching is cool but it's something of a mythical beast. I hear lots of people talking about the wonders of live patching but very few people reporting on actually using it in their own production systems. If you're building an ultra-reliable system, then you have to somehow make it robust in the case where (some of) the hardware executing your code fails. Once you've covered that case, there's not much need for live patching.
      - macintux 4y ago
        I think it depends on which level of live patching you're talking about. At Basho, we would load module fixes into Riak instances for customers...I hesitate to say "fairly regularly" because it's been long enough and I had limited visibility into it, but it certainly seemed like a routine operation. The full "upgrade the entire application" hot loading definitely requires more planning than most companies will ever be willing to do.
Jtsummers 4y ago
http://www.lispworks.com/documentation/HyperSpec/Body/f_upda_1.htm#update-instance-for-redefined-class http://www.lispworks.com/documentation/HyperSpec/Body/f_upda... That's how you'd handle it in Lisp. Smalltalk has something similar, but I'm less familiar with the internals for it. No restart needed, but it requires a runtime that is able to track data instances by type. You could build that onto C, though. Probably with a custom allocator that was passed some symbol indicating the structure type so it could report on instances for executing an update. Would be hard, though, to do this without invalidating pointers when the size changes. You'd probably end up with an extra level of indirection as a consequence to make it simpler (for the runtime author, not for the end user).
- jstimpfle 4y ago
  Many things are possible with another level of indirection, but not necessarily worth while.
  - Jtsummers 4y ago
    I mean, the project that started this discussion is considered "not necessarily worth while" by most people, that's why they use systems that require restarts on function redefinition instead of hot code reloading. But if you're going to the trouble of supporting hot code reloading, you ought to support (at least as an option) structure redefinition as well. Otherwise you've only gone halfway to making an actual interactive system.

Nobody intended to give an answer to an unsolvable problem, but to solve practical problems. If you redesign data structures, most likely you'll have to restart the program. So what?

williamcotton 4y ago

I agree, this is still very useful in something like game development where you want to maintain state and you’re well beyond the point in development where you’re changing data types!

xxpor 4y ago

That's simply unacceptable for some systems, like if you're actively routing phone calls.

jstimpfle 4y ago
It's acceptable (and required) for others. Which is my point.
deleted 4y ago
[deleted]
ithinkso 4y ago
If a restart is unacceptable then live-patching a data structure change at runtime requires a #YOLO approach to developement and ice in your veins
- xxpor 4y ago
  Well, I can't say too much, but it's not as bad as you might think. It's extremely annoying, but doable. It's really not that different from doing a DB table update.
- macintux 4y ago
  Depends on the platform. Erlang was specifically designed around telecom systems that needed maximal uptime, and the language and runtime collaborate to support hot patching with a distinctly non-YOLO approach.
  - ithinkso 4y ago
    Interesting, Erlang comes up here on HN rather frequently but I haven't really looked into it. I think I should though, any resources you can specifically recommend?
    - macintux 4y ago
      Funny you should ask… I haven’t checked these links in quite some time: https://gist.github.com/macintux/6349828 https://gist.github.com/macintux/6349828 And if you don’t mind videos, here’s my talk from Midwest.io (RIP) on the philosophy behind Erlang & its VM: https://youtu.be/E18shi1qIHU https://youtu.be/E18shi1qIHU
  - foldr 4y ago
    Live patching is cool but it's something of a mythical beast. I hear lots of people talking about the wonders of live patching but very few people reporting on actually using it in their own production systems. If you're building an ultra-reliable system, then you have to somehow make it robust in the case where (some of) the hardware executing your code fails. Once you've covered that case, there's not much need for live patching.
    - macintux 4y ago
      I think it depends on which level of live patching you're talking about. At Basho, we would load module fixes into Riak instances for customers...I hesitate to say "fairly regularly" because it's been long enough and I had limited visibility into it, but it certainly seemed like a routine operation. The full "upgrade the entire application" hot loading definitely requires more planning than most companies will ever be willing to do.

Jtsummers 4y ago

http://www.lispworks.com/documentation/HyperSpec/Body/f_upda_1.htm#update-instance-for-redefined-class http://www.lispworks.com/documentation/HyperSpec/Body/f_upda... That's how you'd handle it in Lisp. Smalltalk has something similar, but I'm less familiar with the internals for it. No restart needed, but it requires a runtime that is able to track data instances by type. You could build that onto C, though. Probably with a custom allocator that was passed some symbol indicating the structure type so it could report on instances for executing an update. Would be hard, though, to do this without invalidating pointers when the size changes. You'd probably end up with an extra level of indirection as a consequence to make it simpler (for the runtime author, not for the end user).

jstimpfle 4y ago
Many things are possible with another level of indirection, but not necessarily worth while.
- Jtsummers 4y ago
  I mean, the project that started this discussion is considered "not necessarily worth while" by most people, that's why they use systems that require restarts on function redefinition instead of hot code reloading. But if you're going to the trouble of supporting hot code reloading, you ought to support (at least as an option) structure redefinition as well. Otherwise you've only gone halfway to making an actual interactive system.