It would be nice to be able to compress responses with gzip in basic-webserver. I know this could be implemented by the platform, but it seems like it would be nice to have a pure Roc implementation of gzip so it could be reused and would not have to be exposed across multiple platforms. Does that sound right? Is there anything else I should be thinking about?
That sounds right to me. I have no idea how complicated that would be to implement though
Sounds pretty reasonable. Always a little concerned about fine grain byte twiddling that might happen. Cause this should be solid perf in roc, but if it is running on every single web request, the extra perf from platform langauges feels nice too.
Like 3% slower web requests can actually lead to a much earlier slump under load.
Right that makes sense. Even if some platforms choose to expose an implementation from another language, it would still be nice to have one implemented in Roc for other use cases
I think it's totally worth it for a lot of applications. If perf is a concern you can always pass that off to the platform.
Maybe this would be a good package to think about for roc performance tooling?
Yeah, I definitely think we can close most of the gap. Just still can be a high cost when thinking about scale...the fun of scale.
But yeah would be useful.
Also, basic compression might be useful for the book, but idk.
Also, basic compression might be useful for the book, but idk.
I was thinking the same thing. Do you know of any good algorithms that would be reasonable in scope?
Probably best would be one of the super simple cores of the lz algorithms that is basically a windowed lookup.
Though maybe that is less applicable to general users than parsers and things of that nature
I think it could still definitely fit because devs use compression all the time but I would guess frequently don't know that much about how it works under the hood
fair
I would probably target LZ77
maybe slightly simplified if needed
I believe gzip uses LZ77 so that's nice too
IIRC, It uses deflate which has a ton more on top of it.
eh, not a ton, but definitely a solid bit more complex
Right, I'm just saying its a component of it
If it is compressed in roc using LZ77, could another program detect that and decompress it?
I don't think you would be able to detect it automatically, but another program could definitely decompress it if it knows the format from the get go
I created an issue for the book here: https://github.com/roc-lang/book-of-examples/issues/48
With a header, you probably could lie about Huffman encoding and some how get gzip to do it....otherwise a decode for lz77 is also very simple
Just found @Folkert de Vries's elm-tiny-inflate which implements deflate.
Also maybe relevant, @Shritesh Bhattarai implemented the CRC32 and Adler32 in roc-image.
Cool! I know crc32 is also needed for gzip
I've also been working on https://github.com/memorysafety/zlib-rs recently, so I'm quite familiar with the implementation details
though it's hard to strike a balance here between simplicity and efficiency
Last updated: Jul 06 2025 at 12:14 UTC