Ergo: Erlang-inspired event driven actor framework in Go

Love the idea, but i am having a hard time finding out what the code looks like. Where can i see the code for spawn, receive and send?

> ... a command-line utility designed to simplify the process of generating boilerplate code for your project based on the Ergo Framework

Why is there any boiler plate code at all? Why isn't hello world just a five line programme that spawns and sends hello world somewhere 5 times?

I was looking for the same thing. A project like this really needs an `examples/` directory with a few projects to sink your teeth into.

I've been thinking for years that if a project existed like this for Python it would take over the world. Golang is close, I guess.

It's right there. https://github.com/ergo-services/examples

It looks like a close copy of Erlang APIs, albeit with the usual golang language limitations and corresponding boilerplate and some additional stuff.

Most interesting to me is it has integration with actual Erlang processes. That could fill a nice gap as Erlang lacks in some areas like media processing - so you could use this to handle those kind of CPU bound / native tasks.

  func (a *actorA) HandleMessage(from gen.PID, message any) error {
    switch message.(type) {
      case doCallLocal:
        local := gen.Atom("b")
        a.Log().Info("making request to local process %s", local)
        if result, err := a.Call(local, MyRequest{MyString: "abc"}); err == nil {
          a.Log().Info("received result from local process %s: %#v", local, result)
        } else {
          a.Log().Error("call local process failed: %s", err)
        }
        a.SendAfter(a.PID(), doCallRemote{}, time.Second)
        return nil

I don’t know Go well, but this API would surely piss Alan Kay off.

Why a function that takes an Actor instead of each Actor being a type that implements a receive function? There’s so much Feature Envy (Refactoring, Fowler) in this example. There is no world where having one function handle three kinds of actors makes any sense. This is designed for footguns.

I also doubt very much that the Log() call is helping anything. Surely lathe API is thin enough to inline a that child.

> I don’t know Go well, but this API would surely piss Alan Kay off.

> Why a function that takes an Actor instead of each Actor being a type that implements a receive function?

That function is a method with receiver type `Actor` - IE `Actor` implements this HandleMessage function.

Granted it is exactly equivalent to ``` func HandleMessage(a *Actor, from gen.PID, message any) error { ... } ```

But I'm happy sticking with composition over inheritance