forøvrig: eg har brukt clj-async-profiler for å sjekke kva som tek tid i eigen treig kode: https://github.com/clojure-goes-fast/clj-async-profiler i clj-paginate var det, fritt etter hugsen, pr-str som tok mest tid, i/under lokal testing... https://github.com/ivarref/clj-paginate?tab=readme-ov-file#performance

@UGJE0MM0W bra innspill! Enig om Virtual Threads, det er en god match for eksempelkoden vår. Merk: vi bruker ikke makroene fra core.async i eksempelet vårt, clojure.core.async/pipeline-blocking er en funksjon som opererer på to kanaler (inn og ut), pluss en transducer. Men jeg tror vi lager mange flere ekte tråder enn vi egentlig trenger, så tror vi kunne fått til mye mer parallelisering med virtuelle tråder. Med biten av teksten jeg har skrevet har jeg tenkt at jeg vil holde ting helt håndfast: vise litt man faktisk kan gjøre, uten å nevne alle de andre mulighetene. --- Kanskje virtuelle tråder hadde vært en idé for en del 2? Har du lyst til å skrive selv? Jeg synes det er ganske gøy å bruke Clerk til ting som dette. Deploy er rett fram, Clerk har en funksjon som tar inn en Clojure-fil og lager en index.html og en index.edn. Putt begge bak samme mappe bak en http-server, så er du på nett.

> Re concurrency: har du/de lest java concurrency in practice (“tog boka”)? Den har tidvis quiz/kontrollspørsmål som testar kunnskapen din. Det er (for meg) ein god mengde gotchas. https://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 Har ikke lest den—men har fått den anbefalt så mange ganger nå at jeg nesten tror jeg må plukke den opp 😄

re pipeline-blocking: ja, eg fekk med meg det (og det er ein god abstraksjon, trur eg). Re ekte/virtuelle tråder: Sitat frå netty in action frå 2015: > Third, even if a Java virtual machine (JVM) can physically support a very large number of threads, the overhead of context-switching will begin to be troublesome long before that limit is reached, say by the time you reach 10,000 connections[/threads]. Eg les dette som at ein kan bruka opp mot 10 000 vanlege trådar utan problem. Mao. om ein har mindre parallellisering enn det, så treng ein ikkje bry seg om ein fyrer opp f.eks. 1000 trådar. Kanskje eg tek feil. Netty in action brukar 150 000 concurrent connections som eit case der ein treng netty (async). Sidan 2015 har ein vel sikkert fått ein god del fleire kjernar også. Denne artikkelen her skriv godt om slike ting: https://motherduck.com/blog/the-simple-joys-of-scaling-up/

Virtual threads er veldig imponerende. Ekstremt mye enklere å bruke enn Async i .NET synes jeg. (C# Async ser lett ut, men det er mange gotchas, flere enn de fleste tror.) Enig at man bør holde seg unna core.async, vertfall go macro. Noen sier at resten av core.async, som channels, er bra. Men nå med virtual threads er de ikke like viktig.

Morn!

Takk for gode innspill! Virtual threads virker veldig kult. Noe jeg liker spesielt godt med core.async er at det er inspirert av communicating sequential processes, slik som goroutines i Golang. I den begrensede erfaringen jeg har syntes jeg det har vært ganske fint å jobbe med, spesielt siden jeg er vant til Golang. Liker også at core.async spiller greit på lag med resten av clojure med transducers og slikt. Det jeg liker mindre godt med core.async er at go blocks ikke blir parkert på I/O kall, det blir goroutines i Golang (og jeg tror virtual threads I java og?). Det er ikke en dealbreaker syntes jeg, men litt kinkig å jobbe med. core.async implementert med virtual threads hadde vært kult, så vidt jeg har forstått så har bababashka en modifisert versjon av core.async som gjør det.