+1<div><br clear="all"><div><div>Best regards,</div><div>Max</div><br></div>
<br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 11:11 PM, Max Lapshin <span dir="ltr"><<a href="mailto:max.lapshin@gmail.com" target="_blank">max.lapshin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Ok, my question is: why do they think that fixing the same bug in C program, written around libuv will be easier?<br></div>I've written a video streaming server in ObjectiveC and I can tell how hard is to find bugs in single threaded callback-style program.<br>


<br></div>So, this is a hard-to-find-bug. When you fix all easy-to-find-bugs there are only hard bugs. Erlang has all easy bugs fixed, left only hard bugs. This is why we will hear more and more that some horrible bug inside Erlang VM is found and fixed.<br>


<br><br></div>Frankly speaking, I dont understand complaints about erlang performance, when half of your system is written in C. Fast path is coded in C and erlang has excelent capabilities for it. <br></div>I've used such approach to<br>


</div>1) capture UDP packets in fast manner with my own hand-crafted gen_udp <a href="https://github.com/erlyvideo/flussonic/blob/master/apps/mpegts/c_src/mpegts_udp.c" target="_blank">https://github.com/erlyvideo/flussonic/blob/master/apps/mpegts/c_src/mpegts_udp.c</a><br>


</div>2) use direct mmap access (which is impossible in Java): <a href="https://github.com/erlyvideo/flussonic/blob/master/apps/flussonic/c_src/mmap.c" target="_blank">https://github.com/erlyvideo/flussonic/blob/master/apps/flussonic/c_src/mmap.c</a><br>


</div>3) write USB video capture: <a href="https://github.com/erlyvideo/uvc/blob/master/c_src/uvc.c" target="_blank">https://github.com/erlyvideo/uvc/blob/master/c_src/uvc.c</a><br></div>4) write my own database for storing ticks: <a href="https://github.com/maxlapshin/stockdb/blob/master/c_src/stockdb_format.c" target="_blank">https://github.com/maxlapshin/stockdb/blob/master/c_src/stockdb_format.c</a><br>


<br></div>So I really don't understand the problem.<br><br>You are writing a database server and use erlang prim_file? Sorry, are you really sure that you are writing a database server or you are just playing a new shiny toy?<br>


</div>Was it a problem to open very simple erlang sources and find that prim_file is designed for non-blocking, not for speed?<br><br></div>For example, when I understood that erlang's gen_udp cannot accept 10K of messages per second, I've rewritten it in C in a couple of days. If I was writing a database server with high requirements to disk IO, I would definitely use blocking but fast direct file access.<br>


<br></div>But I don't see any of these reasonings in Damien's post, I see only "created cultures that focus on the wrong things". Yes, of course C created a culture which is focused only on right things.<br>


</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></div>