[saurik]

> And then, within the matrix of those message busses, we don't need Erlang's restart capability. We have an abundance of ways to restart processes, from systemd, to kubernetes, to any number of other ways.

I agree with pretty much all of your comment (which clearly comes from a place of deep experience), but the thing that keeps bringing me back to the ideas of Erlang--potentially trying in vain to implement similar concepts in the languages I actually work in (including developing a way to manage fibers in C++ coroutines that work similar to Erlang processes so I could debug background behaviors)--is the idea that these restartable and isolated units simply aren't large enough to be managed by the operating system and systemd or kubernetes of all things: they are things like individual user connections. While there are plentiful easy ways to do shared-nothing concurrency in the world attached to virtually every software project and framework these days, they are all orders of magnitude more expensive than what Erlang was doing, even with its silly little kind of inefficient VM.

[llimllib]

It's worth noting that jerf implemented process trees including restarting services in golang - so I'm curious in what way he means that we don't need Erlang's restart capability when he added it to his own library.

[jerf]

We do not need Erlang's exact solution.

The suture interface for a service in the latest version is:

    type Service interface {
     Serve(ctx context.Context) error
    }

Where's all the stuff for gen_server? https://www.erlang.org/doc/man/gen_server.html Where's the "start_link" versus "start_monitor" distinction? Where's "cast" versus "call"? Heck, where's "stop"?

The answer is, those things are all Erlangisms. They make sense in Erlang. But in Go, the supervisor tree doesn't need to enforce any of those things. Cast or call or multicall or whatever else you like in the code that talks to those services. When I got down to it I couldn't even justify a "Start" or "Initialize" call; I just couldn't help but notice it was completely redundant and it could just be in the Serve function.

What you need is that a single crash does not take down your entire service. It does not have to be in Erlang supervisor trees with Erlang gen_servers that have the exact features and behaviors as Erlang supervisors and the exact APIs. It doesn't even have to be in an OS process the same way as Erlang; cloud lambda functions in many ways solve the same problems in a completely different way. Getting too stuck in Erlang's thoughtspace inhibits your ability to design solutions. There are many ways to make it so a single crash does not take down your entire service. Erlang's way is not the only way.

[sangnoir]

> Heck, where's "stop"?

I'm intermediate (at best) in Go, but I've always found server teardown in Go a little clunky: most solution's I've seen are variations of sending a KILL signal to a channel that the server is listening on, which technically is still message-passing, though unstandardized, unlike stop/n

[jimbokun]

That sounds very interesting. What's the project that interface if from?

[llimllib]

https://pkg.go.dev/github.com/thejerf/suture/v4

[camgunz]

I read that list as "Erlang doesn't have exclusive rights to X"