David Masover wrote:
> You mentioned Erlang. It will do some N:M threading -- that is, there 
> really
> will be some OS threads involved. In theory, one crash could bring down 
> your
> entire app. Also in theory, the Erlang runtime is robust enough that 
> this will
> Never Happen -- and to ensure that, the preferred way to write C 
> extensions is
> as separate processes which talk to Erlang via RPC. More efficient than 
> fork
> on Unix, but much more reliable than "threads" in just about any 
> language.
> 
> That is: I see threads as both as harmful and as useful as Goto.

Absolutely all true.

Of course, threads are going to be necessary at some level (just as goto 
is necessary at a low level), because that's how SMP hardware actually 
works.

The benefit of erlang is that is uses threads on your behalf but 
provides you a much better message-passing abstraction in its place.

(It's possible to have message-passing at the hardware level. The 
Transputer is an example of that. Writing in Occam for the Transputer is 
like writing in C for a regular CPU - one step above machine code)

> The biggest problem I have with Erlang is that the syntax is hideous,
> especially after Ruby.

When I get a few spare cycles I'm trying to hack together a 
ruby-flavoured erlang: just a front end which emits either the erlang 
abstract syntax form, or regular erlang source.

> This is why I have such high hopes for Reia, and why I'm tempted to 
> dabble in
> io -- I want something that's at least as beautiful as Ruby (though I do 
> like
> prototypal inheritance), but at least as good at concurrency as Erlang.

After erlang, when I look at ocaml again it starts to make a lot more 
sense (for example, all the pattern-matching stuff). And ocaml can 
compile directly to machine code too.
-- 
Posted via http://www.ruby-forum.com/.