large-records VS amazonka

Good question! I checked, and no, they are currently discarded. I think that's fixable. I've opened a ticked at https://github.com/well-typed/large-records/issues/80 .

Also: maybe you already knew GHC.Generics instances had superlinear compilation time, but betcha you didn't know even normal records themselves had superlinear compilation time. At least I didn't know until Edsko's super-recent investigation (resulting in yet-unreleased https://github.com/well-typed/large-records)

This is perhaps not as obvious as it could be. A penny for your thoughts? https://github.com/brendanhay/amazonka/issues/968

Most of our tech stack is built on Free and Open Source Software, and we give back wherever we can - either by upstreaming fixes or publishing libraries. In the Haskell world, we’ve open-sourced wai-handler-hal and aws-arn, made significant contributions to amazonka and we have more on the way. If you’re interested, here’s our applications page. If you have questions, you can ask them here or email [[email protected]](mailto:[email protected]).

Stack does not clone a copy of a git package for each of a user's projects that uses the package but cabal does. This can be a deal-breaker for cabal when using huge git projects like https://github.com/brendanhay/amazonka that can take forever to git clone. If you have a test/CI setup for a project that uses such packages, cabal's lack of caching can also cause huge delays and more opportunities for failure (from network errors or timeouts). From the proceedings of past issues, I don't think cabal devs are interested in addressing this use case. https://github.com/haskell/cabal/issues/5586

amazonka is a bit of a minefield despite being listed as the only AWS library by SOTU