I tried a bit with atoms..
is there a kind of a list of missing features .. I was missing add-watch
yep https://github.com/candid82/joker#differences-with-clojure
"The following features are not implemented: protocols, records, structmaps, chunked seqs, transients, tagged literals, unchecked arithmetics, primitive arrays, custom data readers, transducers, validators and watch functions for vars and atoms, hierarchies, sorted maps and sets."
correct. Specifically, watch functions for atoms are not implemented. In general Joker is single threaded so everything related to state management in multi-threaded environments doesn’t apply to Joker.
I am wondering about a dialect which leverages golang in all aspects in particular channels, the build system, wasm etc. I like clojure, but in my environment JVM is not an option. I find the thought of having fast upstart time and native capabilities exciting.
clojure.async was more of an afterthought and not core part of the language.
My gostd fork/branch still has a ways to go to meet these objectives, but I’m hoping to take it there! Funnily enough, I got very basic function-wrapping (fns with no args and no return value) working in my private repo, and quickly discovered the one API I tested on it invokes the function on a separate thread, so…I guess that might be the first case of a Joker program running “multithreaded”, even though Joker itself isn’t really designed for it yet? (IIRC, @roman.bataev asked me about MT support in Joker a long time ago, and though I don’t recall responding, I’ve been thinking about it on a back-burner basis ever since….)
thats cool. with "multithreaded" I assume you mean support for go routines?
also a datomic clone on golang could be really great.. I am bit surprised wider clojure community is not picking up more on it
Joker does have limited support for channels and goroutines: https://candid82.github.io/joker/joker.core.html#go, but it’s still single threaded. It’s similar to ClojureScript in this sense.
gostd might directly support goroutines in some sense someday (haven’t really thought about it much yet!).
But what I was referring to is the fact that gostd (on my private repo anyway) wraps a few functions, such that one can call a Go API that takes a function as a callback, and gostd thus allows the (Joker) caller to provide a Joker function to serve as that callback.
What happens when the callback is called? Well, it ends up being on a different thread, based on the limited testing I did! So the mainline Joker code keeps running, and another thread running that Joker function runs (and just says “hi” or something, whatever quick test I threw in).
Joker doesn’t fully support MT, but it’s fun seeing little thinks like that work…as far as they’re tested, anyway.
yeah, I am not sure that works correctly 🙂 There is a lot of global state in the interpreter, that needs to be synchronized in MT environment. That was the reason I introduced GIL, to avoid interpreter running in multiple threads at the same time.
and GIL is acquired / released before / after user callback, e.g. https://github.com/candid82/joker/blob/master/std/http/http_native.go#L155
In principle I dont see why a clojure on golang shouldnt be better than on JVM in the longterm. the golang ecosystem is a lot better in many spaces and connects well to a whole bunch of things. Java/JVM is very entreprisey thing. these days any meaningful opensource project would most likely be on golang or rust
The footprint of a Joker script, versus a Clojure script/program, running a simple web service, is so much smaller that it makes much more sense for “modest” network servers like mine, which is a VM.