I/O canali vs lettore/scrittore

Question

Poiché Go ha canali, mi chiedevo perché la libreria standard non sembra essere stata progettata per usarli anche per IO.

Esistono invece tipi di lettori e scrittori, ma quale sarebbe il problema con l'utilizzo dei canali?

Una funzione può restituire un canale di porzioni di byte (presupponendo che i ritorni a byte singolo o anche a bit singolo siano troppo inefficienti) e includa un canale per le richieste di annullamento e un canale per la segnalazione degli errori.

-Il curioso Go novizio.

Answer 1

I canali sono adatti per la comunicazione tra le goroutine. Quando un programma fa qualcosa di semplice, come ad esempio leggere lo stdin, fare qualcosa con lo stream ed emettere il risultato su stdout, quindi usare un canale è un'esibizione eccessiva e inutilmente dannosa.

Finché la libreria standard non fornisce in qualche luogo qualcosa di specifico per goroutines comunicanti tra loro, non c'è nessuna buona ragione per modellare operazioni semplici, come quelli di io.Reader o io.Writer utilizzando i canali, rispettivamente di aver basato un canale set di metodi (API).

Inoltre, laddove necessario, l'implementazione semplice può essere racchiusa in un canale, mentre l'opposto, per "scartare" l'implementazione di un canale fino alla sua primitiva non è possibile. Inoltre, gli autori di Go evidentemente come explicitness, portano a colli di bottiglia delle prestazioni non nascosti (e sorprendenti).