[erlang-questions] The future of Erlang and BEAM
Sat Feb 11 23:36:10 CET 2012
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
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.
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
> Jesper Louis Andersen
> Erlang Solutions Ltd., Copenhagen, DK
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions