[erlang-questions] The future of Erlang and BEAM

[Fred Hebert]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120211/08bca65b/attachment.htm>