> A side effect of the clumsy Streams API in dotnet is that the antipattern of reading a Stream into memory (e.g. with a MemoryStream) is prevalent - we’re guil

> A side effect of the clumsy Streams API in dotnet is that the antipattern of reading a Stream into memory (e.g. with a MemoryStream) is prevalent - we’re guilty of it ourselves, in places. This seems a little unfair to compare bad C# practises to good Go practises. Of course, if you unnecessarily load data into byte arrays, GC is going to be a problem. But you don't have to do that. Even if you're using some 3rd party API that doesn't support streams, you might be able to use pooled byte arrays, or even pass a stackalloc'd Span for small data. The author does a lot of hand-waving about 3rd party libraries, but since they don't actually name them, it's impossible to comment on that This has very seldom been a problem for me personally, but it might depend on the 3rd party libraries that you use - the author does a lot of hand-waving about 3rd party libraries, but since they don't actually name them, it's impossible to comment on that. > There’s also the fact that even idle dotnet processes can consume hundreds of MB of memory This is contrived; it's only true if those idle processes were previously doing a lot of work that made a lot of allocations.