[erlang-questions] The future of Erlang and BEAM

[Tim Watson]

I'd really second this. I work with both Erlang and Java (alongside a few
other bits and peices) on a daily basis and slowness isn't something I've
really run into major difficulties with Erlang at all. If you take a look
at that rather well documented case of the chat at Github who implemented
an Erlang git daemon, but then found it to be too slow so abandoned it. A
more experiences Erlang programmer came along and refactored the code for
massive performance improvements.

It's true that sometimes you need raw throughput that Erlang can't provide
and need to break out to C/C++ with a port/nif or whatever, but that's not
so often the case. Also I prefer to 'pick the right tool for the job' and
not every system has to be monolithic running on only one VM.

Cheers,

Tim

On 11 February 2012 20:33, Fred Hebert <mononcqc@REDACTED> wrote:

> The best question to ask after this is "What's slow?", "What do you
> consider to be fast enough?", "What are your requirements?". You often (but
> not always) find out that they do not really know what they want, so they
> aim for the fastest overall thinking 'surely, I won't make a mistake
> there.' Do you need a 5 nanosecond message sending requirement when you're
> going to treat the message for 20 milliseconds anyway?
>
> In some cases they do need something too fast for Erlang, or think Erlang
> is optimized for areas it isn't. Then being honest will be the best
> argument to prove you're giving sane recommendations and are not a fanboy.
> But before knowing what they really need, it is pretty hard to counter any
> argument.
>
> There's no use fighting someone whose task to accomplish requires too much
> work or time in Erlang, but sometimes apprehensions come from not knowing
> the technology or the problem enough; that's where we can help.
>
> On Sat, Feb 11, 2012 at 1:37 PM, Matthew Evans <mattevans123@REDACTED>wrote:
>
>>
>> Having said that there is a valid criticism of Erlang in that it is often
>> perceived to be too slow. As Joe said, you can't have all the features of
>> resilience and reliability without some cost, but when trying to "sell"
>> Erlang it's often the first argument against Erlang that I hear. The pointy
>> haired managers look at things like the Alioth shootout and see Erlang
>> perform poorly for most tests. Now, most Erlang users will correctly say
>> "well, Erlang isn't designed for those types of highly serial tasks, use C,
>> C++ or Java for that instead, and use Erlang where it makes sense". But
>> this now means that a company needs to embrace 2 (perhaps more) languages
>> to do a job. This isn't necessarily a bad thing, but can make for pain when
>> hiring, training and retaining staff.
>>
>> My point is that I don't think Erlang will ever be as fast as Java and
>> certainly never as fast as C/C++, but I would like to see a greater focus
>> on performance, perhaps get it into the top 10 languages for performance.
>> I'm happy to see that work is been done WRT to JIT in the Erlang VM, and
>> LLVM+HiPE, so maybe future releases will address those concerns.
>>
>> I've also often wondered if it makes sense to implement some of the
>> Kernel and STDLIB modules as BIFs instead of in Erlang. Would that improve
>> things?
>>
>> Matt
>> ________________________________
>> > Date: Sat, 11 Feb 2012 13:20:54 +0100
>> > From: poprosturadek@REDACTED
>> > To: ulf@REDACTED
>> > CC: erlang-questions@REDACTED
>> > Subject: Re: [erlang-questions] The future of Erlang and BEAM
>> >
>> > # the same as above, sorry for inconvenience
>> >
>> > Hi Ulf,
>> >
>> > thank you very much for answer.
>> >
>> > I understand that Erlang has been created in purpose of managing
>> > coordination complexity and it does it's job well.
>> > 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.
>> >
>> > Of course, it's not obvious that (despite being big effort) it would
>> > bring desired performance (although, it seems it would) but some
>> > advantages for sure, like ubiquity of JVM, wide gremium of
>> > supporters/maintainers, ease of deployment (even single .jar maybe),
>> > access to huge variety of other languages and libraries, and even some
>> > minor things like proper module managament, etc.
>> >
>> > As I said before, I'm rather novice in Erlang world (still digging
>> > through Erlang and OTP in Action) so all above may be
>> > wrong/incomplete/etc. I had this idea some time ago so I finally took
>> > decision to write about my concerns here.
>> >
>> > Greetings,
>> > Radek
>> >
>> > _______________________________________________ erlang-questions
>> > mailing list erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
> _______________________________________________
> 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/55424911/attachment.htm>