[erlang-questions] The future of Erlang and BEAM

[Radek]

Hi Gleb,

Yes, I've seen it already. But I'm not sure if it's exactly what I meant.
I rather thought about making something like a framework which would 
emphasize concurrency, fault-tolerance, etc. and implement Erlang as a 
DSL just to operate on it.

Kresten (author of Erjang) did a great job but took (as I understand it; 
I may be wrong) little different option and "translated" C code to Java, 
made .beam files possible to be loaded on JVN thus making it capable of 
running Erlang code.

By making a special framework and Erlang-as-DSL to operate on it, we 
could then use normal Erlang tools without many downsides of them (for 
example, we could always rely on messages because of no copy-on-send 
penalty, use more data structures apart from just lists and tuples, and 
so on).

Of course, I'd like to repeat that I'm not an Erlang-master nor skilled 
in language design etc so my ideas can be just wrong.

Greetings,
Radek

W dniu 2012-02-11 13:37, Gleb Peregud pisze:
> On Sat, Feb 11, 2012 at 13:20, Radek<poprosturadek@REDACTED>  wrote:
>> But, maybe I'm a bit of devil's advocate, let's say that we (by which I mean
>> mostly OTP team because of their knowledge of Erlang intrinsics but others
>> too) could follow similar direction that Clojure's creator Rick Hickey took.
>> Which means, to build Erlang on JVM, using tools that we already have (like
>> earlier mentioned Java libraries, etc) and optimize it for using with JIT.
> http://erjang.org/ - actually there is such solution already :) Not
> sure how mature it is, but afaik it implements most of stdlib and bifs