Comments on: Rules of Hot Code Swapping http://spawnlink.com/articles/rules-of-hot-code-swapping/ Linking You to Erlang Sun, 22 May 2011 00:00:39 +0000 http://wordpress.org/?v=2.6.1 By: How to Create an Erlang First Target System « streamhacker.com http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-9378 How to Create an Erlang First Target System « streamhacker.com Thu, 02 Jul 2009 15:46:11 +0000 http://spawnlink.com/?p=12#comment-9378 [...] distribute and run on all your nodes. Now you can finally take advantage of release handling with hot code swapping. In an upcoming article, I’ll cover how to deploy release upgrades using reltools and fab. [...] [...] distribute and run on all your nodes. Now you can finally take advantage of release handling with hot code swapping. In an upcoming article, I’ll cover how to deploy release upgrades using reltools and fab. [...]

]]>
By: Mike http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-3534 Mike Mon, 16 Mar 2009 17:05:24 +0000 http://spawnlink.com/?p=12#comment-3534 These might also be helpful: http://wiki.openmoko.org/wiki/Hot_code_loading http://12monkeys.co.uk/2009/02/05/mochi-reloader.html These might also be helpful:

http://wiki.openmoko.org/wiki/Hot_code_loading
http://12monkeys.co.uk/2009/02/05/mochi-reloader.html

]]>
By: John Bender http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-1055 John Bender Mon, 15 Dec 2008 15:43:59 +0000 http://spawnlink.com/?p=12#comment-1055 The amount of awesome material you have on your site here is pretty amazing. I look forward to seeing the screencasts, as thats one way to help get the erlang ball rolling for a greater audience. The amount of awesome material you have on your site here is pretty amazing. I look forward to seeing the screencasts, as thats one way to help get the erlang ball rolling for a greater audience.

]]>
By: Mitchell http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-80 Mitchell Mon, 15 Sep 2008 06:16:20 +0000 http://spawnlink.com/?p=12#comment-80 Zamous, The final article of my OTP introduction series covers this in detail. Should be published at the end of this week, or around there. ;) Zamous,

The final article of my OTP introduction series covers this in detail. Should be published at the end of this week, or around there. ;)

]]>
By: Zamous http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-79 Zamous Mon, 15 Sep 2008 06:01:40 +0000 http://spawnlink.com/?p=12#comment-79 Any chance on covering this for an OTP application? Thanks! Any chance on covering this for an OTP application?

Thanks!

]]>
By: Christopher Oliver http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-59 Christopher Oliver Fri, 12 Sep 2008 13:58:00 +0000 http://spawnlink.com/?p=12#comment-59 Ulf Wiger wrote: When programming in Omnis 7 (a database 4GL), editor and debugger where fully integrated, and one could edit code while debugging it... That was 15 years ago… One could go back even further with Smalltalk-80 and the lisp machines to see the same sort of thing as well as hot swap. I think Erlang's claim to the stage rests more on a lightweight CSP model with a syntax that supports CSP cleanly than on hot swapping. Ulf Wiger wrote:
When programming in Omnis 7 (a database 4GL), editor and debugger where fully
integrated, and one could edit code while debugging it… That was 15 years ago…

