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. <br>
<br>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.<br>
<br>Cheers,<br><br>Tim<br><br>On 11 February 2012 20:33, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@gmail.com">mononcqc@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<div class="HOEnZb"><div class="h5">

<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" target="_blank">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>>  <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>> _______________________________________________ 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" 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>
<br></blockquote></div><br>
</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>