

3·
2 months agoThe white paper is 98 pages lolwut. Is there a maybe 5 page document explaining what this is and why you’d want to use it? Are there existing applications that use the current Racket/Scheme implementation? Why do you want to reimplement it in Rust? I had thought that Racket handled multi-threading, and of course Racket and Scheme are already memory safe (in the sense that C is unsafe). Are there significant performance problems in real use of the existing implementation?
Overall this seems like a rewrite project that should first get some sober thought to convince yourself that it’s worthwhile, unless you’re already convinced. Otherwise why not use your creativity to do something that hasn’t already been done?
It sounds like for this thing to be really useful, you have to replace the whole application ecosystem. Sounds like the basis of a new mobile OS or something. Capability based OS’s have been written before, though IDK if any have gotten any traction.
Guile is supposed to be embeddable in C so I’d hope it’s also embeddable in Rust, or at most needs some Rust bindings. That would be a good thing to write if it hasn’t already been done.
Yeah I don’t know the situation with Guile and threading, but is there really a serious performance bottleneck? What is going on that is slow? If it’s something like cryptographic signatures, it’s presumably using a fast library, so calling the same library from Rust wouldn’t give much of a speedup. If the Guile version is basically fast enough, running it in a single thread could be a decent workaround. Do applications really have to present capabilities millions of times? I’d think it’s something they’d do once at program startup, or maybe occasionally where the user would invoke some protected operation and the capability would temporarily be enabled. In fact maybe you don’t even need language bindings instead of a local socket to pass capabilities through. Then if you really needed parallelism in Guile, you could run multiple processes listening on the socket, instead of multiple threads.
I’ll look at that section of the whitepaper. I’m still a bit puzzled by this whole thing.