One could go back even further with Smalltalk-80 and the lisp machines to see the
same sort of thing as well as hot swap. I think Erlang’s claim to the stage rests more
on a lightweight CSP model with a syntax that supports CSP cleanly than on hot
swapping.

]]>
By: Kevin’s Link Blog » Hot Swapping Code in Erlang http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-58 Kevin’s Link Blog » Hot Swapping Code in Erlang Fri, 12 Sep 2008 12:59:05 +0000 http://spawnlink.com/?p=12#comment-58 [...] Mitchell Hashimoto on the basics of hot code swapping: http://spawnlink.com/articles/rules-of-hot-code-swapping/ [...] [...] Mitchell Hashimoto on the basics of hot code swapping: http://spawnlink.com/articles/rules-of-hot-code-swapping/ [...]

]]>
By: Tim http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-22 Tim Thu, 04 Sep 2008 16:57:24 +0000 http://spawnlink.com/?p=12#comment-22 Above, Martin says "... he would stop the process and relaunch using a new dll through the master process." That's where there is one difference : as soon as you stop the process you are vulnerable to failure. Even if you restart it as quickly as possible you still have a window of opportunity for a request to attempt to hit your service, at which point you have a failure. In systems that mandate fault tolerance that could be problematic. There might be work-arounds to this, it will depend on exactly what your program is doing. In Erlang, you never actually stop it, so you have 0% downtime. Sure, you can do this in other languages, it's just it's a lot harder to do if the language doesn't have hot-swap as a core design principle : you end up doing a lot of coding to recreate something that is built-in to Erlang. Aside from a lack of downtime, another important distinction is that when you redeploy in Erlang you automatically maintain state. If you're doing it in a language that doesn't have native hot-swap then I guess you have to explicity code for it, serializing your variables etc, and deserializing them when you start the new process... or are there any libraries for Java, C++ etc that can make hot-swap work automagically ? Above, Martin says “… he would stop the process and relaunch using a new dll through the master process.”

That’s where there is one difference : as soon as you stop the process you are vulnerable to failure. Even if you restart it as quickly as possible you still have a window of opportunity for a request to attempt to hit your service, at which point you have a failure. In systems that mandate fault tolerance that could be problematic. There might be work-arounds to this, it will depend on exactly what your program is doing.

In Erlang, you never actually stop it, so you have 0% downtime. Sure, you can do this in other languages, it’s just it’s a lot harder to do if the language doesn’t have hot-swap as a core design principle : you end up doing a lot of coding to recreate something that is built-in to Erlang.

Aside from a lack of downtime, another important distinction is that when you redeploy in Erlang you automatically maintain state. If you’re doing it in a language that doesn’t have native hot-swap then I guess you have to explicity code for it, serializing your variables etc, and deserializing them when you start the new process… or are there any libraries for Java, C++ etc that can make hot-swap work automagically ?

]]>
By: Ulf Wiger http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-21 Ulf Wiger Thu, 04 Sep 2008 12:15:29 +0000 http://spawnlink.com/?p=12#comment-21 To mention another program that has been able to do hot code swapping for ages: emacs! It's true that dynamically replacing code is not new. If you read Armstrong's History of Erlang (http://portal.acm.org/citation.cfm?id=1238844.1238850), you will find that hot code swapping was one of the input requirements to what later became Erlang already in 1986, since the Ericsson AXE phone switches that came out in 1974 had this capability. At Ericsson, we also perform hot code swapping on C++ and Java applications. Now to the "so what?" In Erlang, the requirement to change code in a running system was a primary input requirement, and influenced other factors of the language design. So it was with Java too, but while Java also had the requirement to appeal to C++ programmers, it stuck with the shared memory model, whereas Erlang departed from it because it makes fault tolerance and in-service code change more difficult (as well as breaking symmetry between local and distributed processing). Erlang was also influenced by ML. ML relies on strong static typing, which is problematic from a hot code loading perspective (not unsolveable, but more difficult). The combination of share-nothing concurrency, immutable data, dynamic typing and hot code loading is what makes it interesting. Add to this the OTP "behaviours" that provide hot swapping support "for free", and you have an environment where designers can, and habitually do, change code and hot-load it into a running system as an integral part of the edit-compile-test cycle. I once realised that while prototyping a server application, I'd been doing farly massive changes back and forth, but hadn't restarted the server once in three months. It's not a world record by any means, but it's still pretty cool. One place where we can witness the difference is in "bakeoffs" or "interop events", where different manufacturers meet to try to get their systems working together. It's quite common that the guys with Erlang-based systems end up making their own code bug compatible with the C++ and Java-based systems, because debugging, modifying and updating the code base is that much easier. In interops, all tricks are allowed, because it's a learning experience, but what experience has taught us, is that while hot code loading can be done in these other systems as well, the practical difference in the field is quite significant. Personally, I've experienced even slicker environments. When programming in Omnis 7 (a database 4GL), editor and debugger where fully integrated, and one could edit code while debugging it, stepping through the code, inspecting variables, and if something went wrong, back up the "go point", edit the code or variables, and then step through the code again, until you got it right. That was 15 years ago... To mention another program that has been able to do hot code swapping for ages: emacs! It’s true that dynamically replacing code is not new. If you read Armstrong’s History of Erlang (http://portal.acm.org/citation.cfm?id=1238844.1238850), you will find that hot code swapping was one of the input requirements to what later became Erlang already in 1986, since the Ericsson AXE phone switches that came out in 1974 had this capability. At Ericsson, we also perform hot code swapping on C++ and Java applications.

Now to the “so what?” In Erlang, the requirement to change code in a running system was a primary input requirement, and influenced other factors of the language design. So it was with Java too, but while Java also had the requirement to appeal to C++ programmers, it stuck with the shared memory model, whereas Erlang departed from it because it makes fault tolerance and in-service code change more difficult (as well as breaking symmetry between local and distributed processing).

Erlang was also influenced by ML. ML relies on strong static typing, which is problematic from a hot code loading perspective (not unsolveable, but more difficult).

The combination of share-nothing concurrency, immutable data, dynamic typing and hot code loading is what makes it interesting. Add to this the OTP “behaviours” that provide hot swapping support “for free”, and you have an environment where designers can, and habitually do, change code and hot-load it into a running system as an integral part of the edit-compile-test cycle. I once realised that while prototyping a server application, I’d been doing farly massive changes back and forth, but hadn’t restarted the server once in three months. It’s not a world record by any means, but it’s still pretty cool.

One place where we can witness the difference is in “bakeoffs” or “interop events”, where different manufacturers meet to try to get their systems working together. It’s quite common that the guys with Erlang-based systems end up making their own code bug compatible with the C++ and Java-based systems, because debugging, modifying and updating the code base is that much easier. In interops, all tricks are allowed, because it’s a learning experience, but what experience has taught us, is that while hot code loading can be done in these other systems as well, the practical difference in the field is quite significant.

Personally, I’ve experienced even slicker environments. When programming in Omnis 7 (a database 4GL), editor and debugger where fully integrated, and one could edit code while debugging it, stepping through the code, inspecting variables, and if something went wrong, back up the “go point”, edit the code or variables, and then step through the code again, until you got it right. That was 15 years ago…

]]>
By: Mitchell http://spawnlink.com/articles/rules-of-hot-code-swapping/#comment-20 Mitchell Wed, 03 Sep 2008 16:13:40 +0000 http://spawnlink.com/?p=12#comment-20 Martin, I would say most of its concepts can be recreated in other languages but the whole point is that they were built in to Erlang from the start as a foundation to the language. Erlang was built to be concurrent, fault tolerant, etc. etc. (you've probably heard it before ;)) So although the features can be "recreated," Erlang makes it very easy to make these otherwise complex systems. And with this ease of use, you don't have to sacrifice the ability to upgrade your systems seamlessly. Its all part of the language. Erlang is by no means a panacea to all computing problems, it has plenty of its own. And it will not replace other languages. Its just its own language, in its own little niche of the programming market :) (Though others are closing in!) Martin,

I would say most of its concepts can be recreated in other languages but the whole point is that they were built in to Erlang from the start as a foundation to the language. Erlang was built to be concurrent, fault tolerant, etc. etc. (you’ve probably heard it before ;))

So although the features can be “recreated,” Erlang makes it very easy to make these otherwise complex systems. And with this ease of use, you don’t have to sacrifice the ability to upgrade your systems seamlessly. Its all part of the language.

Erlang is by no means a panacea to all computing problems, it has plenty of its own. And it will not replace other languages. Its just its own language, in its own little niche of the programming market :) (Though others are closing in!)

]]>