streamly VS witch

https://github.com/composewell/streamly/issues/1307 seems related, but it was a long time ago. We weren't heavy users anyway, so our streaming philosophy is now "conduit if it's simple and plugging into a conduit-using library, streaming if you're doing complicated things".

Interesting! Which of the streamly modules is implementing that part? Is it one of the workLoop implementations in Streamly.Internal.Data.Stream.Async?

I want to like streamly, but the API is so huge, yet I feel like I'm doing things on a too low level of abstraction. (And as long as it needs a ghc plugin I doubt it'll become the de facto standard.) Though maybe I just haven't used it enough. It does have great docs at https://streamly.composewell.com/ and they seem to be taking both performance, dependency weight and API design quite seriously.

You missed streamly in your list of alternatives: https://github.com/composewell/streamly/blob/master/docs/streamly-vs-async.md

Thanks for mentioning Witch! I'm obviously biased because I wrote it, but it's a great library :)

See this issue for some discussion: https://github.com/tfausak/witch/issues/2

The witch package provides type classes for converting between arbitrary types: text, numbers, and anything else that people create instances for. It is therefore much more broadly applicable compared to TTC, which only works with text. I really appreciate that both a From type class (for conversion without failure) and a TryFrom type class (for conversion that may fail) are used, and the implementation looks very convenient. I will remember this project and use it when I have a suitable application in the future.