On the topic of IO. I'm actually a fan of java.io.Reader/Writer and java.io.InputStream/OutputStream. It seems to me that most java protocols and parsers are quite composable by default due to these simple little abstractions. Granted, they might not be a good fit for async IO, but I'd still argue that they've held up quite well during the past fifteen years. I'll go out on a limb and claim that standard C++ IO haven't worked out quite as well, although it might just be my skip-the-oo-and-template-everything skepticism. Rust seems closer to java, although I feel like the Jury's still out. I'm not a enthusiastic of doing everything asynchronously as in Node. Haskell does seem to get the composability right.

Python has some of javas thinking through a standard convention on the method names for reading and writing (an interface!), but it seems common with departures from those simple rules when people get creative. From that perspective, an initiative like this is quite understandable and convenient. Nevertheless, I don't seem to feel the need in the same way in certain other languages.

A little off-topic but IMO one of the more unfortunate decisions by Java was Reader/Writer and InputStream/OutputStream, instead of CharReader/CharWriter and ByteReader/ByteWriter (or similar).

It turns out TLS isn't that bad.

OpenSSL exposes a "memory BIO", which is basically exactly this. You send in writes, and then emit data when you can, and in the meantime it buffers.

It's a bit more limited than that, but generally speaking it's not too bad.

I assume you handle decompression the same way? Feed in data, and the decompressor emits data when it can?