It sounds super cool, your idea and implementation for await and transactions. Because of my limited Rust knowledge, it's hard for me to understand how difficult it was to implement such a plugin.
Also, your idea of using different domain specific colors is interesting. It might be possible to express this via some kind of effect system. I'm not aware of any popular Rust libraries for that, but it could be worth borrowing some ideas from Scala libraries.
I see, thanks! I don't have much experience in Rust, aside from some pet projects. Which features of Rust's type system are needed to implement such behavior? (It's unclear to me why I wouldn't be able to do the same in, for example, C++.)
"Zero-Copy In-Memory Cache Abstraction: Leveraging Rust's robust type system, the in-memory cache in foyer achieves a better performance with zero-copy abstraction." - what does this actually mean in practice?
Yeah, I like your examples. In such scenarios, it makes sense when we're just trying to protect against our own bugs rather than a user deliberately sending a path that leads to the password.txt file.
I am not sure, is this custom Os.Root implementation good enough to relay on it? I see that it is based on openat, and validation of paths/symlinks. But should we expect CVEs, which will break this protection layer?
What would be an use case for `os.Root`? Based on my understanding ( https://github.com/golang/go/issues/67002 ), it is related to security. However, under the hood, it doesn't use `Chroot`, so I could imagine, that eventually someone finds a way to escape from the Root.
> Here's where Rivet's architecture gets fun – we don't rely on a traditional orchestrator like Kubernetes or Nomad for our runtime. Instead, our orchestrator is powered by an in-house actor-like workflow engine – similar to how FoundationDB is powered by their own actor library (Flow [4]) internally. It lets us reliably & efficiently build complex logic – like our orchestrator – that would normally be incredibly difficult to build correctly. For example, here's the logic that powers Rivet Actors themselves with complex mechanisms like retry upgrades, retry backoffs, and draining [2].
It is a bit unclear for me, do you use actors themself to develop Rivet Actors, or it is another actor-like workflow engine, not the final product?
(I would be super happy to read an article, which explains architecture, main blocks of the system, gives some an example)
I really like an idea to solve scheduling problem via compiling to WASI. Many months ago I had conversation with friends, how to implement deterministic testing in Go, without custom IO runtime (common approach in Scala/Rust/C++). We were talking about a few random things, which require a lot of effort (compare to WASI):