[erlang-questions] what is the "race condition bug in core Erlang" mentioned by @damienkatz?
Fri Jan 11 20:11:15 CET 2013
Ok, my question is: why do they think that fixing the same bug in C
program, written around libuv will be easier?
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.
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.
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.
I've used such approach to
1) capture UDP packets in fast manner with my own hand-crafted gen_udp
2) use direct mmap access (which is impossible in Java):
3) write USB video capture:
4) write my own database for storing ticks:
So I really don't understand the problem.
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?
Was it a problem to open very simple erlang sources and find that prim_file
is designed for non-blocking, not for speed?
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions