How does Hollywood compare to Erlang OTP for actor systems in Go?

Hollywood is Go-native with optimizations like dRPC and protobuf for performance, while Erlang OTP is Erlang-based with decades of battle-testing. For Go teams, Hollywood offers better integration but less maturity in fault-tolerance tools.

How to set up clustering with Hollywood actors?

Use the remote package with a listen address and TLS config, then integrate it into the engine via EngineOptRemote. The chat example shows how to enable distributed, self-discovering actors across machines.

What happens if an actor crashes in Hollywood?

Actors can restart up to a configurable limit (WithMaxRestarts), and crashes trigger ActorRestartedEvent in the event stream. Guaranteed delivery buffers prevent message loss during failures.

Can Hollywood be used for building microservices?

Yes, its actor model and cluster support make it suitable for fault-tolerant, scalable microservices. However, it may be overkill for simple CRUD services due to the message-passing overhead.

How to monitor dead letters and system events in production?

Subscribe actors to the event stream for events like DeadLetterEvent and use slog for logging. The eventstream-monitor example demonstrates tracking crashes and other internal events.

What are the performance costs of using remote actors vs local?

Remote actors add latency due to network serialization with protobuf and dRPC, but Hollywood optimizes this with no reflection. Benchmarks focus on local performance; remote throughput depends on network conditions.

Open-Awesome

Hollywood

MITGov1.0.5

A blazingly fast, low-latency actor engine written in Go for building highly concurrent and distributed systems.

GitHub

2.3k stars178 forks0 contributors

What is Hollywood?

Hollywood is a high-performance actor engine written in Go that implements the Actor Model for building highly concurrent and distributed systems. It enables developers to create scalable, fault-tolerant applications through message-passing between independent actors, with a focus on speed and low latency.

Target Audience

Go developers building low-latency, high-throughput systems such as game servers, trading engines, advertising brokers, or any distributed application requiring robust concurrency.

Value Proposition

Developers choose Hollywood for its exceptional performance (10 million messages/second), lightweight design, and built-in support for clustering, remote actors, and WebAssembly compilation, all while maintaining simplicity and extensibility.

Overview

Blazingly fast and light-weight Actor engine written in Golang

Use Cases

Best For

Building game servers requiring high message throughput
Developing low-latency trading or financial engines
Creating distributed advertising or real-time bidding systems
Implementing fault-tolerant microservices architectures
Writing concurrent applications that compile to WebAssembly
Scaling actor-based systems across clusters with self-discovery

Not Ideal For

Projects with simple, sequential logic that don't benefit from actor-based concurrency
Teams working in non-Go environments or preferring lightweight goroutines without abstraction
Applications requiring mature GUI tooling or out-of-the-box monitoring dashboards

Pros & Cons

Pros

Ultra-High Throughput

Benchmarks show 10 million messages per second using optimized protobuf and dRPC transport, as highlighted in the README, making it ideal for low-latency applications like trading engines.

Fault-Tolerant Design

Guaranteed message delivery via buffer mechanisms and actor supervision hierarchies ensures system resilience, even on actor failure, as described in the features section.

Flexible Communication Patterns

Supports fire-and-forget, request-response, or both messaging styles, allowing developers to tailor communication to specific use cases without overhead.

Distributed Cluster Support

Enables self-discovering actors across networks for scalable deployments, with examples in the remote and chat examples demonstrating distributed capabilities.

WASM Compilation Target

Compiles to WebAssembly for both GOOS=js and wasm32, extending usability to web and embedded environments, a unique feature noted in the README.

Cons

Protobuf Overhead for Remote

Remote communication requires protobuf definitions for serialization, adding setup complexity compared to local-only use, as admitted in the quickstart section for remote actors.

Ecosystem Immaturity

As a newer project, it lacks the extensive tooling, libraries, and community support of established actor frameworks like Akka, which may hinder integration in complex systems.

Go Version Dependency

Requires Golang 1.21 or higher, potentially blocking teams on older versions or legacy projects from adoption without upgrades.

Frequently Asked Questions

Related Projects

ProtoActor

Proto Actor - Ultra fast distributed actors for Go, C# and Java/Kotlin

Stars5,480

Forks574

Last commit3 months ago

Ergo

An actor-based Framework with network transparency for creating event-driven architecture in Golang. Inspired by Erlang. Zero dependencies.

[Go]Distributed Actor/Grain framework for Golang with goodies

Stars364

Forks37