IO-Kanäle vs Leser/Schreiber

Question

Da Go Kanäle hat, habe ich mich gefragt, warum die Standard-Bibliothek nicht entworfen worden ist, um sie auch für IO zu verwenden.

Dafür gibt es Lese- und Schreibtypen, aber was wäre das Problem bei der Verwendung von Kanälen?

Eine Funktion könnte einen Kanal von Byte-Slices zurückgeben (unter der Annahme, dass Einzelbyte- oder sogar Einzelbit-Returns zu ineffizient sind) und einen Kanal für Löschungsanforderungen und einen Kanal für Fehlerberichte aufnehmen.

-Der neugierige Go Novize.

Answer 1

Kanäle sind eine gute Lösung für die Kommunikation zwischen den Goroutines. Wenn ein Programm etwas Einfaches tut, wie zum Beispiel das Lesen von stdin, etwas mit dem Stream macht und das Ergebnis in stdout ausgibt - dann ist die Verwendung eines Kanals ein Overkill, was die Performance unnötig beeinträchtigt.

Solange die Standardbibliothek nicht spezifisch für goroutines in einem Ort etwas nicht bieten, miteinander zu kommunizieren, gibt es keinen guten Grund, einfache Vorgänge zu modellieren, wie die von io.Reader oder io.Writer unter Verwendung von Kanälen, jeweils ein Kanal auf Basis hat Methodensatz (API).

Zusätzlich, wo erforderlich, kann die einfache Implementierung in einen Kanal gehüllt werden, während das Gegenteil, um eine Kanalimplementierung zurück zu seinem Primitiv zu "entpacken", nicht möglich ist. Go-Autoren mögen Offenheit offensichtlich, was dazu führt, dass Leistungsengpässe nicht verborgen (und überraschend) sind.