Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Two big surprises from this article:

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!



There is no clear winner. Haskell wins on having a powerful type system and producing generally efficient code. Erlang wins the maintenance-race by far since you can trace on the running system and deploy code while it is running. And the fact that Erlang is built to be robust over fast.

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.


Memory leaks due to laziness are not as frequent as the interwebs would tell you. It's not like that this type of code appears in every single program you write.

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.


The memory leaks I had to work around in combinatorrent were extremely subtle:

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.


What leak-debugging tools did you use?


GHC has a very nice memory profiler in the runtime. You just enable that one and then it has rules to constrain views of allocation data. Profiling by "anything of type X" usually helps to narrow down a specific place in the code which has trouble. Also, splitting by module helps since it can tell you where in the code base you have the leak.

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.


What did Erlang lost? I thought he stated that both did reasonable well.

Author chose Haskell cause of static type but most of his subsequence posts are Erlang. I'd say Erlang won him ha.


The bias is also that I work professionally with Erlang.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: