Sorry for the delay. (Was out on vacation last week.)
No worries, hope you had a good time.
So I’ve been playing with your graph library (the code from PR). I’ve been actually thinking before I saw your library on how to ingrate something like a database directed graph like ne4j in motoko but not the case anymore. I’ll add a few questions/suggestions to your PR.
replace pointers to sub-structures (all within one canister memory) with canister-level indirection, across distinct canisters.
Great, but how is memory handled here? I know it’s not specific to my inquiry so feel free to skip this part, but I’m curious to know once you add more slaves to your master canister how the memory of a big graph is going to scale up and when? I’m talking about heap, thread stacks and cache.
From what I’ve read so far wasm is single-threaded The future: Deterministic parallelism within a canister? (i.e. multi-core and many-core canisters)
I initially thought that motoko and wasm behave like go routines and they have some sort of Go Runtime scheduler. I’m guessing that’s going to change in the future?
Like in languages like Rust, I would instead advise people to do application-level error handling with a
Resulttype, and not with exception handling
Coming from Golang application error handling make sense but they both have they ups and downs like the infamous
if err != nil { }
Rust seems to behave the same.
Thank you for your time.