I have often thought perhaps about 50% of Go's success in the high-power network space has little to do with any of its headline features and more to do with the fact that it shipped with the "io.Reader" and "io.Writer" interface from the get-go in the standard library, and as a result, the entire ecosystem tends to support working in the io.Reader and io.Writer interface. One of the joys of working with networking in Go is picking up some half-obscure library like a JSON validator or some obscure encryption/decryption library and finding out that it defaults to stream processing, because it uses Reader/Writer correctly, and the byte-array or string interface is just a convenience wrapper around the stream processing. Anyone who posts a string- or byte-array-only library to some Go discovery mailing list or message board where there isn't a good reason to have it take only those things will get as their first piece of feedback that they should convert the library to be based on Reader/Writer.

There is almost no technical reason any current popular language couldn't work this way. (Though C has some serious challenges with its anemic memory management system, pretty much anything else can do this.) It is all to the culture of the language community, rather than the language itself, and a sort of inductive process of "all previous N libraries worked on strings, so the person writing the N+1'th library also wrote it work on strings". It is one of the problems I have when going back to Python for the sort of work I've done... it only takes one library in a pipeline to work solely on strings to ruin the ability to stream process for the entire pipeline.

(Note this isn't a praise of Go qua Go; again, almost any language is technically capable of pulling this off. It's the libraries that accumulate in a community based on strings, and the problem where it only takes one library in your stack to be based on strings to make stream programming impossible meaning that they tend to "pollute" the community library culture if you don't start from the beginning with stream processing in mind. Otherwise a language community ends up having to create a whole parallel library ecosystem based on stream processing, like Twisted used to be for Python, and that parallel ecosystem is never quite able to keep up with the main one. There are other language communities that also do this successfully, I think, but there are certain communities where the language is perfectly capable of streaming but libraries tend to be written against fully-manifested strings.)