This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-10-24
Channels
- # aws (7)
- # aws-lambda (3)
- # beginners (65)
- # boot (43)
- # cider (7)
- # cljs-dev (12)
- # cljsrn (15)
- # clojure (284)
- # clojure-austin (32)
- # clojure-brasil (4)
- # clojure-dusseldorf (4)
- # clojure-germany (1)
- # clojure-italy (40)
- # clojure-spec (21)
- # clojure-uk (69)
- # clojurescript (97)
- # core-async (11)
- # cursive (19)
- # data-science (1)
- # datascript (6)
- # datomic (30)
- # dirac (2)
- # emacs (4)
- # events (2)
- # fulcro (76)
- # graphql (38)
- # juxt (1)
- # lein-figwheel (1)
- # leiningen (6)
- # luminus (4)
- # lumo (13)
- # mount (4)
- # off-topic (24)
- # om (28)
- # onyx (32)
- # other-languages (1)
- # parinfer (40)
- # pedestal (1)
- # portkey (47)
- # re-frame (21)
- # reagent (4)
- # ring (4)
- # ring-swagger (3)
- # rum (1)
- # shadow-cljs (115)
- # spacemacs (5)
- # sql (14)
- # unrepl (1)
- # yada (3)
@reborg c'è stato un talk bellissimo riguardo la fusion a ClojuTRE di quest'anno (in realtà era la Small FP Conf dentro ClojuTRE)
@nilrecurring pensi che ci sia qualcosa da estrapolare per clojure dai stream fusion?
Ci sono state un po’ di domande in stile “ma che differenza c’è con i transducers?”
Il punto della fusion è che il compilatore di occupa di riscrivere effettivamente il codice (nel talk è spiegato molto bene)
E le diverse astrazioni che coinvolgono uno “streamable” possono essere adattate alla fusion
Non credo sia lo stesso per i transducers?
non c'e' riscrittura (quella sarebbe una macro), e' pura e semplice astrazione funzionale. Il pattern OO piu' vicino ai xducers e' chain of responsibilities (per intenderci)
L’ho sentito solo un’altra volta, e non ricordo dove. Ne senti parlare bene o male? 😄
[troll]Vaadin: prendi l'anima di GWT, vendila al demonio e costruiscici il marketing attorno [/troll]
ciao a tutti, la fusione e' come quella di Dragonball? Connetto le dita e si viaggia 😄
Stream fusion e' semplicemente un sistema automatico di deforestazione basato su trasformazioni di uguaglianza, qual e' il problema? 🙂
volevo chiedere qui se qualcuno di voi usa the "Unified Log" pattern, come Kafka, ma senza Kafka 😄
non voglio usare Java e sto cercando un "append-only" database
Temo che Kafka sia l’opzione più viabile per avere unified-log ultimamente
Noi stiamo pensando di usare Google Cloud PubSub, ma tiene il log solo per 1 mese
stiamo pensando di fare una cosa simile in AWS...senza pero' deploy di Kafka, non ci piace Java...
ok perfetto
un mese non e' male, Kinesis mi pare tenga per una settimana
Quindi non va proprio bene per “unified log”, a meno che non hai un consumer che scrive tutto su un bucket così non perdi nulla
Però se hai poi necessità di andarti a vedere il log di un po’ di tempo fa, diventa lento
Quindi boh, dipende dallo use case
afaik @skuro sta usando Kafka con successo
c'e' stata chiacchera di corridoio alla conj riguardante un possibile equivalente di kafka per clojuristi che non vogliono uno zookeper nel cluster
eh ho trovato un progetto in go in realta'
gia' !
Noi usiamo kafka pesantemente a funding circle
È stata dura all'inizio ma adesso sembrano tutti content
Con un po' di semplici wrapper si possono scrivere funzioni pure
@nilrecurring talk un po' difficile per me, ma grazie per il link. Sembra giustificare l'ottimizzazione (stream fusion) per produrre codice componibile e allo stesso tempo garantire l'ordine dei side effects. E' un problema interessante, ma cosa ci fanno side effects in mezzo a sequence processing? Per usarli devo riscrivermi map e amici. Senno' uso librerie che li hanno dentro (e.g. conduit). Sembra che streamf sia esterno ad haskell. Rispetto a Clojure xforms, streamf mi sembra che richieda piu' commitment.
@andrea.crotti non e' per le funzioni pure, stiamo proprio cercando di evitare JVM come la peste qui 😄