On 5/13/2011 4:32, Invisible wrote:
> 4. Really easy to link to C for performance-critical sections.

Do you have an example of what you need to do in Haskell to link to a simple 
C function? Is it easy for C to call Haskell functions?

> Implementing Erlang's distributed processing model in Haskell. (This is a
> work in progress. I doubt it's production-ready yet - or any time soon.)

Yah. Python has one of these too.

> Notable by its absence is hot code update. Some commentators have noted that
> if you actually care about high availability, you'll be using multiple
> hot-spares anyway, and so long as you don't take down all systems at once,
> you can just take one offline, update it, put it back online, and move on to
> the next one.

The problem with this is it takes *incredibly* longer. You have to write all 
the current data out to disk, shut down cleanly (including all the processes 
running there whose code you are *not* updating), then modify the code, then 
start everything up again, and read everything back in off disk.

With Erlang's hot update, the data stays in memory. If you're fixing a bug, 
you don't have to save out and then reload dozens of gigabytes of in-memory 
database just to change the line. Plus, you now have to write all the code 
to shut down cleanly and start up cleanly again, and track which tasks are 
running in the same process as you're shutting down, shut them down too, etc.

Yeah, you can do it, and that's the answer I give to people who bitch about 
Windows needing to reboot to update widely-used code and such, but it really 
sucks for an availability system where you have bunches of threads on the 
same machine.

> All of which obviously fails spectacularly if sender and receiver aren't
> running the same version of the same program. ;-)

It also fails if the sender and receiver aren't using the same version of 
the data structures. As soon as you have half your code updated to be using 
floats instead of integers, now you have to have some way in your *old* code 
to be able to know you're getting *new* messages and how to handle them. 
That can be rough with static typing.

 > 1. Every process implicitly has a "mailbox" that can be used to send or

That's the Erlang approach, except of course it's dynamically typed.

 > 2. You can explicitly create typed "channels". Each such channel can

That's the NIL / Hermes approach, both of which were statically typed. The 
advantage of this is channels can become first class. You can pass them 
between processes and have different channels connected to different 
processes.  You can use it for security, too - if I don't give you a channel 
to the screen but only to your window, you can only write to your window, 
and it's trivial to verify that.

 > (This is not livelock,

I'm not sure about that. I think livelock is defined for individual tasks, 
such that no task spends an unbounded amount of time waiting for access to 
the critical section.  I.e., a system making progress is defined as no part 
of the system failing to make progress. But I can't find anything online to 
back that up.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message