Haskell vs. Erlang for bittorent clients
jlouisramblings.blogspot.ca
jlouisramblings.blogspot.ca
http://www.haskell.org/pipermail/ghc-devs/2013-February/0004...
> Our evaluations show that the new Mio manager improves realistic web server throughput by 6.5x and reduces expected web server response time by 5.7x. We also show that with Mio, McNettle (an SDN controller written in Haskell) can scale effectively to 40+ cores, reach a throughput of over 20 million new requests per second on a single machine, and hence become the fastest of all existing SDN controllers.
http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...
[1] http://www.pps.univ-paris-diderot.fr/~jch/
[2] http://www.pps.univ-paris-diderot.fr/~jch/software/hekate/
since I prefer the platform to blogger.
Say I wanted to write my own bittorrent client for fun and to learn a new language, is there a good guide on bittorrent I can read?
Don't cache anything. Write data directly to disk and use seeks. Request pieces at random and don't think about getting the rarest first. Skimp on the choking strategy and don't do anything clever, but pick a simple algorithm. Skip all the extensions until the other parts work.
Get the wire-protocol and bencoder up and running first. Then handle tracking. Then handle connections to peers. Then handle storage.
1. The author gives the impression that there's no big deal to fixing memory leaks in Haskell. I thought they were supposed to be its Achilles' heel.
2. Erlang lost on its home turf!
Memory leaks are notorious mostly due to leaks in lazy code looking very innocent when coming from strict languages. After you get comfortable with laziness the same code (usually) stands out very clearly. And even when it doesn't, these leaks aren't very subtle. GHC has a good profiler for memory usage, so tracking them down is mostly trivial and fixing them once you know what's wrong is not very hard.
loop = forever x and loop = do {x; loop} had different laziness semantics in the Process monad. The former leaked, the latter did not.
I wrote all of the code in about 1.5 months, but spent the next 2-3 months fighting with memory leaks. In typical batch-processing code this is hardly a problem since a small leak goes away once the program terminates. In a long-running daemon-process, this is not as easy.
It won't point and scream HERE!, but it will give you enough information that you can use to narrow down where the leak happens to be.
Author chose Haskell cause of static type but most of his subsequence posts are Erlang. I'd say Erlang won him ha.
Saying that Erlang lost in its home turf would be a wild extrapolation of what I wrote. I don't really think there is a clear winner, but rather a set of trade-offs you will have to make.
Isn't the type system of ATS more advanced? It might be hard to say with all the GHC extensions.
The only systems which can beat it are theorem provers like Coq, and they are not general purpose programming languages (Morriset and the YNot team might disagree though!).
ATS is dependently typed and therefore falls under theorem provers.
But I have a hunch that the type system of Haskell allows for more expression than the comparable ATS type system. Even though ATS has variants of dependent types and also linear (perhaps affine?) types.