Only Matrix is federated, like email. I really enjoy sending emails without opening an account for each recipient or being subservient to 1 stack provider for 50 years, with all the inbreeding that entails.
It consolidates Go compiled to WASI as an alternative of doing containers.
Linux containers don't "Run anywhere." as docker.io says. You need a specific architecture and kernel features, which is not obvious from afar.
There's also other benefits. Example: the team I work on compiled Kyverno, a CNCF K8s policy engine written in Go, to a WASI target. We are building Kubewarden, a CNCF policy engine where policies are Wasm binaries shipped in OCI registries. We strive to build "a Universal Policy Engine".
Now, we have an experimental Kubewarden policy `kyverno-dsl-policy` that allows you to reuse Kyverno DSL with us.
We also provide WaPC as a target, more performant and secure, hence normal SDKs for Go, Rust, C#, swift, typescript... In addition to supporting Rego, again compiled to Wasm.
IMHO you only benefit from the real sandboxing from WaPC, as WASI's posix-like interface allows you to attack the host.
The next step for the official Go compiler is to export the function symbols, to allow for WaPC.
Just gave a talk on Monday about it in containerdays.io, but the video is not in youtube yet!
In a nutshell, with Kubewarden we strive to build the universal policy engine by:
- Provide all personas (policy consumer, policy developer, policy distributor, engine admin, engine developer/integrator, etc) with current and future industry-standard workflows, not only a subset of personas, nor more than needed knowledge for those personas. It's a bold statement, and if it would be universal it should indeed cater to everyone.
- This is achieved with policies as code, which are Wasm modules: Wasm policies allows us to support Rego DSL (OPA/Gatekeeper), YAML, SDKs for Wasm-compiled languages, and now an experimental Kyverno DSL policy by compiling it to WASM with WASI. Great for using your language and tools of preference.
- Wasm modules have first class support In OCI registries, just like container images: Use same tools that you know as artifact distributor: SBOMs, signing and verifying with cosign, airgap, slsa.dev, etc.
- Policies can be evaluated out-of-cluster: great for CI/CD, dev loop, integration tests, etc.
- Modular architecture informed by using Wasm policies: OCI registry, policy-server, k8s controller, out-of-cluster cli (kwctl), etc. This also helps in adopting future industry-standard workflows.
- Usual features of a Policy engine (mutating, context-aware, recurring scanner of already in-cluster resources, etc). Plus ample room for new features thanks to the architecture. E.g: possibility to run the policy-server directly in the k8s apiserver (one colleague already presented that in Kubecon), possibility to evaluate out-of-cluster policies outside of clusters like OPA just by running the policy-server standalone, more DSLs compiled to Wasm, more languages, etc.
- Vendor neutral, CNCF project, open source, developed in the open.
Technically you don't need a full kernel, edge workers will likely have their own custom trimmed down kernels for running WASM binaries, cutting out a lot of the OS overhead. As long as they implement a limited set of POSIX syscalls they can run WASM binaries, in fact you might even want to limit the WASI syscalls you implement for certain targets.
It also needs root access, and 3.10 is only the lowest supported kernel. Not a docker expert but I could bet that they only support a subset of features there.
What I do know is that docker images are specific to the host architecture, supporting either one architecture, or a blessed list. wasm binaries on the other hand aren't. wasm can theoretically also run on bare-metal embedded scenarios without an OS entirely.
A good architecture for fully parallel, deterministic, thread-safe, serializable and extensible games is the Entity-Component-System pattern. I'm sure that Godot has one or a way to integrate a library that implements it.
I think Unity doesn't come with ECS anyways.
This is why I feel an engine like Bevy will one day beat them all. ECS, rust, memory safety, thread safety.
It just needs an editor (or even a gameplan for what an editor would look like), animation, halfway decent rendering pipeline... it's a very long way from production ready.
I went into it thinking I needed a bunch of ECS multithreading to make it run on an Oculus Quest 2, but honestly, it's completely unnecessary. Vanilla essentially single threaded Unity C# with careful asset optimization, and I get get ~60+ rigidbody running on a mobile chip at 72 fps. I haven't been able to survive a dogfight against more than 12 enemy ai fighters
Tim Sweeney was right, ECS for optimization purposes is overkill for most games and is best relegated to fancy particle systems (which is the route Unreal went)
You yourself say in a different comment that you are currently assessing Element:
https://news.ycombinator.com/item?id=34779070. Either you have a formed opinion Matrix, or you don't. Which one is it?
You keep saying Element instead of Matrix, and obviating the whole Matrix ecosystem. Matrix protocol has several server implementations, and many more things around:
https://matrix.org/docs/projects/try-matrix-now
