Erlang

Well, it seems kinda weird, but I am really salivating over the promise of N-times faster programs on an N-core cpu..

Thoughts?

>>39
Ah, I see.

Erlang differs from the Actor model in a number of ways, and I'm fairly sure I've read that Erlang makes no guarantees about messages sent. It's meant to be a fault-tolerant language after all.

So chances are it'd just start dropping them if the queue grew too big.

>>41 nmx Bich-O
"If you think TCP guarantees delivery, which most people probably do, then so does Erlang."

>>39
Synchronous, send->work->wait, and anything else you can think of are easily built on top of asynchronous messaging, and are done in like 3 keywords of Erlang.  The language primitives simply supply ... primitives that you can build really nice shit from, and the libs have probably already built anything you can think of related to message passing and distribution.

>>39
In practice though, I hope there's some sort of a backstop.
There never is. And enterprise fags who use languages like that usually don't even know or care. It's all supar elegant etc., until it actually has to perform.

>>43
Yes, I know. It's just that strict synchronous or send-work-wait has different space characteristics in the event where the receiver doesn't pick up soon enough; having worked with MPI I tend to think of it as superior.

Though I can very well see how in telephony applications it's vastly preferable to have the sender keep going rather than stall. I guess the same thing applies to networked and fault-tolerant applications too. Conversely, asynchronous by default messaging wouldn't be so nice as, say, a microkernel IPC primitive.

>>44
Or they'll bump into it, meet unexpected behaviour, be forcibly torn from their comfort zone and go spastic. Yeah, we've seen it before.

>>44
Yeah, like Erlang isn't used in important infrastructure like telephony at all.  Once they start rolling out those systems starting 15 years ago, all hell is going to break loose.

>>45
In agent-based design, messages are handled quickly since one thread of execution isn't handling everything including the kitchen sink as in traditional threaded/distributed IPC systems.  Plus, seeing as the send statement has timeout handling built in, the "receiver doesn't pick up soon enough" situation is right in your lap.

I don't get this "has to perform now" attitude. What ever happened to writing elegant code first then refactoring the code for speed gains?

>>47
Yeah, like Erlang isn't used in important infrastructure like telephony at all.
You can rest assured that Erlang certainly isn't used for any parts there that actually require some skill to code.

>>48
there's nothing to refactor if you pump it all through some super high one size fits all abstraction layer anyway

>>47
Are you saying that Erlang processes are stackless and not affected by priority scheduling?

Anyway, trapping timeouts when send-work-wait is wrapped around asynchronous messaging just means that the receiver hasn't _replied_ soon enough. Isn't the message queued either at the sender or the receiver, at the mechanism level, until the receiver actually gets it? Even in the case of timeout (i.e. the sender giving up before getting a reply), the sent message will hang around in some queue or another, and so might the reply which was given up on if the receiver hasn't died.

>>48
Real-time requirements are surprisingly common outside prototype code. Well, soft real-time anyway, the kind where it's vastly preferable to have a responsive system than an efficient or even simple system.

>>51
Erlang manages its own process priorities, if you care to fiddle with those settings.  Its process switching time is incredibly short, since it doesn't have to swap CPU states, so it screams through your process list very quickly.

As for your 2nd paragraph, what's the problem?  The sender can only know anything if there is a response from the receiving end.  Take these scenarios:

1) Message went out on the wire, receiver didn't get it yet
2) Message is sitting in the receiver's inbox
3) Receiver pulls the message from its inbox
4) Receiver does its work and sends ACK at the appropriate stage, early on or at the end

Responding to 1-3 really isn't meaningful at all in tracking the call's progress (unless you're doing some incredibly low-level tuning) since the receiver can error out or crash afterwards without the work getting done.  The 4th is really the only useful way of acknowledging reception, and by definition requires the receiver to trigger when it's appropriate to send it.

GUIs and other systems have been doing message-queue processing since they've been invented, and the fear of message overflow has never been a huge concern.

>>38
I was a telco programmer, and 80% of my time went to problems caused by lost or corrupted inter-process messages. There are lots of things getting in the way of those messages: power outages, improper system shutdown by newb administrators, Oracle choking a cpu so bad it can't even read ethernet, abends/coredumps before a key progrma finishes procesing a message, and on and on. The more bullet-proof Erlang's message passing is the better. Extra hard drives for big queues and message logs are much cheaper than programmer time to track down some message that got lost 3 days before anybody noticed something was wrong.

If it doesn't compile to native code, it's not good enough.

>>54
-Omg-optimized.

>>54
I bet you'd walk a mile for a Caml.

>>53
So Erlang can pass messages over the network and still have all that robustness? I don't habeeb it.

>>57
I don't know. We built our own messaging system with all imaginable hand-shaking. But it sounds like Erlang's developers had similar experiences and are building the solution into Erlang.

>>58
It sounds like something that would require a lot of extra infrastructure. Somewhat out of the scope of a programming language alone.