Sì, grazie per il riassunto... è più o meno come pensavo.
Detto così a naso, non penso che sia un concetto molto attraente nel mondo delle "normali" applicazioni crud con gui (thread o no). La foresta dei listener non è praticamente mai così complicata da diventare ingovernabile, e i gui framework hanno sviluppato strategie abbastanza robuste per fare le cose a botte di observer/listener (vedi signal/slot nelle qt, o il sistema di eventi delle wx). Ovviamente, è sicuramente possible costruire un'applicazione gui "difficile" abbastanza da farti sentire la mancanza di qualcosa di più evoluto... Certo dovrei leggere il libro per vedere se fanno degli esempi delle architetture troppo complesse di cui erano insoddisfatti e per cui hanno sviluppato frp.

Si, dovresti. Ma ti vedo molto prevenuto. A me la cosa che mi ha attrattato e' che il codice prende un aspetto che secondo me e' quello che avrebbe sempre dovuto avere.
E' chiaro che "per cose semplici" probabilmente me la cavo anche senza. Ehi... ma me la cavo anche a scrivere C invece che Python. Questo non vuole dire che *preferisca* scrivere C. Anzi, in generale preferiro' lavorare in Go. Ahem, Python.

tipo appunto Go per avere delle basi un po' più solide sulla concurrency.

Uhm... interessante. Pero' vorrei fare notare una cosa. Il problema di "concorrenza" e' un problema molto vasto.
Go ha un approccio (buono) e c'e' molta attenzione per fare le cose bene, ma "alla Go".
Insomma, se hai gia' una buona comprensione dello spazio e vuoi vedere come si fanno le cose in Go, e' un'ottima cosa.

Se vuoi vedere un buon modo di fare le cose, allora ancora una volta Go e' un'ottima cosa.

Se pero' il punto e' "diventare forte sulle problematiche di concorrenza", quello che vedi in Go e' solo *un* approccio. Fra quelli buoni.
Pero' il fatto e' che Go e' anche pragmatico (chesso', nonostante hai i channel, i Mutex te li fanno vedere abbastanza presto e ti fanno vedere come usarli). Non e' che ti dicono: questa e' una feature esoterica non usarla mai. Ti dicono: quando puoi usa i channel. Ma non ti "insegnano" dove e' il tradeoff fra soluzione con i channel troppo complicata e quando basta un po' di "mutex e compagnia". Sta alla tua esperienza capire quando devi fare le cose con le mani e quando usare i chan. Poi i chan sono una primitiva brillante... perche' hai la scelta fra chan buffered e no (qui un po' la differenza te la spiegano, ma non e' che ti spiegano tantissimo come scegliere). E non ti fanno davvero vedere che il fatto che un chan chiuso in scrittura e' pure quello un modo di mandare segnali fra coroutine (da quel momento in poi, il chan ti tornera' lo zero value del suo tipo... quindi puoi riconoscere che il chan e' stato chiuso (e non blocchera' mai piu).

Insomma, secondo me devi *anche* farti le ossa sul problema esteso, non solo sulla visione di Go sullo stesso. e potenzialmente, sebbene le risorse per Go siano ottime, potresti farti una visione biased del problema. Che non e' un problema se l'obiettivo e': scrivere applicazioni con molta concorrenza in modo sano (Go grosso modo ti mette sulla strada giusta). Ma se il problema reale e' "capire cosa nasconde il problema della concorrenza, tecniche, gotcha e compagnia", avere solo il punto di vista di Go potrebbe essere limitante.