[LukeHoersten]

I've actually found the exact opposite. The library ecosystem is rich and mature. Haskell is, by default, "concurrency safe" because of referential transparency. You can safely "async" and compose almost any library in the Haskell ecosystem without worrying about shared memory etc underneath.

Also, a lot of the really common libraries like text, attoparsec (parsers), aeson, networking, etc are highly tuned for low latency and performance. Many use compiler rewrite rules and techniques called stream-fusion to compact a lot of the machine code away. Also aggressive inlining etc can be done.

I'm sure there are some memory-heavy or poorly optimized libraries out there but that's certainly not the norm. I've had no problems with the libraries off-the-rack.

[windlep]

I actually thought that too, but I guess that's not the case. I helped write some HTTP2 frame-parsers for Haskell using attoparsec, but apparently it wasn't fast enough as the lib author later rewrote all the attoparsec code to use pointers to the underlying byte buffers.

https://github.com/kazu-yamamoto/http2/commit/0a3b03a22df1ca...

The stream fusion stuff is sweet, but not exactly unique to Haskell since any language with good iterator/generator abstractions have similar constant-time memory characteristics.

[zoybert]

I believe you're misunderstanding what stream fusion is. A language compiler does not really need "good iterator/generator abstractions" more than a guarantee of side-effect free transformations in order to be able to de-forest the intermediate data structures. http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.104.7...

[windlep]

I meant more that languages with an iterator/generator usually have similar constant space usage. That is a drastic oversimplification of stream fusion and fails to mention other practical outcomes as you mention, along with a variety of optimizations.

I found this posting a little more approachable to seeing the various optimizations possible with stream fusion: https://donsbot.wordpress.com/2008/06/04/haskell-as-fast-as-...