Regarding sandboxing, I am working on https://github.com/babashka/sci/pull/1084 for the #C09622F337D stack. It allows my harness to be fully forked including nested sci REPLs for nested worlds (I am planning to also give it https://github.com/replikativ/yggdrasil semantics). Probably we don't want to pay the overhead in general, but for me it is more than worth it.
Really cool. If you go for forking mode, what is roughly the price to pay in performance terms? When do you pay the penalty? I also want this feature for myself
Is it for every var/atom read invocation or mostly on write?
@jeroenvandijk thanks! What would you want to use it for? 2-4x overhead you have to pay for var or atom access. More precise numbers are in the PR, but @borkdude might have more accurate suggestions of how to benchmark this better.
@whilo I am working on a web platform with multiple hosts. So let's say multi tenant Ruby on rails. Each host needs to be isolated (ideally) and maybe even each request (to limit the damage of an online def). I know that the current sci/fork is cheap but also doesn't exclude var and atom change interference. This is mostly fine for a single user, but I would like to mix users safely. So I would say a slight performance hit is ok. 2x4x overhead is probably ok. Is it for all the vars or only for the one created inside the "world"? E.g. if I load a library do all the vars have this overhead or can I make some vars more static (like what clojure has)
At the moment it is for all vars, but we could change that. That is probably a good idea also for me.
Also, if your world needs isolation and versioning outside the interpreter itself then I would also be happy to explore options for that. I have worked a lot into this direction with http://datahike.io over the last years.
Yeah I think your git replacement is interesting. Right know I'm trying to integrate the normal git via clj-jgit. Probably the datahike version would be more powerful. But I also try to limit myself a bit to get to an alpha version 😅
At the moment it is for all vars, but we could change that. That is probably a good idea also for me.> > Yeah I think one of the USPs the sci setup is that you can safely reuse libraries and so on. Since they are versioned they should not change and it would be safe to make them fully immutable. I guess this has similar tradeoffs as clojure's direct linking. The world approach still has the benefits of reusing memory like normal clojure data structures, but I guess the var deref overhead could potentially pull down performance a bit. But hard to say if it would be significant
Makes sense. Feedback helps me to improve the quality though and make sure the libraries get closer to what people want/need.