The whole discussion surrounding the Erlang issues that Tim Bray presented in his blog has got me wondering about file I/O. I'm definitely no Erlang expert, but my own experiments seem to show that Erlang file I/O is an insurmountable obstacle for the kind of problem Tim's trying to solve. Unfortunately, clear details about file I/O didn't seem to come out in the "Not an Erlang fan" thread.
<div><br class="webkit-block-placeholder"></div><div>So, I'm wondering:</div><div><br class="webkit-block-placeholder"></div><div>1. Is file I/O for large files really as slow as it seems, and if so, why?</div><div>2. Are there existing alternatives to the regular file module functions for file I/O that might skirt this problem, and if so, what are they?
</div><div>3. Is the whole premise of this problem just not "how it's done" in Erlang? If so, how would this problem be rearranged to better allow for an efficient Erlang solution on the large dataset?</div>
<div>4. Someone posted a link to a Haskell solution in a comment in my blog that seems too good to be true: <<a href="http://www.serpentine.com/blog/2007/09/25/what-the-heck-is-a-wide-finder-anyway/">http://www.serpentine.com/blog/2007/09/25/what-the-heck-is-a-wide-finder-anyway/
</a>>. Assuming it's accurate, why does Haskell beat Erlang so handily in this situation?</div><div>5. If file I/O speed is really the issue that it seems to be, are there any plans to officially fix it?</div><div>
<br> </div><div>thanks,</div><div>--steve</div>