The Erlang Shell

Post by bitwalker » Wed, Feb 19, 2014, 5:50 AM UTC

agentultra wrote: post #50

bitwalker wrote: post #16

Earlier quoted context omitted.

> It's not. iIRC there's even a version of the JVM with code reloading. I've seen some info about the JVM implementation, but I could've sworn it wasn't able to preserve state while hot swapping. I haven't dug in to it though, so it's totally possible it handles that. > There are a tonne of features in Common Lisp like this that are geared towards robust, maintainable software. I'm a fan of Lisp in general, though my…

In no specific order: 1. Configurable compiler. You can tell the compiler where it's safe to ignore types and where to be strict about types. For the battle-hardened critical sections of code turning off run-time type checking can be a pretty big win performance-wise. 2. Extensible compiler. Macros are like tiny compilers. It's possible to create DSLs for the programmer to work with a problem in terms of nouns and ve…

Thanks for breaking it down! I'll have to investigate further, but there is a lot here to like.

Post by bitwalker » Wed, Feb 19, 2014, 6:00 AM UTC

simula67 wrote: post #57

phamilton wrote: post #53

Earlier quoted context omitted.

So no. One of the beauties of Erlang's hot code loading is the ability to migrate internal application state. An example: I'm storing a lookup table going from key to value as a tuple {key, value}. With a change going out, I'm going to start doing {key, {value, other-value}}. In Erlang there's an easy pattern in place to do that. Just provide a function that goes from {key, value} to {key, {value, sensible-default}}…

You may have misunderstood. A file can have multiple, say 'deployment units'. You can have a 'migrate deployment unit' which depend on the 'model deployment unit' which forces the app server to deploy the migrate unit first. You can have code there that migrates the tables and fill with default values before your model entities become available for use. From your comment this seems to be the same as what Erlang does…

I think the difference here is that the migration of internal state happens the moment the module is swapped out in memory. Erlang doesn't have mutable state, so state is instead passed around within a module. When a fix needs to be deployed, the two versions (old and new) run simultaneously, any new processes immediately run the new code, old processes call a `code_change` function which takes the current state within that process, performs any transformations required for the new code, and then the old module code is swapped out for the new.

That's not at all a perfect explanation of the process, but it's more or less useful enough to describe the difference between the two platforms.

Re: The Erlang Shell

Re: The Erlang Shell