bytestring VS pool-conduit

The documentation is itself fairly funny, for those who don’t care to click ahead:

> This "function" has a superficial similarity to ‘unsafePerformIO’ but it is in fact a malevolent agent of chaos. It unpicks the seams of reality (and the IO monad) so that the normal rules no longer apply. It lulls you into thinking it is reasonable, but when you are not looking it stabs you in the back and aliases all of your mutable buffers. The carcass of many a seasoned Haskell programmer lie strewn at its feet.

> Witness the trail of destruction:

    https://github.com/haskell/bytestring/commit/71c4b438c675aa360c79d79acc9a491e7bbc26e7

If you bring in efficient strings from bytestring, densely packed arrays from vector, and an in-place sort from vector-algorithms, you can bring it down to 275ms (uses 19MB of mem).

bytestring

Note that this release is broken for Windows.

I've opened https://github.com/haskell/bytestring/issues/455 so the situation can be improved. You're very welcome to chime in on the discussion or to contribute some of the missing documentation yourself! :)

Highlights from the changelog:

Well, ByteString in particular should not have an IsString instance in a new report. That's pretty clear by https://github.com/haskell/bytestring/issues/140 : the concensus is that there is no good solution right now, but it should not have gotten an IsString instance in the first place. If a theoretical new Haskell Report 202x includes OverloadedStrings (as it should) to handle string literals analogously to numeric literals, I'd expect it to not give ByteString (which is really just a collection of octets) an IsString instance, with all it's issues and rattail due to the encoding question being implicitized.

Standard streaming libraries. They are being written by people that make the effort to understand performance and I have a hope that they make sure their streams run in linear space under any optimizations. It is curious and unsettling that we have standard lazy text and byte streams at the same time — and the default lazy lists, of course. I have been doing some work on byte streams and what I found out is that there is no way to check that your folds are actually space constant even if the value in question is a primitive, like say a byte — thunks may explode and then collapse over the run time of a single computation, defying any effort at inspection.

I understand that the "new" version of Persistent requires Servant Handler to be MonadUnliftIO which is not the case. I also understand that I am suppose to use acquireSqlConn somehowe (following this this), but I can't figure it out. Any ideas ?

I don't think there's any malicious intent. It seems pretty clear that the motivation here is to simplify the type checker considerably, which is a really good reason to do something. Heck, I've got an open issue for deleting a feature in persistent which (according to the lack of comments on the issue) only ever used by persistent's own test suite.

PR submitted: https://github.com/yesodweb/persistent/pull/1366 :)

Ha, I spotted a possible resource leak here. If stmtFinalize fail, then the connection won't be closed.

text Cloning b1e32adfe1da49cd9df997a13bd0c5b391486f5c from https://github.com/yesodweb/persistent.git No cabal file found for Repo from https://github.com/yesodweb/persistent.git, commit b1e32adfe1da49cd9df997a13bd0c5b391486f5c