This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-08
Channels
- # announcements (5)
- # babashka (46)
- # beginners (32)
- # calva (9)
- # chlorine-clover (4)
- # clojars (31)
- # clojure (83)
- # clojure-italy (1)
- # clojure-nl (1)
- # clojure-spec (13)
- # clojure-uk (12)
- # clojuredesign-podcast (1)
- # clojurescript (30)
- # cursive (3)
- # fulcro (18)
- # graalvm (6)
- # graphql (2)
- # jobs-discuss (6)
- # joker (4)
- # malli (1)
- # nrepl (1)
- # off-topic (15)
- # shadow-cljs (2)
- # spacemacs (3)
- # tree-sitter (19)
- # vim (1)
- # vscode (7)
I'm working on something using golang channels heavily and wonder what your view on clojure/async is when ported to go
Joker's async capabilities are somewhat limited because it doesn't support true multithreading: https://candid82.github.io/joker/joker.core.html#go It uses GIL (Global Interpreter Lock) to make sure the interpreter only runs in one thread at a time to avoid race conditions. On the other hand, being built on top of Go's runtime, Joker's implementation of clojure/async primitives is very simple, almost trivial. It also doesn't have to distinguish between <!
and <!!
, and users don't have to worry about blocking vs. non-blocking I/O inside goroutines. There is no complex state machine transformation behind go
macro. All the heavy lifting is done by Go runtime.