The Stream API has to be one of the ugliest warts in .NET, and it's been around since the beginning. I am so glad Microsoft finally addressed it. Every time I use Stream, I am reminded of how badly the Stream API violates SOLID principles.
I like how Microsoft approached the problem from below by introducing new types like Span<T> and Memory<T>, then the Pipes API. It shows that the future of the platform is in good hands.
I agree it would be nice to have a consistent interface. The problem is it's neither consistent nor an interface, it's an inconsistent hierarchy of subclasses. There's always fuss because everyone is going to get bitten by it at some point. It's just a poor abstraction, and it leaves a bad taste in your mouth as a library (well, framework) consumer.
Microsoft promised me that they gave me a thing that had certain features and capabilities using industry standard terminology and knowledge. There's a contract. If you go out for a car loan that says "0% APR for 12 months!" You expect that to be the first 12 months, not "0% APR only on days divisible by 7 during leap years, up to a total of 12 * 30 days over the course of the next millennium, otherwise 7.5%"
Contrast this with, say, C where there is nothing. Encryption would look vastly different to compression, but both are a similar abstraction: transformations. Now if you wanted to load that result into a device bitmap, you'd likely have to dump the entire stream into memory on onto disk - depending on what different pattern the other library you are using thinks about streams.
Go did a much better job out of the box, but you'd have a hard time convincing me that .Net streams weren't an inspiration there; especially given the nomenclature used.
Plenty of stuff for inspiration for.NET devs.
While true, at least it was less ugly than Java, and that was the initial design goal.
I agree though. Lots of things have changed and been further improved on since then, and maybe it was about time these parts got fixed up too.
A lot of these features evolved over time, so the fundamental building blocks might have been missing.
I am not sure....
That said, the number of projects I worked on where this new API would have made things so much easier is staggering. It is a shame we can't just fax this API back to our past selves.
The other big building block this uses is Span<T>/Memory<T> which is recent as in this year. Span<T>'s the sort of huge paradigm shift that likely would never have occurred to early .NET design, but starts to seem obvious in retrospect.
The future here looks bright!
Overall, pipelines have been really solid for me so far. Working out how to use it without documentation was a total pain though, hopefully they get that out soon. If anyone is interested I can throw the library up on GitHub if anyone wants some real world examples of using pipelines.
Im sure there is an example of connecting pipes together like this somewhere. Maybe in Kestrel or SignalR (Core)?
Last I checked, SignalR haven’t had a release in years, so I wouldn’t go there looking for news.
It is alive an under active development on .NET Core