Move away from streamly?

[hasufell]

Streamly has been rather difficult to maintain:

• it breaks API often, requiring major updates/rewrites
  • Update streamly to the latest master hasufell/streamly-yaml#5
• it makes improper use of cabal flags, which has been communicated several times to the maintainers
  • Educate (or prevent) users from making flag-dependent API cabal#8128
• sometimes older releases are incompatible with new GHC versions and the compatiblity patch is mushed into the next major API version, giving no room for minimal updates
  • Build streamly with ghc-9.6.1 composewell/streamly#2415 (comment)
• currently doesn't build for us at all with GHC-9.6.5:
  • 0.10.1 fails to build with transformers 0.5.6.2 composewell/streamly#2738
  • 0.10.1 fails to build with +use-unliftio composewell/streamly#2739
• I have to maintain streamly variants of libyaml to avoid unnecessarily depending on e.g. conduit:
  • https://hackage.haskell.org/package/yaml-streamly

All this is maintenance cost. At the moment I don't see the advantage of using streamly anymore. I'm thinking to move to another streaming framework, maybe back to conduit.

[harendra-kumar]

We spend significant amount of time in trying to maintain backward compatibility and make it easier to migrate. We only make breaking changes to released APIs in major versions. All of your problems described above are because of using experimental and internal APIs which are subject to change.

it breaks API often, requiring major updates/rewrites

You used parser APIs extensively which were being developed, not released and were internal only at that time. But we offered to make changes and did make changes to streamly-yaml to migrate it to the released versions of the APIs.

it makes improper use of cabal flags, which has been communicated several times to the maintainers

I disagree with this. There are some build flags which are meant for development and testing purposes and end users are not supposed to use those.

sometimes older releases are incompatible with new GHC versions and the compatiblity patch is mushed into the next major API version, giving no room for minimal updates

The breakage was due to a breaking change in the transformers library, not because of a change in streamly.

composewell/streamly#2739

use_unliftio is an internal developers-only flag and is not supposed to be used by users.

I have to maintain streamly variants of libyaml to avoid unnecessarily depending on e.g. conduit:

We have sent PRs in the past to make streamly related to changes to this library and we will continue to help in future if needed. However, I understand that as a maintainer it is your decision to use or not use the library based on whatever you deem fit.

[hasufell]

Thanks for the support, but I decided to move to conduit, since my use of streams is very narrow and building across many GHC versions is a higher priority for this project.