Rust as a gateway drug to Haskell

Re:Rust as a gateway drug to Haskell by lambdadmitry on Wednesday June 14, 2017 @07:41AM (#14552006)

I would argue that at least for client-server apps Erlang is faster. Here is why: in most cases the perceived performance of a server is constrained by maximum (or 99%, whatever) latency, not by throughput. Moreover, you can scale throughput horizontally, while scaling for latency is more or less impossible. Haskell's GC can give you horrendous pauses (see [1][2]), ruining perceived performance. Erlang, on the other hand, is thoroughly optimized for minimal latency.

TL;DR: "fast" isn't well-defined, and for a lot (or even most) applications "fast" is about latency, not throughput, and Erlang is "faster" in that sense.

[1] https://making.pusher.com/latency-working-set-ghc-gc-pick-tw...

[2] they eventually abandoned Haskell for Go https://making.pusher.com/golangs-real-time-gc-in-theory-and...

[ Parent | on HN ]

Re:Rust as a gateway drug to Haskell by Tarean on Wednesday June 14, 2017 @04:19PM (#14555781)

Yeah, the worst case of ghc's garbage collection is awful and can dwarf the actual work being done. That's the man driving factor behind adding linear types to haskell - they let long lived and large data live on a separate non-gced heap.

The other big part of this is that it can make stream fusion predictable. Currently haskell programs can become 100x slower or faster after some innocuous change, so linear types will make it a lot easier to write fast haskell in general.

http://blog.tweag.io/posts/2017-03-13-linear-types.html

[ Parent | on HN ]