Kanały IO vs czytnik/program czytający

Question

Odkąd Go ma kanały, zastanawiałem się, dlaczego standardowa biblioteka nie została zaprojektowana do używania ich również dla IO.

Zamiast tego są typy czytników i pisarzy, ale jaki byłby problem z używaniem kanałów?

Funkcja może zwrócić kanał z bajtów (zakładając, że jednobajtowe, a nawet jednobitowe powroty są zbyt mało wydajne) i przyjąć kanał dla żądań anulowania i kanał zgłaszania błędów.

-Najlepszy nowicjusz.

Answer 1

Kanały doskonale nadają się do komunikacji między goroutinami. Kiedy program robi coś prostego, jak na przykład czytanie stdin, robienie czegoś ze strumieniem i wyprowadzanie wyniku na stdout - używanie kanału jest przesadą, niepotrzebnie rażącą wydajność.

Dopóki średnia biblioteka nie udostępnia w jakimś miejscu czegoś konkretnego do goroutines komunikujących się ze sobą, nie ma dobry powód, aby modelować proste operacje, takie jak te z io.Reader lub io.Writer wykorzystaniem kanałów, odpowiednio do oparły kanał zestaw metod (API).

Dodatkowo w razie potrzeby prostą implementację można zawinąć w kanał, podczas gdy odwrotnie, "odinstaluj" implementację kanału z powrotem do jej prymitywu, nie jest możliwe. Również autorzy Go najwyraźniej lubią wyraźność, co prowadzi do tego, że wąskie gardła wydajności nie są ukrywane (i zaskakujące).