Ergo: Erlang-inspired event driven actor framework in Go
An Erlang-inspired actor framework for Go is prompting renewed interest in bringing lightweight, supervised processes and message-passing semantics to a language better known for goroutines and channels. Commenters weigh the appeal of “batteries-included” Go against Erlang/Elixir’s BEAM VM, highlighting tradeoffs such as the lack of per-process garbage collection, true hot code reloading, and fully addressable processes, while noting potential for integrating with existing Erlang systems. Others question whether complex actor frameworks belong in Go at all, arguing that teams needing robust supervision and distribution may be better served by using BEAM-based languages directly.
Go vs other ecosystems & “batteries included”
- Several comments praise Go’s rich standard library and “zero dependencies” approach; seen as simpler than Rust’s many competing crates.
- Others argue external ecosystems can surpass stdlib quality at the top end (e.g., logging, error handling), but are fragmented and inconsistent.
- Critiques of Go stdlib include: confusing time API and types, lack of simple date/time arithmetic, lack of guaranteed system CSPRNG access, mediocre logging levels in
log/slog. - Comparisons note that Python/Java/.NET have more “batteries” (GUI, DI, rich collections, plugin systems), but Go’s culture resists “magic” features (reflection-heavy DI, AOP).
Ergo’s design, API, and Erlang integration
- Ergo is an Erlang-inspired actor framework in Go; commenters like the concept and name but want clearer examples and less boilerplate.
- Examples exist in a separate repo; the API closely mirrors Erlang/OTP concepts but with Go-style boilerplate and type-switching.
- There is support for talking to real Erlang nodes, but some Erlang/OTP compatibility has moved to a commercial repo.
- Some suggest for Erlang integration it may be simpler to use NIFs, ports, or plain network services rather than joining BEAM clusters.
Goroutines vs BEAM processes
- Key differences highlighted:
- Goroutines are not directly addressable; communication is via channels, not per-process mailboxes.
- No built-in links/monitors, no process dictionary, no ability to externally kill a goroutine; termination is cooperative via contexts.
- Channels can block senders and are capacity-bounded; Erlang mailboxes are unbounded and non-blocking for senders.
- Ergo cannot fully replicate OTP semantics:
- Kill only takes effect after the current handler returns (possible “zombie” period).
- No hot code reloading.
- No per-process GC; Go’s GC is global.
GC, performance, and hot code reloading
- Per-process GC on BEAM gives fine-grained pauses and good fault isolation; Go uses a highly optimized global GC with very low pause times.
- Some argue Go is generally faster and its GC is “good enough” for most workloads; BEAM still wins on predictable, non-bursty latency and isolation.
- Hot code reloading is absent in Ergo/Go; Erlang uses it heavily in some domains, while Elixir commonly uses limited hot reload for development (e.g., web frameworks).
Use cases and necessity of actors
- Supporters see actors as a fine-grained tool: parallelizing loops, isolating subsystems (logging, sessions, pools) more cheaply than separate processes + Kafka.
- A backend engineer with stable gRPC/Kafka systems questions why actors are needed; responses suggest thinking at a smaller granularity than whole services.
- Some feel that if you truly need robust actor semantics and supervision trees, you should use BEAM languages (Erlang/Elixir) or other actor platforms (Akka, Orleans), not Go.
Critiques: boilerplate and language fit
- Multiple comments dislike the verbosity and ergonomics of actors in Go compared to Erlang syntax and semantics.
- Skeptical voices claim frameworks like Ergo fight Go’s philosophy of simplicity and may be misusing the language; others are cautiously optimistic but want better docs and concrete, real-world examples (e.g., supervision trees and database interaction).