Morn, morn

Morn!

God morgen!

God morgen!

Morgon

god morgen 👋

Møøørn, ørn, øøørn! girspak

Hvor ofte har dere fått bruk for core.async Channels i virkeligheten? :thinking_face:

4-5 ggr kanske

Finns use cases där de är väldigt nyttiga

Men sören vad lätt det är att skjuta sig i foten

Ganske mange ganger. Men det er ikke det første verktøyet du strekker deg etter. Jeg bruker dem stort sett til å bygge "maskineri". Men som @emil0r sier - de kommer med skarpe kanter, så bruk med måte 😅

Jeg kom over https://github.com/unclebob/turtle-graphics/blob/main/src/turtle_graphics/turtle_commands.clj i dag og ble litt nysgjerrig på det. "Hoi! Hva er dette? Dafuq betyr >!! mon tro?"

En ting du ihvertfall skal ha i bakhodet er at du bør ha så lite kode som mulig inne i go-makroer. Den makroen skriver om koden din ganske grassalt, så debugging er mer eller mindre umulig. Små go-blokker som kaller på "streite" funksjoner er ålreit. Og være EKSTREMT paranoid på feilhåndtering (catch) og lukking+draining av kanaler, pass opp for ressurser som lekker osv.

☝️:skin-tone-2: Allt det. Och var ännu mer paranoiod än EKSTREMT ;)

Jeg er kjent med f.eks. RabbitMQ, Kafka og Azure Service Bus. Ved første øyekast og helt naivt fremstod det som noe i samme nabolag.

Profilers är väldigt nyttiga för att se att kanaler stängs korrekt

Det är väl samma tankegods

@leif.eric.fredheim ja, men mer lokalt, om du vil

consumers och producers

Vet du om de kommer uppdatera för Java 21 och Project Loom?

@christian767

Har ikke helt oversikt. Så Alex skrev noe om loom, men hva det gjaldt vet jeg ikke. core.async har fått skuffende lite kjærlighet de siste årene

Når man har et problem hvor en typisk ville brukt en "message queue" (RabbitMQ) eller "streaming dings" (Kafka), pleier Clojure folket å bruke core.async istedenfor da, eller? Hvis det kun handler om "internleamikk" i sitt eget system, typ ikke kommunikasjon med eksterne applikasjoner.

Det är en implementationsdetalj Leif, men just nu så är core.async bundet till en thread pool på 8 threads

Om du har något som är blocking så kan du lätt sluka upp hela threadpoolen

@leif.eric.fredheim core.async er ikke noen erstatning for kafka, nei. Men du kunne brukt core.async til å konsummere fra kafka

core.async brukes til å bygge maskiner i prosessen din

Jeg får litt feelings av Erlang/OTP-aktig "actor model" også når jeg leser om dette, men sentralisert og i mye mindre skala (i Erlang kan man ha mange hundre tusen eller flere millioner "lettvektsprosesser" med en egen "innboks" som kjører på forskjellige fysiske nettverk/maskiner).

Eksempler på bruk av core.async fra mine prosjekter: Orkestrere asynkrone ting som skjer som resultat av endringer i filsystemet, parallellisere I/O, intern pubsub-kanal for å decouple deler av appen

ref loom: https://clojurians.slack.com/archives/C05423W6H/p1677676131782299

core.async bør bare brukes i ett tilfelle: når du skjønner at det du trenger er en maskin, ikke en funksjon.

og når du er i en så prekær situasjon, så er det god hjelp å få i core.async 😅

Maskin som i "https://en.wikipedia.org/wiki/Finite-state_machine," typ?

ja, det er en okay måte å tenke på det, men jeg vil si at det er mange måter å få bruk for state machine-patternet også utover core.async

Jeg oppdaget forresten https://clojure.org/about/state#actors som var opplysende for en tidligere Erlang-entusiast. > "Clojure is a functional language that explicitly supports programs as models and provides robust and easy-to-use facilities for managing identity and state in a single process in the face of concurrency. […] Clojure may eventually support the actor model for distributed programming, paying the price only when distribution is required, but I think it is quite cumbersome for same-process programming." Dette var en fin analogi: > "This is a world in which everyone sits in a windowless room and communicates only by mail."

