ymz_ncnk

Totally fair, the 3x is based on local throughput benchmarks focused on protocol overhead. It doesn’t reflect full network latency, but gives a baseline for serialization and transport cost.

I think for simple scenarios, the Command Pattern can indeed be an overhead. It’s more suited to systems where structure, composition, or replayability matter.

Thanks for the thoughtful questions.

Compression: cmd-stream-go doesn’t currently include built-in compression, but it’s a potential feature for future versions.

Retries & Latency: You're right, basic packet retries are handled by TCP. cmd-stream-go doesn't implement application-level retries directly, since those are typically left to business logic where factors like idempotency and error semantics come into play. Also, it uses the standard Go net.Conn without modifying TCP options like TCP_NODELAY.

go:generate for Commands: Good suggestion, this could be added in the future.

The benchmarks - https://github.com/ymz-ncnk/go-inter-server-communication-be...

Sorry for the late reply.

> so a very compact ansible/salt stack?

I think you could try to use cmd-stream-go as an automation tool as well.

> "high performance", but what did you test the performance on?

I will publish benchmarks soon.

> also, what protects the open endpoint on the server side?

You can use mutual TLS for that.

MusGo is no longer supported, please consider using mus-go instead. mus-go benefits:

1. It is very simple and can be easily implemented for other programming languages.

2. More flexible.

3. The test coverage is 100%.

4. It is faster.

5. Does not use code generation.