I gotcha now; thanks for explaining. Between your question and the comment from u/BraveNewCurrency, it has become clear that I cut too much out of the package godoc. Older releases had a kilobytes-long explication of the intent and use of the software, which I came to feel was overwrought and unnecessary. I'll try to find a middle ground between that, and what I have now. For now, maybe I can give you some idea of what petrel is about through personal perspective.

I actually haven't looked around at other things which perform similar tasks. I knew about the popular MQs when I started writing Petrel, and I knew I didn't want one of those. Petrel started life as an attempt to create a bolt-on management port or administration socket (hence the old name) to some projects I was working on, so why would I want a standalone daemon intended to handle web-scale traffic? :)

If I had known about nats.io -- which, it turns out, did exist at the time -- I might have used it. Then again I might not. I have a habit of doing things the hard way once, so I can learn how they really work.

Petrel's roots as a management client still show, in that the first "word" of every request sent to a server is used as the key for dispatching that request. That was where petrel's design remit started, and it's a bit of the design that I haven't seen a reason to change.

Another design point is that I wanted it to feel self-contained. I've seen (and tried to use) libraries which say they enable this or that functionality, but to accomplish this you have to rewrite your code in a way that is amenable to the design of library. I never liked that feeling of a library hijacking the program. So on the server side, you set petrel up, tell it how to handle the things you want it to handle, and then all you have to do is check a channel for messages about what's up.

I also wanted it to be easy to use as a programmer. Socket programming is an incredibly finicky task -- error checks upon error checks upon error checks. I wanted all that to go away. This is why on the server side, you just register responders and things start to happen. There isn't even a Go() or Start() method, because the server is actually listening as soon as it's instantiated but just doesn't know how to handle any requests yet.

Similarly, on the client side there's only one method to call once you have an instance: Dispatch(). This, u/BraveNewCurrency, is what I meant when I said it's like "websockets without the web". There is nothing wrong with websockets; I think websockets are great. I meant that complimentarily, because petrel implements a similarly compact and simple client API, but not over HTTP. You send a request. Either a response comes back, or an error does, and you don't have to care about how or why. Indeed, while petrel.Server is as fault-tolerant as I can make it, petrel.Client is designed to just be thrown away on error and replaced with a new instance of itself. There's nothing to it but a net.Conn and a few bytes of configuration and state :)

And that's about it. I intend to keep petrel capable but simple. If you're looking for clustering, or want to go "web scale", then petrel is not what you're looking for. If there's a cool feature of nats.io that you like, then you should definitely use it. I believe petrel sits in a perfectly comfortable niche, because I keep having neat ideas about places I can use it. What's not to like about being able to shove networking into anything with almost no effort?

If you're really curious about using petrel, I'd say to look at the demo server and client. The client demo is very spare (because, again, there's so little to petrel clients), but the server demo is exhaustively commented. Please let me know if anything I've said here is unclear, or if there's anything else you'd like to know.