http4s
Renderable framework has become a misfit
In 0.21, when a request or response could contain modeled headers, it was possible to encode the entire HTTP/1 control data line and headers with a single StringBuilder, and then encode that to bytes in one pass. This is the basic approach still taken by both Ember and Blaze[^1]. However, since 0.22, each header value is first materialized in a Header.Raw, which defeats the single StringBuilder encoding.
The mechanism was inherited from the original Spray fork. Since we can no longer render to one builder, and have chosen not to render directly to binary, what's left is an obscure DSL over StringBuilder.
[^1]: this approach has won most CPU benchmarks I've thrown at it, but I suspect creating twice the necessary memory pressure, but that's a separate ticket
That ContravariantMonoidal was beautiful. I wish I could have made performance not dogshit.