Ergo: Erlang-inspired event driven actor framework in Go

1. ergo

   1 37 4,060 4.7 Go

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

   

2. InfluxDB

   www.influxdata.com featured

   InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.

   

3. examples

   2 3 37 1.4 Go

   examples for demonstrating Ergo Framework features (by ergo-services)

   

   The examples are in another repo:

   https://github.com/ergo-services/examples

4. laborunion

   3 1 30 - Go

   Dynamic Worker Pool Library

   

   I have been watching Ergo repo for a while now and you wrote my observation concisely.

   A while back, I tried to solve no.2 on your list by having a dynamically expanding and shrinking go-routines. POC here: https://github.com/didip/laborunion. It is meant to be used in-conjunction with config library & application object that's update-able over the wire. But I never got around to solve that last part.

5. redwood

   4 2 901 0.0 Go

   A highly-configurable, distributed, realtime database that manages a state tree shared among many peers. (by brynbellomy)

   

   with that said it’s quite easy to write an equivalent- https://github.com/redwood/redwood/blob/develop/utils/mailbo...

6. Akka.net

   5 24 4,940 9.5 C#

   Canonical actor model implementation for .NET with local + distributed actors in C# and F#.

   

   No per-process GC (still very configurable unlike the one here) but for hot-reload, if you don't mind completely different language, there are https://github.com/akkadotnet/akka.net and https://github.com/dotnet/orleans

7. Orleans

   6 36 10,477 9.4 C#

   Cloud Native application framework for .NET

   

   No per-process GC (still very configurable unlike the one here) but for hot-reload, if you don't mind completely different language, there are https://github.com/akkadotnet/akka.net and https://github.com/dotnet/orleans

8. protoactor-go

   7 22 5,306 9.2 Go

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

   

   My go to actor framework for golang has always been https://github.com/asynkron/protoactor-go. It seems that both protoactor and ergo are heavily influenced by Erlang. Why would one select ergo over protoactor?

9. Sevalla

   sevalla.com featured

   Deploy and host your apps and databases, now with $50 credit! Sevalla is the PaaS you have been looking for! Advanced deployment pipelines, usage-based pricing, preview apps, templates, human support by developers, and much more!

   

10. Oragono

    8 26 2,893 8.6 Go

    A modern IRC server (daemon/ircd) written in Go.

    

    Not to be confused with ergo, the ircd[0] nor with ergo, the cryptocurrency[1]

    [0] https://github.com/ergochat/ergo

    [1] https://github.com/ergoplatform

11. .NET Runtime

    9 717 16,813 10.0 C#

    .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

    

12. asyncmachine-go

    10 4 152 9.2 Go

    Batteries-included graph control flow library (AOP, actor model, state-machine)

    

    > you cannot send messages directly to a goroutine

    Goroutines communicate through channels, all you need is a queue (eg buffered chan).

    > you cannot terminate a goroutine from another goroutine

    Termination is propagated via context cancellation. go-A cancels ctx, go-B waits with `select`, reads from `<-ctx.Done()` and does a `return`, or checks it after each blocking call.

    > there are no "goroutine-local variables"

    Not sure if I got this one, but every var in a function's scope, which has been `go`-routined, would qualify.

    I'm currently working on a lib/framework somehow related to Ergo, but taking a more "generic" approach of a state machine[0]. It may solve some of the mentioned issues with Go, like addressing and queues for communication.

    You seem to be very attached to an idea of using the same goroutine for a long time, whereas it's usually more dynamic and only schedulers are long lived `go`-s.

    [0]: https://github.com/pancsta/asyncmachine-go

Suggest a related project