Ergo: Erlang-inspired event driven actor framework in Go

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).