[erlang-questions] The future of Erlang and BEAM

[Paul Davis]

On Sat, Feb 11, 2012 at 2:49 PM, Tim Watson <watson.timothy@REDACTED> wrote:
> 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.
>

Here's a link to the articles about refactoring egitd by Andrew
Thompson. I'd highly recommend them to anyone that's not read the
series.

http://andrew.hijacked.us/article/324/optimizing-egitd-introduction

> 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
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>