5
Core.async è un sostituto di Lamina o intende sostituire la Lamina?Clojure core.async e Lamina
In caso contrario, ci sono situazioni chiare in cui uno è preferibile rispetto all'altro?
A
risposta
13
Sono l'autore di Lamina. Penso che core.async sia una libreria ben fatta, con molta più chiarezza nel design rispetto a Lamina. Ci sono cose a cui penso che Lamina sia migliore, principalmente legate all'introspezione, alle prestazioni e all'estendibilità.
Il grosso problema che ho con core.async è che oltre a un'astrazione di flusso, porta con sé un modello di esecuzione (tutto avviene nei pool di thread core.async), il che significa che se lo si utilizza ovunque, vincola la progettazione e l'implementazione di tutto il resto nella base di codice.
Ho visto un certo numero di librerie "asincrone" create che espongono i flussi come canali core.async, il che significa che è possibile utilizzare le librerie solo se si ha dimestichezza con il modello di esecuzione core.async.
Sto per rilasciare una libreria che tenta di essere una rappresentazione del flusso "minima" che può essere utilizzata al posto di core.async, Lamina, code di blocco Java, ecc. Chiamate Manifold. Un flusso di manifold può essere forzato a un canale core.async, a un canale Lamina e così via, e una di queste cose può essere reinserita in un flusso di manifold.
Penso che il paesaggio "asincrono" sia ancora piuttosto giovane, e ci sono molti problemi inesplorati. quanto sono efficaci le astrazioni, quanto sono facili da eseguire il debug in produzione e così via. La JVM offre molti strumenti per l'introspezione, ma dal momento che i meccanismi asincroni utilizzano un modello di esecuzione completo e completo, stiamo praticamente ricominciando da capo. Non ti direi di usare Lamina su core.async, ma vorrei sottolineare che core.async è un'astrazione a livello di applicazione, non a livello di libreria.
+0
Grazie mille per questo, sempre meglio ascoltare gli autori. Non mi sono reso conto di core.async e una buona cosa da considerare. Leggerò il documento logico per Manifold, ma è un po 'tardi il venerdì ora :) – shmish111
+0
Il collettore sembra buono, certamente, ma ho ancora bisogno di fare una scelta dietro di esso. Sembra tuttavia che Lamina e core.async probabilmente rimangano entrambi come strategie diverse per lo stesso obiettivo finale. Penso che giocherò di più con Lamina poiché è già nella nostra base di codice, tuttavia core.async mi ha permesso di avvolgere semplicemente qualcosa in un blocco di go e di vedere un enorme aumento delle prestazioni, senza dover cambiare il modo in cui penso a quel pezzo di codice. – shmish111
+0
Ora vedo che la Lamina è stata deprecata.In questo momento sto utilizzando Manifold per un client Kafka, mi sembra una scelta perfetta perché posso creare una libreria semplice che restituisca un flusso e le persone possano usarlo come vogliono, come un canale, un seq, un flusso variegato ecc. (supponendo che funzioni :))! – shmish111
3
core.async e Lamina sono due progetti diversi e non sono destinati a sostituire l'un l'altro. In realtà, potrebbero giocare bene insieme -se tu vuoi--
Lamina è un approccio orientato al flusso, mentre core.async è orientato ai messaggi.
Quale utilizzare dipende da voi. In Lamina, la cosa importante sono i callback che definisci per il canale, mentre in core.async, i canali e i blocchi go sono disaccoppiati, e questo è più flessibile e modulare.
+0
Ok, quindi immagino che i creatori di core.async pensino che sia un modo migliore di fare le cose rispetto a Lamina, no? – shmish111
+0
@ shmish111 Non so, meglio chiedergli :) Data la mia risposta, non intendevo core.async è meglio di Lamina – Chiron
+0
Ho detto che avevo appena visto il discorso di Rich Hickey su core.async;) – shmish111
I molti sapori della concorrenza in Clojure possono essere interessanti - http://adambard.com/blog/clojure-concurrency-smorgasbord/ – edbond
Ho visto che, sebbene fosse un ottimo articolo, era un po 'troppo bello per rispondere alla mia domanda, penso. – shmish111