<div>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?<br>
</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<br><div class="gmail_quote">On Sat, Feb 11, 2012 at 1:37 PM, Matthew Evans <span dir="ltr"><<a href="mailto:mattevans123@hotmail.com">mattevans123@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr"><br><div>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.<br>
<br>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.</div>
<div><br></div><div>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?</div><div><br></div><div>Matt</div><div>________________________________<br>
> Date: Sat, 11 Feb 2012 13:20:54 +0100 <br>> From: <a href="mailto:poprosturadek@gmail.com" target="_blank">poprosturadek@gmail.com</a> <br>> To: <a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a> <br>
> CC: <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <br>> Subject: Re: [erlang-questions] The future of Erlang and BEAM <br><div><div class="h5">> <br>> # the same as above, sorry for inconvenience <br>
> <br>> Hi Ulf, <br>> <br>> thank you very much for answer. <br>> <br>> I understand that Erlang has been created in purpose of managing <br>> coordination complexity and it does it's job well. <br>
> But, maybe I'm a bit of devil's advocate, let's say that we (by which I <br>> mean mostly OTP team because of their knowledge of Erlang intrinsics <br>> but others too) could follow similar direction that Clojure's creator <br>
> Rick Hickey took. Which means, to build Erlang on JVM, using tools that <br>> we already have (like earlier mentioned Java libraries, etc) and <br>> optimize it for using with JIT. <br>> <br>> Of course, it's not obvious that (despite being big effort) it would <br>
> bring desired performance (although, it seems it would) but some <br>> advantages for sure, like ubiquity of JVM, wide gremium of <br>> supporters/maintainers, ease of deployment (even single .jar maybe), <br>
> access to huge variety of other languages and libraries, and even some <br>> minor things like proper module managament, etc. <br>> <br>> As I said before, I'm rather novice in Erlang world (still digging <br>
> through Erlang and OTP in Action) so all above may be <br>> wrong/incomplete/etc. I had this idea some time ago so I finally took <br>> decision to write about my concerns here. <br>> <br>> Greetings, <br>
> Radek <br>> <br></div></div><div class="im">> _______________________________________________ erlang-questions <br>> mailing list <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a> <br></div></div> </div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br>