jag har använt core.async ganska mycket. Det har inte alls samma användningsområden som tex Kafka eller RabbitMQ, tycker jag. Kafka är ju ett sätt att lösa persistens, vilket core.async inte är. Core.async är som bäst när man behöver kod som väntar på flera saker, eller ska välja till exempel att ta från en channel eller göra en time-out. Det är alltså alt som jag tycker är "the secret sauce" i core.async. Det jag lärde mig mest av var att följa de här kodexemplen: https://github.com/halgari/clojure-conj-2013-core.async-examples

Om man är intresserad av Erlangs OTP-modell finns detta: https://github.com/suprematic/otplike jag har aldrig själv använt det, men det använder Core.async för att sätta upp kommunikationen mellan olika processer. Centralt är att den har en trädstruktur med en översta processhanterare.

Det är också sant att exceptionhanteringen helt enkelt inte fungerar i core.async. Ett sätt att lösa det är till exempel som pedestals interceptorer, som antingen kan returnera en contextmap eller en core.async-channel (som blir ungefär som ett promise, svaret i form av en contextmap förväntas läggas på channeln när det finns). I interceptor-hanteringen (som i princip är en explicit callstack, eftersom ju JVM:en inte tillåter att en jobbar med callstacken, som gjorts asynkron med core.async) omgärdar man hela hanteringen av interceptorfunktionen med en catch Throwable, en lite bättre med core.match-baserad felhantering (som sägs vara inspirerad av IBMs språk X10) samt hanterar scoopet för dynamiska variabler automatiskt: https://github.com/pedestal/pedestal/blob/master/interceptor/src/io/pedestal/interceptor/chain.clj Denna mekanism har jag använt utanför requesthanteringen för att göra vissa sidoeffekter utanför själva requesthanteringen i pedestal - interceptorramverket är egentligen ganska generellt. Det är också ganska långsamt, jämfört med en JVM-stack. Dock kräver inceptorerna mer tydligt en ingång och en utgång än vad "rå" core.async skulle kunna ge.

Även David Nolen har gett några riktigt bra exempel på när Core.async är väldigt kraftfullt för vanliga praktiska problem: http://swannodette.github.io/2013/07/12/communicating-sequential-processes/

Nå gikk det opp for meg hvor awesome Clojure er på det som ofte kalles ELT eller ETL eller Data Engineering. Bedrifter bruker stort sett visuelle verktøy som f.eks. https://www.snowflake.com/en/, https://www.matillion.com/technology-partners/snowflake, https://www.getdbt.com/product/what-is-dbt, https://airflow.apache.org, https://www.snaplogic.com, https://www.alteryx.com, https://www.tableau.com/products/prep, etc. Det kan være "scheduled batch jobs" eller streaming. Et problem er at slike GUI-baserte "low-code verktøy" produserer proprietære artefakter som er vanskelige å versjonere og samarbeide på, og en er begrenset til "komponentene" som tilbys av disse verktøyene. Channels og Transducers er jo helt nydelig til sånt (i tillegg til alt annet Clojure har å tilby). Man har også native tilgang til f.eks. Hadoop, Spark og Kafka via Java interop. Jeg lurer på hvorfor Clojure ikke er mer utbredt i denne nisjen. De få som gjør ETL/ELT med kode pleier å burke Python eller Scala (for å få tilgang til Java libs).

@leif.eric.fredheim https://github.com/slipset/guess-a-number/blob/master/src/guess_a_number/battle.clj er https://github.com/slipset/guess-a-number/blob/master/src/guess_a_number/core.clj implementert for to. Sistnevnte er kode som kom til verden ved at eldstemann hadde lært seg “tenk på et tall” spillet, og så skal man gjette hvilket tall det er. Førstnevnte er dette spillet spilt av to ulike spillere i samme prosess. Aner ikke om det gir mening eller om det funker.

Dette var forøvrig fra den tiden da eldstemann ikke hadde begynt skikkelig med engelsk, så det måtte kodes på norsk 🙂