[erlang-questions] The future of Erlang and BEAM

[Radek]

I'm still a novice, but I can clearly say that Erlang is a nice language 
to play with; There is short period of time needed to convert the 
working prototype to full solution, since it's sometimes just the case 
of clearing/adding some API (because you already use gen_server, 
gen_fsm, ...) etc.

Moreover, I think that many times it's just simpler to use Erlang 
compared to Java/C++/... because you don't have such difference from 
model (when it's said "sending message from object A to object B) to 
implementation. In Erlang you actually send a message and don't have to 
bother to properly implement Observer pattern and all that stuff. So 
it's a huge advantage of both Erlang style on concurrency & functional 
programming.

I was just wondering if making it on JVM wouln't be a good idea, but I 
realized I didn't put some thing under consideration (like safety and 
truly fault-tolerance). And, it seems it's easier to make Erlang faster 
by researching for better algorithm/solution or sacrificing some 
performance for overall better (in terms of speed/reliability ratio) 
quality of product than trying to make things to work the same way on 
platform(-s) that wasn't designed for it in the first place.

Greetings,
Radek

W dniu 2012-02-11 23:06, Jesper Louis Andersen pisze:
> On 2/11/12 11:34 AM, Radek wrote:
>>
>> So the question arises: is Erlang still the best platform to build 
>> such demanding applications ? Wouldn't it be better if we stick to 
>> one, very mature (J)VM and try to make it even better than trying to 
>> achieve something similar with less resources available (size of OTP 
>> team vs. JVM team, supporters, etc) ? And is it possible at all to 
>> achieve this kind of performance and adoption with BEAM ?
>>
> Performance is but one of many aspects of writing a program. Usually 
> performance is possible, but bounded by human time spent. That is, if 
> you have limited time, say 3 days, to implement something then usually 
> the solutions are very different performance wise. One of the distinct 
> advantages of Erlang is how fast you can build up prototypes and make 
> them run. This means you have ample time to sit back and tune your 
> system for better performance. You have more time to change algorithms 
> and tune for faster execution.
>
> Another strength of Erlang is that programs can evolve. Adding another 
> process with a certain responsibility or altering the internal 
> implementation of a process is easy: the messages passed forces an API 
> between your components. This yields a system where you can gradually 
> build it up over time.
>
> Erlang is a rarely seen triumvirate: fault-tolerance, 
> distribution+message passing, and functional sequential programming. 
> You often see other systems implementing one or two of those, but I 
> have not yet seen all three implemented in another language. This 
> places Erlang in a niche, and I think many people who do take time to 
> learn the details enjoy the ideology of Erlang as a fabric for program 
> construction.
>
> -- 
> Jesper Louis Andersen
>    Erlang Solutions Ltd., Copenhagen, DK
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120211/9db629ab/attachment.htm>