Localhost benchmarks are pretty meaningless on code that is expected to deal with network latencies orders of magnitude larger.
It's ok that it runs faster, but much better if it's easier, safer, or more painless than the alternatives. The amount of code for a hello-world doesn't seem to indicate so, but maybe it pays off on more complex usecases.
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.
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.
Localhost benchmarks are pretty meaningless on code that is expected to deal with network latencies orders of magnitude larger.
It's ok that it runs faster, but much better if it's easier, safer, or more painless than the alternatives. The amount of code for a hello-world doesn't seem to indicate so, but maybe it pays off on more complex usecases.
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.
Looks nice. Does it have compression? Retries and latency are whatever TCP does, right? Have you thought about a go:generate format for the commands?
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.