the semantics matched

Its probably best to think of Electric as its own language, the idioms are different than Clojure

Another example - in Clojure dynamic scope has a bunch of problems - it interacts badly with clojure's lazy collections, and also from a JVM concurrency perspective, bindings are threadlocals which have terrible operational semantics [Leo says: The reason why dynamic vars have terrible operational semantics and bad performance is the binding conveyance mechanism; there is nothing wrong with threadlocal which has well defined operational semantics and are also fast] but in Electric, dynamic scope doesn't have any of those problems, reactive bindings are a foundational compiler primitive and something we use extensively

thanks for the explanation

another way to think about it - in electric everything has to have an initial value. What's the initial value of a server block that didn't come yet?

coming back to my Pending loading indicator problem from yesterday, why is e/wrap needed for blocking JVM calls? results seem to work without it

but it does show the catch block better if I add wrap

blocking calls will block the event loop

in a multi-user scenario all events will be blocked

in our datascript demo we cheated and omit the e/wrap, we should fix it

“all events” as in all events for all connected clients?

but now that makes sense why the loading indicator didn’t work when I wasn’t using wrap

it completely blocks the server side until it finishes

each client has their own server event loop, so not all clients

e/wrap throws Pending so yes, it should improve the demo

@U09FL65DK do they all have threads?

@U11SJ6Q0K btw pull master , we fixed a regression related to Pending

or i can publish a new version

I’ll sync my fork

re threads, not sure

one thing I liked about Phoenix LiveView (well many BEAM based systems) is the cheap processes and every connection having its own isolated process loop

but perhaps the JVM isn’t as good (at least not before project loom)

You're right, BEAM has an advantage here. Loom will make this advantage smaller, but the JVM is still built for throughput

Either way electric needs to run async, so all blocking calls should be wrapped in e/wrap

I could imagine wrap calls to be needed very often, perhaps a e/server-wrap convenience (kind of like async has go-loop)

yeah, could be. Maybe the Electric compiler can do stuff automatically, idk

if you would always just wrap everything, would that cause problems? too much pendings even when you don’t need them

one issue with wrapping everything is that calls like inc and println are indistinguishable from query-database , they are all synchronous and blocking

so the cost of moving inc to a threadpool is paying thread communication overhead which dwarfs the cost of the actual inc

one idea is to use statistical heuristics, the "Electric VM" can could maybe detect slow calls

probably not worth it atm

but I was thinking about electric vs traditional apps

usually you have some logging and middleware in backends

could you do something like that in electric, like bind a call fn that takes a server side function as parameter to call it, wraps it handles errors and logging… even catches exception and shows “error topbar” on client

can you give me a concrete example of that in the context of one of our demos, say the todo list demo?

Ok I understand now - you just want a easy way to log queries, intercept errors, and route errors to a banner

i think you could code that today in userland in a few LOC with a higher order electric fn, or a macro

exactly that, I’ll try to experiment with that

middleware that seamlessly handles both client and backend concerns would be 🔥

yes, it works great! it was easy to do

I made a system I can call like (call. :some-service-name {:foo 42 :bar 123}) and it will invoke a service multimethod on the server in a wrap, and catch any errors… error is shown on client in an alert

I even added an m/observe that uses NProgress to show a generic top loader line