3 ms·

What kinds of web sites need this level of complexity? They must be doing something really hard and tightly coordinated, such as collaborative editing, right?

What kinds of web sites need this level of complexity? They must be doing something really hard and tightly coordinated, such as collaborative editing, right? Does this have enough performance to solve the server cost problem of Improbable's metaverse back end? That's a remote object system too expensive to run 24/7.

declan_roberts 2y ago
If you have a really tiny bit of compute that must happen on the edge, I guess it makes sense.
- NathanFlurry 2y ago
  For example – I'm a big proponent of local-first apps, but even those require a sync server. You can easily implement one in under 100 lines of code with actors.
NathanFlurry 2y ago
Hey! > What kinds of web sites need this level of complexity? The most common use cases are high contention & strong consistency workloads where using an OLTP database doesn't work well. A few examples: - Collaborative docs - Local-first & CRDT sync (e.g. Yjs) - Stateful multiplayer games, often async multiplayer (e.g. chess) - Agentic workflows with frequent memory updates - Chat - Scheduling software - Rate limiting Actors can also be used for stateless realtime workloads that benefit from edge computing, similar to what you would use existing serverless edge functions for. The actor model is widely used in larger companies. The best-known example is how WhatsApp used Erlang to scale to 900 M users with 50 devs [2]. It's also widely used at Discord, LinkedIn, Microsoft, etc. Take a look at Erlang/Elixir, Akka, and Orleans for prior art. > Does this have enough performance to solve the server cost problem of Improbable's metaverse back end? Actors usually have a single responsibility (e.g. document or chat room) while Improbable focused on building expansive worlds without clear boundaries between entities. Our docs include tips on scoping the responsibility of actors [1]. The actor model encourages actor-actor communication, sort of similar how entities in the ECS model communicate in games. > That's a remote object system too expensive to run 24/7. Actors automatically go to sleep when unused. They provide the benefit of realtime workloads without the cost of keep idle compute sitting around. [1] https://rivet.gg/docs/scaling#tips-for-architecting-actors-for-scale https://rivet.gg/docs/scaling#tips-for-architecting-actors-f... [2] https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-engineers/#:~:text=Part%20of%20the%20trick%20is%20that%20the%20company%20builds%20its%20service%20using%20a%20programming%20language%20called%20Erlang https://www.wired.com/2015/09/whatsapp-serves-900-million-us....

declan_roberts 2y ago

If you have a really tiny bit of compute that must happen on the edge, I guess it makes sense.

NathanFlurry 2y ago
For example – I'm a big proponent of local-first apps, but even those require a sync server. You can easily implement one in under 100 lines of code with actors.

NathanFlurry 2y ago

Hey! > What kinds of web sites need this level of complexity? The most common use cases are high contention & strong consistency workloads where using an OLTP database doesn't work well. A few examples: - Collaborative docs - Local-first & CRDT sync (e.g. Yjs) - Stateful multiplayer games, often async multiplayer (e.g. chess) - Agentic workflows with frequent memory updates - Chat - Scheduling software - Rate limiting Actors can also be used for stateless realtime workloads that benefit from edge computing, similar to what you would use existing serverless edge functions for. The actor model is widely used in larger companies. The best-known example is how WhatsApp used Erlang to scale to 900 M users with 50 devs [2]. It's also widely used at Discord, LinkedIn, Microsoft, etc. Take a look at Erlang/Elixir, Akka, and Orleans for prior art. > Does this have enough performance to solve the server cost problem of Improbable's metaverse back end? Actors usually have a single responsibility (e.g. document or chat room) while Improbable focused on building expansive worlds without clear boundaries between entities. Our docs include tips on scoping the responsibility of actors [1]. The actor model encourages actor-actor communication, sort of similar how entities in the ECS model communicate in games. > That's a remote object system too expensive to run 24/7. Actors automatically go to sleep when unused. They provide the benefit of realtime workloads without the cost of keep idle compute sitting around. [1] https://rivet.gg/docs/scaling#tips-for-architecting-actors-for-scale https://rivet.gg/docs/scaling#tips-for-architecting-actors-f... [2] https://www.wired.com/2015/09/whatsapp-serves-900-million-users-50-engineers/#:~:text=Part%20of%20the%20trick%20is%20that%20the%20company%20builds%20its%20service%20using%20a%20programming%20language%20called%20Erlang https://www.wired.com/2015/09/whatsapp-serves-900-million-us....