Streams and Cutters - Day 28 - VaultStream
April 10, 2026•260 words
I've gotten back in to the groove of coding. I was first trying to emulate how a library was written from memory but once I stopped trying to write it their way, it all became a lot more easier. It's likely because I don't yet understand the nuances or powerful way of coding that they were doing.
Likely in a year or two, my code or library may drift closer to theirs or similar. The biggest things is that I'm based on streams where the data could be a larger amount then can fit into memory at a time. Say 1TiB or 2TiB's worth of data or something similar.
This has profound architectural implications that I've been attempting to ensure I don't get ahead of myself with. A perfect possibility is worth nothing compared to a rickety prototype. As a perfectionist it's easy to get caught up in algorithms and abstractions and forget to actually code, deal with harsh reality of complexities and exceptions.
Presently I've got a Stream which implements a Cutter. The Cutter is bound to the Stream in a partial lockstep. But designed in such a way that the Cutter doesn't know what the Stream does with the data. Making it perfect to swap out or treat the input, output and such as a whole stream itself! (Which I'm very proud of).
Basically the Stream will periodically return Chunks via the Iterator interface. The Cutter will return Boundaries which are then folded into the Chunks struct when it's emitted.
Quite beautiful and rather very proud of it.